Creating an app with PhoneGap Build – Part 6: Summary

This is the sixth and final part of a six part series detailing the creation of an HTML5 mobile app using jQuery Mobile for TRINUG that was eventually transformed to an Android app available in Google Play via PhoneGap Build.  In this post I summarize the experience and give my thoughts about this process.

The Final Output
I set out to learn mobile development and publish an app to an app store.  I started by creating a mobile targeted website for TRINUG using jQuery Mobile.  I then determined that Android’s Google Play marketplace had the quickest and most inexpensive road to publishing.  From there I made sure to follow some Android development guidelines and created an installable Android app with the TRINUG mobile website via PhoneGap Build. I then published the app to Google Play.

Will I Pursue to Make This Available to Other Mobile Operating Systems?
This raises an interesting question.  On one hand I could rightfully justify not publishing my free app on iTunes or the WP7 market because I’d have to pay $99/year for the privilege.  However, there are a few other concerns as well.  One being that in order to sign an iOS based app, you need a Mac which I do not have.  The other is the question I realized at the end of the process: does a jQuery Mobile layout work as a universal layout across all mobile operating systems?  I’d say the answer to that is no when you think of WP7.  Although I have a Windows Phone App Hub account and could technically publish my app for WP7, I don’t believe the current layout shares the WP7 ‘experience’.

What you say, a WP7 ‘experience’?  That’s right, if you open almost any WP7 app you’ll see it has a black background and has top-level side-swipe menus.  I guess it’s called a Metro Modern UI layout, I’m not really sure.  I do know is that if I submitted this “one-size-fits-all” PhoneGap Build based app using a jQuery Mobile layout, it would be an inconsistent layout to all other standard WP7 apps.  The real solution here may be to use PhoneGap within a native application and not use PhoneGap Build.  Or maybe I just say that since I’m a .NET developer, I write a completely native app.  Either way, you can see that there are situations where PhoneGap Build isn’t the master key to mobile app development where one set of source code rules all ecosystems.

PhoneGap Build’s Future
The introduction of PhoneGap and PhoneGap Build has been revolutionary.  Anyone can now design and maintain a single code base and deploy it to multiple platforms.  It may not be suitable for every single platform (à la WP7), but it does make the time it takes to publish an app much quicker and cheaper than maintaining multiple code bases per mobile operating system.

PhoneGap Build’s true power comes from its ability to use the PhoneGap API features to access native phone controls.  Although I didn’t use that API in version 1 of the TRINUG app, I see huge potential for its use in future versions.

Lessons Learned
There’s no question that jQuery Mobile is easy to use, well documented, has a large community base, etc.  However, I think the next time I attempt a mobile app, I’d give Telerik’s KendoUI  a close look.  The main difference from a consumer standpoint between jQuery Mobile and KendoUI is KendoUI customizes the UI per device where as jQuery Mobile attempts to look the same on every platform.  For instance, using KendoUI, a button on iOS would look like a native iOS button where as on Android that same button would look like a standard Android themes button.

I also learned that your app will only be perceived to be as good as it looks.  If you use a standard jQuery Mobile theme and layout as seen on a mobile website, your app will look like a mobile website wrapped up in an Android app.  In order to pull this off in any sort of professional way where you’d consider charging money for your PhoneGap Build based app, you’ll want to make sure you consult with a designer to make the app look as native as possible.

In the end though, one has to admit that PhoneGap is revolutionary with all the barriers it breaks down for native mobile application development.  If you told me a year ago that an app with my name as the publisher would be in the Android marketplace, I wouldn’t have believed it.

Links
TRINUG mobile on GitHub
TRINUG public PhoneGap Build download page
TRINUG mobile website on AppHarbor
TRINUG on Google Play

 

Part I: Background and Introduction
Part II: Developing the TRINUG Mobile Site
Part III: Using PhoneGap Build
Part IV: Testing and Debugging
Part V: Publishing to Google Play
Part VI: Summary

Tags: PhoneGap, TRINUG Filled Under: Programming Posted on: July 6, 2012

Creating an app with PhoneGap Build – Part 5: Publishing to Google Play

This is the fifth part in a blog series detailing creating the TRINUG Android app via PhoneGap Build.  In this post, I share my experiance publishing the app to the Google Play Android store.

Why Android?
The TRINUG app I created details upcoming event info for my local .NET user group.  So why did I decide to first release my app via Google Play?  There are many reasons, but it boils down to it being the fastest, simplest, and cheapest way to distribute an app compared to iOS and Windows Phone.  Plus, Android as a whole (meaning all versions) makes up the largest market share of smart phone operating systems.

