top of page

Grupo My Site

Público·108 membros

Preview: New HTML5 PhoneGap Project



This document demonstrates how to create an HTML5 project in the IDE that is packaged as a mobile application and run in a mobile device simulator. When you create an HTML5 application you have the option to create the application using an Apache Cordova site template. Apache Cordova provides a group of APIs that enable you to develop an application with HTML, CSS and JavaScript that is packaged as a native mobile application. The application runs on the mobile device and can access the native functions of the device such as the GPS or camera. By using the Cordova APIs a developer can build a mobile application without writing any native code.




Preview: New HTML5 PhoneGap Project



For this tutorial you will create a very basic HTML5 project that has an index.html file and some some JavaScript and CSS files. You will select some jQuery JavaScript libraries when you create the project in the wizard.


In Step 4. JavaScript Files, select the jquery and jquery-mobile JavaScript libraries in the Available pane and click the right-arrow button ( > ) to move the selected libraries to the Selected pane of the wizard. By default the libraries are created in the js/libraries folder of the project. For this tutorial you will use the "minified" versions of the JavaScript libraries.


If you expand the js/libs folder in the Projects window you can see that the JavaScript libraries that you specified in the New Project wizard were automatically added to the project. You can remove a JavaScript library from a project by right-clicking the JavaScript file and choosing Delete in the popup menu.


To add a JavaScript library to a project, right-click the project node and choose Properties to open the Project Properties window. You can add libraries in the JavaScript Libraries panel of the Project Properties window. Alternatively, you can copy a JavaScript file that is on your local system directly into the js folder.


In the editor, add references to the jQuery JavaScript libraries and CSS files that you added when you created the project. Add the following code (in bold) between the opening and closing tags.


Working with CSS Style Sheets in HTML5 Applications. A document that continues with the application that you created in this tutorial that demonstrates how to use some of the CSS wizards and windows in the IDE and how to use the Inspect mode in the Chrome browser to visually locate elements in your project sources.


I'm using Phonegap to build an app, problem however is that the default built from phonegap is portrait orientated. Atleast, that's what it seems. When I test the app on my ipad the width is adjusted fine, bu the height for some reason is bigger then the actual content of the body. I narrowed it down to this line:


Monaca started with a powerful Cloud IDE that can run in the browser. Now a desktop GUI tool (Localkit) and command-line tool (CLI) are available as its local development companions. In addition, we provide an extension for Visual Studio. Your projects can be synchronized no matter what environment you use. It's the perfect app builder.


For the past several years, HTML5 web app developers have been using the Apache Cordova project to create an incredible array of apps targeting native platforms. Many, such as the Wikipedia Foundation's mobile app, have had tens of millions of downloads across platforms. Cordova is the fundamental tool which enables developers to use open web technologies - HTML5, CSS3 and JavaScript - to create both fundamental and innovative mobile apps. This is why Amazon supports the Cordova project and enables developers to target the Amazon Fire OS platform. We want to enable web developers to take advantage of the advanced capabilities of the Chromium-based Amazon WebView integrated into Kindle Fire tablets running Fire OS.


This will create our new Cordova project directory, pre-fill it with the skeleton folders, and then add in the appropriate Fire OS support files (amazon-fireos). (The first time you run through this process, you'll be prompted to download the AWV SDK found here) Make sure you change the package name to be unique to you or your company, rather than com.example.html5 in the above example.


The Cordova config.xml settings file can be found in your main project folder. Enter in your contact details, the name and description of your app, and then add in Fullscreen and BackgroundColor preference tags (see below) which will make your app fill the entire screen, and prevent any sort of color flash as it loads.


Next we'll need to replace the different sized app icons that our project used before we are ready to publish. These images are found in the /platforms/amazon-fireos/res directory, and will need to be created and copied over manually. I used a drawing program to whip up a quick app icon and then exported it as a giant 512px square image (you'll use this later when submitting your app to the Appstore). I then shrunk the images as needed and saved them as icon.png files in the following folders:


This will prompt you for all the information you need to enter and create a new keystore file for you to use to self-sign your app. Put the keystore somewhere safe and accessible from your Cordova project, and don't forget the password!


dropbox.com/s/i83f0yketwh4vic/Jumpy%20Shark%20Help%20File_EXPORT.pdfAll the phonegap plugins of @Cranberrygame are working with this method. So like Chartboost, Revmob, Vungle you name it, they all work. I don't show how to implement the plugins but once you export your game all the plugins are installed automatically once your import them inside Intel XDK.


If I were building a project for a client, I'd look at this bug, and the lack of updates, as a *possible* sign that the project is dead. I can definitely do a fork! But the question is, do I want to? Do I want to - essentially - shepherd my own version of this project? I may have no interest in improving it, maintaining it, etc. Therefore I'd be disinclined to fork/fix and simply look for a better solution.


As much as I love open source, I think there is a *huge* disconnect sometimes between people who work in that world versus people actually using it. Should we expect more from people using open source projects? Maybe. Will that ever happen? Probably never.


Also, I really think this line isn't what I said: "However, he went one step further and simply recommended against patching any open source library, in spite of the simplicity of the patch. " (Lord, not sure why Disqus copied the format too. Ugh.) I certainly do *not* believe that and actively do create PRs on projects. I just don't know if that is the right solution for someone in *this* case.


Well, with that comes the concern that I also tend to disagree with generally: just because a project hasn't had many updates doesn't necessarily mean it is dead. We used to call that "stable", unless there are so many bugs it was just abandoned as even its own developers found something better. A rapid update cycle often means incompatible changes can happen at any time (I refuse to willingly use ruby for this very reason). And even the most active project may find itself abandoned as the core developers get pulled by professional commitments, or corporate politics gets involved.


If you do fear such an update of a dependency, then are you yourself also dependent on that potentially breaking change? By choosing another library, are you instead setting yourself up for a similar breaking change because as an active project, an incompatible change can happen at any time (true for the hundreds of 0.x libraries out there), or maybe the library you choose will also die as its developers move on to other things, or choose not to update because of the incompatible dependency change?


This is a significant thing with the apps targeted for PhoneGap building: the rapid release and support of new html5 libraries and javascript mechanisms, like built-in promises, objects in ES6, O.o() in ES7, and the growing trend in web-components as a design model - these all mean that the need or desire to use a new key feature may require significantly restructuring the app to the point of a total rewrite of a major part of the main structure (either view appearance or control structure). When that happens, a new library or framework will be around to take advantage of the new features and make it easier to deploy them than the current libraries can.


1) no updates == danger: Yep, you are right on that. I was a bit too harsh on Ratchet for not updating over the year. I *do* think it is something to note. A project that hasn't been updated in a year may be very stable and not need updates. However, it is *also* possible that the project is abandoned. How about this - given a project hasn't been touched in a year - a developer should perhaps do extra checking to see if the project has become stable or left to rot? No activity doesn't mean either - just that you should look a bit closer.


2) "If you do fear such an update of a dependency, then are you yourself also dependent on that potentially breaking change?" Oh certainly yes - that's a concern for choosing any project. But - to me - modifying the project to fix it means adding _another_ possible concern. I'd think a developer would possibly want to minimize such concerns. Again, imagine the case where the developer wants to use library X but has no intent in helping it. That's not nice, but probably accounts for 99% of the people using the product. 076b4e4f54


Informações

Bem-vindo ao grupo! Você pode se conectar com outros membros...

membros

bottom of page