by Brian Rinaldi
This is part 2 in a multi-part series. Click here to read Part 1. The sample files are available here.
The goal of this step is simply to get acquainted with the PhoneGap Build service. In this step, we will get the PhoneGap starter app running on your test device.
You can begin by downloading the zip file of the starter project mentioned earlier. Assuming you have registered for a PhoneGap Build account, you can create a new app in the form by clicking “Upload a zip file.” As you can see, there are other means available for creating and updating your application, but for the sake of simplicity in this tutorial, we will be using the zip file option.
Your new application will automatically have a name and description added. This is because the starter files include a config.xml file in which these settings are included. If a config.xml file is included, it will control these settings in PhoneGap Build and they will not be able to be changed via the site. Go ahead and check the “Enable Debugging” and “Enable Hydration” options before clicking the “Ready to Build” button. We’ll discuss those features later.
Once you click ready to build, you’ll see PhoneGap Build working to complete the builds for the various supported platforms.
You’ll notice that the iOS icon is red. Assuming you have a signing key setup as discussed in the prior section covering setup for iOS, then you can get this working. Simply click on your project name to edit it and choose the signing key you added. Once the key is chosen (and assuming it is currently unlocked), PhoneGap Build will begin building your app for iOS.
In order to install the app on your device(s), simply scan the QR code for the project using any QR code scanning app. On Android this will start a download. Once the download is complete, select it via the notifications pull-down and choose “Install” and then simply open it to see the result. On iOS you will be prompted with a notification to install the app. Simply click the “Install” button. The app, when run, should look like the screenshot below.
Hydration
Since you probably noticed the Hydration screen come up before your app loaded, let me explain what Hydration is. Basically, Hydration will check for updates to the app PhoneGap Build every time you relaunch the app, allowing you to push new features to all your test devices without needing to re-install the app repeatedly. The only time a new binary is generated for your application (meaning it would require a new install on the device) is if you update the settings in your config.xml for name, version, version code, icons, splash screens, preferences, features or access tags.
This will save you a lot of time and effort and will also speed up the build process on PhoneGap Build. However, it is important to note that this is not intended to be used in production versions of your apps, in part because this sort of update mechanism isn’t allowed in Apple’s app store. If you have detailed questions about Hydration, you can check the PhoneGap Build documentation.
Next Steps
In the next step, we will learn how to connect our PhoneGap application to an API. Click here to continue to Part 3.
I got a phonegap build set up as per the instructions here. However I get an error while installing on WP8 device.
I think that unfortunately the XAP produced by Build is not compatible with Windows Phone 8 yet. You can build for Windows Phone 8 manually using PhoneGap/Cordova. We posted a tutorial on that here: https://flippinawesome.org/2013/04/08/cordova-windows-phone-8/
Thanks a lot. I wish they add the Phonegap build support for WP8 too soon…
Hey, great tutorial, but i have 2 questions:
1. If the icon is red means that it IS working or that it is NOT?
2. What about Blackberry?
Please read the instructions before commenting. It clearly says it will be an Android app – not Blackberry and not Windows.
You can use any javascript lrrabiy you want, but the animations themselves must be written in CSS, not javascript. It is absolutely vital for mobile developers to learn CSS animation instead of javascript. The reason is that Javascript is actually very inefficient for animation, and it’s only recently, with the proliferation of mobile browsers, that we are starting to notice this. You see, with a JS animation (e.g. created using jQuery’s animate function), the javascript lrrabiy sets an interval timer (lets say, 33ms, which is about 30 frames per second), and on that interval, it figures out where the animated element should be, using complex math calculated by the CPU, and then puts it there. Unfortunately, if the CPU is too slow to do that calculation every interval, it gets backed up and the animation stutters. jQuery and other JS animation tools do some work to combat this, sensing a drop in frame rate and trying to make the interval wider, to give it more time to complete the calculations, but it’s often too-little-too-late.On the other hand, when you do a CSS animation (e.g. using the transform or webkit-transform css properties), you leave it to the GPU to simply calculate where the element should be as often as it can. As soon as it calculates the element’s new position and places it there, the GPU starts the calculation again. This means the animation is always as smooth as the GPU can possibly make it, no matter what. If you animate too many elements for the GPU to handle it may still have trouble, but instead of ugly stuttering, it will be a more graceful drop in framerate.Hope that helps.