Both iOS and WP7 have an annual $99 fee they charge to developers for the privilege of being able to publish apps to their marketplaces.  They both also have an app submission approval process.  Android on the other hand charges a one-time $25 fee for a Google Play publisher account.  There is no formal approval process for releasing apps and app updates on Google Play.

Preparation for Publishing
Android has a very easy to read Publishing Checklist for Google Play guide.  Even though an app developed via PhoneGap Build isn’t a ‘true ‘ native Android app, it still must meet certain Android-specific guidelines in order for the install to be uploaded to the Google Play store.

Preparing Graphics
There are currently 16 checklist items Google provides for publishing preparation.  For the TRINUG app, I was only really concerned with two of the items.  One was item 11: ‘Prepare Promotional Graphics’.  When you upload your app to the Google Play publishing site, besides your installable .apk file, you’ll be asked to provide some additional graphics.  The detailed requirements are listed here.  The first requirement is at least two screenshots.

Getting a screenshot of your app running on your Android device is something that will require a 3rd party app to do.  Unlike iOS, there are no shortcut button combinations to capture a screenshot.  There are several Android screenshot apps available but some require your phone to be rooted.  My phone (a Samsung Galaxy S 4G) is not rooted.  I ended up choosing the Screenshot UX app and was very pleased with the results.

The other graphic requirement is a high-resolution application icon.  The reason for this is it provides a way for Google Play to show a large-sized icon on your app’s Google Play page.  I am not a graphic designer by any sort of the imagination and this requirement had me a bit worried.  Fortunately, there are free online tools to generate Android-sized icons for you.  The one I used was Android Asset Studio.

Preparing the APK
The Android Publiching Checklist mentioned above has one other very important item: #12 ‘Build and upload the release-ready APK’.  It includes a link to an article detailing the process.   There are two main items here that you need to pay attention to.  The first being that your app can’t be in Debug mode.  If you remember, PhoneGap Build has an option to create a Debug build.  Make sure that option is turned off in PhoneGap Build for the apk file you create for the Google Play.  The second thing you’ll need to do is sign your apk.  I’ll detail that process below.

Creating a Google Play Publisher Account
Creating a Google Play publisher account is very simple.  Just navigate to the Developer Console and sign in with your Google account.  You’ll be walked through a series of steps and will purchase a developer account for $25.  Once that is complete, you’ll be brought to the Developer Console where your apps are managed.

Signing Your App
Signing your app is detailed in the Google Play developer documentation here.  This step had me a bit perplexed because the documentation refers to Java, Eclipse, Keytool, and tools that I was uncomfortable or unfamiliar with.  The bottom like is this: you need to install the latest version of Java from Oracle.  Once you do that, you’ll need to open a command prompt and follow some steps to generate a key for your application.  I followed the instructions from this DreamWeaver site on how to do all that.

Once your you create the key and password as detailed in that article, it has to be uploaded to PhoneGap Build.  The place to do that is Edit-> Signing.  You’ll be presented this screen where you’ll upload your key and enter in the key’s password that you created with the keytool.

With your key in place, rebuild your app in PhoneGap Build and download the apk on to your computer.  It’s now time to publish it to Google Play.

Publishing on Google Play
The Google Play Developer Console is an intuitive series of screens where you’ll be asked to upload your apk, graphic assets, and answer questions about your app like the description, category, content rating, etc.  The information you provide basically provides a way for someone to find your application from within Google Play.

That is pretty much it!  Once you fill in all the required fields in the Developer Console for your application, you’ll be able to publish it.  I published TRINUG late at night and waited around for about 30 minutes but didn’t see it in the Google Play store.  The next morning it was there.  I’ve since pushed an update out for the app and found it took about an hour for the changes to propagate in to the Google Play store.

In the final article of this series, I’ll provide a summary of my thoughts regarding the use of PhoneGap Build including lessons learned.

Part I: Background and Introduction
Part II: Developing the TRINUG Mobile Site
Part III: Using PhoneGap Build
Part IV: Testing and Debugging
Part V: Publishing to Google Play
Part VI: Summary

Tags: PhoneGap, TRINUG Filled Under: Programming Posted on: July 5, 2012

Creating an app with PhoneGap Build – Part 4: Testing and Debugging

This is the 4th part in a series of blog posts detailing using PhoneGap Build to create an Android app like the TRINUG app.  In this post, I’ll detail debugging the app.

AppHarbor
As a reminder, a PhoneGap Build compiled app is basically an HTML5 based mobile-targeted web page or site.  Before your website is compiled and installed via PhoneGap, it is helpful to view it in the browser of various mobile devices.  Viewing the site in the browser of the device you’re targeting will provide a releastic representation of the compiled app’s layout and behavior because PhoneGap utilizes the browser engine of the native device to display the app.

There are several ways to host a work-in-progress mobile website, but one of the best ways in my opinion is to use AppHarbor.  AppHarbor is designed to integrate with version control systems, compile any .NET code, run unit tests, and finally deploy the associated web application.  Although a platform-agnostic HTML5 website obviously doesn’t use .NET, AppHarbor can still be used as a free web host for your mobile website.

By creating a service hook to your GitHib repo, AppHarbor will deploy the latest code  to your free AppHarbor endpoint.  It even keeps a history of all your past deployments so you could roll back to see a previous version.  To create this service hook, first create an AppHarbor account and  application.  Once the application is created, you’ll be presented with an option to connect to your GitHub repo:

This setup process will result in an application slug and token from AppHarbor for use in GitHub.   Next, from GitHub create a service hook via the Admin section of your repo:

At this point you can navigate back to your AppHarbor account and it should build and deploy your website from GitHub.  You’ll see an option to go to your website from your application’s project page on AppHarbor.  You can use this to view your site on various mobile devices for initial testing.

Debugging With PhoneGap Build

Viewing your website in a browser is a good starting point, but it’s not the same as debugging the actual installed app itself.  When debugging the app, you’ll be able to test all the PhoneGap API calls that interact with your device (for instance notifications, network checks, camera, etc).  Those things aren’t available to test from AppHarbor because they rely on the API hooks to your device that PhoneGap Build provides.

Fortunately, PhoneGap Build offers some very powerful debugging tools.  But first, you’ll need to create a Debug build of your app.  To do that, go to your PhoneGap Build project and chose the ‘Edit’ button of your project.

You’ll then be brought to a page displaying your app’s settings.  In order to allow debugging of your app, enable this option:

Once you save this option, go back to the main project page in PhoneGap Build and rebuild your app.  This will provide you with a debug-ready download which needs to be installed on to a device for debugging.  The install has to be a manual install directly from PhoneGap Build and not from the Google Play store.  Google Play doesn’t allow for apps in debug mode to be distributed.  It’s also worth noting that running an app in debug mode will cause a noticeable performance hit.

Once the debug build of your app is installed, run the app and go back to PhoneGap Build.  There will now be an option available for a Debug console:

The PhoneGap Build console looks mysteriously like the Google Chrome developer tools console.  In fact, if you are familiar with the Google Chrome developer tools, you’ll feel right at home with the debugging functionality in PhoneGap Build:

The ‘Remote’ tab lists the devices running the debug build of the app.  The rest of the tabs preform the same functionality as their counterparts in the Chrome developer tools.  At this point, you have a direct link to the app on the connected device.  For instance, selecting HTML elements in the ‘Elements’ tab will highlight those elements in the app on the device in real-time.  It’s pretty neat to see.

The official documentation for using the debug console is here.  My favorite feature is the ‘Console’ tab.  The Console tab allows you full access to the PhoneGap API on the device you’re debugging.  If I wanted to send that device a vibrate notification, I’d just need to send this in the console:

Very powerful indeed!

As you can see, the debugging tools in PhoneGap Build are powerful and quite useful.  It’s no coincidence that they mimic those in Google Chrome’s developer tools because in the end, your app is a website at its core.

Part I: Background and Introduction
Part II: Developing the TRINUG Mobile Site
Part III: Using PhoneGap Build
Part IV: Testing and Debugging
Part V: Publishing to Google Play
Part VI: Summary

Tags: PhoneGap, TRINUG Filled Under: Programming Posted on: July 4, 2012

Creating an app with PhoneGap Build – Part 3: Using PhoneGap Build

This is the third part in a series of posts detailing the process of building an HTML5 based website and converting it into an Android app via PhoneGap Build.  In this post, I’ll review the PhoneGap Build process.

Preparing the Site for PhoneGap Build
As you recall, I created a single-page HTML5 web site targeted to mobile browsers using the jQuery Mobile framework.  In order to compile a website into an installable Android app, you need to create a PhoneGap Build project and configure your web site for PhoneGap Build.

Configuring a website for PhoneGap Build starts by verifying that the landing page is named index.html.  By convention, PhoneGap Build will look for this file and set it as the main screen for your app.  The other file you’ll need is a config.xml file.  This file is PhoneGap Build specific and contains all the PhoneGap and general app settings for your resulting app.

The PhoneGap Build documentation suggests cloning a sample website they have that contains a config.xml file for you to use as a base template.  The config.xml documentation spells out in detail all the attributes of the config.xml file.  At the very least, you’ll want to personalize the name, description, and id of your app in the config file.  There are many other available values that will all use default values if they’re not defined in the config.xml.  For instance, if you don’t specify an app icon, you’re output will use the PhoneGap icon.  Here is the config.xml for the TRINUG app; you’ll notice that it has Android-specific icon assets defined:

<?xml version="1.0" encoding="UTF-8"?>
<widget xmlns		= "http://www.w3.org/ns/widgets"
	xmlns:gap	= "http://phonegap.com/ns/1.0"
	id		= "org.trinug.mobile.phonegap"
	version 	= "1.0.1">

<name>TRINUG</name>

<description>
Triangle .NET User Group
</description>

<author href="https://github.com/justinsaraceno"
		email="justin.saraceno@gmail.com">
Justin Saraceno
</author>
<preference value="1.7.0" name="phonegap-version"/>

<!-- icons -->
<icon src="icon_057.png" gap:role="default" />
<icon src="Content/images/icons/android/ldpi.png" gap:platform="android" gap:density="ldpi" />
<icon src="Content/images/icons/android/mdpi.png" gap:platform="android" gap:density="mdpi" />
<icon src="Content/images/icons/android/hdpi.png" gap:platform="android" gap:density="hdpi" />
<gap:splash src="splash.png" />
<gap:splash src="splash/android/ldpi.png" gap:platform="android" gap:density="ldpi"/>
<gap:splash src="splash/android/mdpi.png" gap:platform="android" gap:density="mdpi"/>
<gap:splash src="splash/android/hdpi.png" gap:platform="android" gap:density="hdpi"/>

<!-- api access -->
<feature name="http://api.phonegap.com/1.0/network"/>
<access origin="*" />

<preference name="orientation" value="default" />
</widget>

Creating a PhoneGap Build Project
Once your web site’s files are in place, it’s time to create an account at build.phonegap.com.  As of this writing PhoneGap Build is in beta status and non-beta pricing hasn’t been made official.  The TRINUG app is open source so I was able to create it under the free tier.  Being under the free tier exposes the compiled install file to anyone who can find it.  If there was a need to protect the install, the free tier still allows for one private app.

The PhoneGap Build setup process prompts for the source of your website.  The options are to upload a single index.html file, upload a zip file containing the contents of your website, or linking to a source control repository.  Since the TRINUG site is hosted on GitHub, I created a link to the repo’s HTTP location as defined in the repo’s public GitHub page:

Once your source is submitted to PhoneGap Build, a project control panel will allow you to manage your application:

From the control panel you are given the option to update your code, rebuild the code, go to a public download page of your app, or download the various platform-specific installs of your compiled app.

Installing the Output on the Phone
At this point the Android build is compiled in to a valid install-able .APK file.  It’s not Google Play marketplace ready since it isn’t signed, but you can still install it on your Android device.  First, prepare your device by going to your device’s Settings and choosing ‘Applications’.  From here, check the checkbox for ‘Unknown sources’ to allow for the install of non-Market applications.  At this point you can scan the QR code for the Android build of your application which will open a browser and download the install file.  You’ll be able to tell when it’s downloaded by a status message in the Android system tray.  At this point you’ll be able to run the install.

In the following post, I’ll detail debugging your PhoneGap Build generated app.

Part I: Background and Introduction
Part II: Developing the TRINUG Mobile Site
Part III: Using PhoneGap Build
Part IV: Testing and Debugging
Part V: Publishing to Google Play
Part VI: Summary

Tags: PhoneGap, TRINUG Filled Under: Programming Posted on: July 2, 2012

Creating an app with PhoneGap Build – Part 2: Developing the TRINUG Mobile Site

Background:
For scheduling and promoting TRINUG events, TRINUG uses meetup.com.  Meetup.com allows TRINUG to post events, associate them to venues, and collect rsvp information for meetings.  More importantly, for the purposes of creating a mobile web site, meetup.com exposes an API with all that data.

As I mentioned in the previous post, to create an app with PhoneGap Build it must be developed as a mobile-targeted web site.  PhoneGap Build wraps the site’s files in to an installable package for various mobile platforms.  By having the meetup.com API available, it allows for the creation of a web site that uses meetup.com as its data source.  That is perfect because it eliminates the need to manage event data in multiple data stores.

How does one begin creating a mobile-targeted web site in the first place?  Well, there are several frameworks available including jQuery Mobile, KendoUI, Sencha Touch, and others.  I decided that since jQuery Mobile is free, open-source, extensively documented, and maybe the most popular mobile framework, I would work in that platform.

File –> New Web Site:
Even though one could technically develop a mobile web site in a simple text editor like notepad, I wanted to use Visual Studio 2010’s HTML markup and jQuery intellisense capabilities.  To do this, simply choose File –> New Web Site within Visual Studio.  From there, I chose the template ‘Empty ASP.NET Web Site’.  Whatever template you choose doesn’t really matter because you’re going to end up deleting everything to do with ASP.NET.  ASP.NET requires server-side processing and since your app will reside on a mobile device with no web server capabilities, no server-side processes can be written unless they are externally supporting your app (like a web service).

Once your web site project is stripped down (remove web.config, any special ASP.NET folders, all .aspx pages, etc), it’s time to start adding jQuery and jQuery Mobile via NuGet.  Be careful however, because the latest version of jQuery Mobile doesn’t necessarily support the latest version of jQuery.  For instance, jQuery Mobile 1.1.0 requires jQuery version 1.6.4 or 1.7.1.  As of this writing, jQuery  Mobile is not officially compatible with the latest version of jQuery which is version 1.7.2.

jQuery Mobile:
Before embarking on this mobile app adventure, I had zero experience with jQuery Mobile.  The best place to get started with jQuery Mobile is the excellent documentation.  Usually when someone suggests reading framework documentation, I don’t get very enthusiastic about it.  However, jQuery Mobile’s documentation is interactive with working samples that make it very useful and easy to follow.

The documentation is great but after going through it, I felt it would be helpful to read about it in greater context.  As it so happened, I ran across an excellent book titled, “jQuery Mobile: Up and Running” by Maximiliano Firtman.  After you peruse the jQuery Mobile documentation, this book is a must-read.  The author ties together jQuery Mobile, HTML5, and sprinkles in some PhoneGap-minded design tips.  My full review of this book is out on Amazon.

I was surprised to see that the path to mastering jQuery Mobile didn’t  require mastering jQuery itself.  If you know some very basic jQuery syntax such as creating functions, selectors, and ajax calls, then jQuery Mobile will be no problem to pick up.

Pulling in Meetup.com Data:
The next piece to the TRINUG mobile web site puzzle was listing the TRINUG event data and details.  Fortunately, with the meetup.com API, pulling down data is as simple as a jQuery ajax call to return JSON data.

$.getJSON('https://api.meetup.com/2/events?
    key=' + apiKey + '&sign=true&group_urlname=TriNUG&page=20&callback=?',
      function (data) {
      // iterate and display meeting info here
});

Putting it all Together:

In the end, I created a single-page jQuery Mobile site.  This single-page app has multiple ‘pages’ in it under one single HTML document.  This is possible thanks to jQuery Mobile’s support of the HTML5 data-* attributes.  For instance, the main ‘page’ is a div within the HTML document containing the header, content, and footer as shown here:

<div id="main" data-role="page" data-theme="a">
<div data-role="content"><img src="Content/images/trinug_headerlogo.png" alt="" />
<ul id="list" data-role="listview" data-filter="false" data-inset="false">
	<li data-role="list-divider">Scheduled Meetings</li>
</ul>
</div>
 <!-- /content -->
<div style="text-align: center;" data-role="footer" data-position="fixed">
<div data-role="navbar">
<ul>
	<li><a class="ui-btn-active ui-state-persist" href="#" data-icon="home" data-transition="none">Home</a></li>
	<li><a href="#twitter" data-icon="twitter" data-transition="none">Twitter</a></li>
	<li><a href="#about" data-icon="info" data-transition="none">About</a></li>
</ul>
</div>
</div>
</div>

The  output of the main page is as follows:

TRINUG mobile web site using jQuery  Mobile

The entire source is available out on GitHub.  Once you have your mobile web site created, it’s time to package it up and send it off to PhoneGap Build.  The next post in this series will address that step.

Part I: Background and Introduction
Part II: Developing the TRINUG Mobile Site
Part III: Using PhoneGap Build
Part IV: Testing and Debugging
Part V: Publishing to Google Play
Part VI: Summary

Tags: PhoneGap, TRINUG Filled Under: Programming Posted on: June 26, 2012