Posts Under Tag: TRINUG

Strategies for Versioning Your RESTful API

The annual Raleigh Code Camp was a great time and the most attended one yet.  This year I presented “Strategies for Versioning Your RESTful API” to a larger room of attendees than I was expecting.  It’s sort of a niche topic, but more API developers are discovering they need a plan for versioning their RESTful APIs as they evolve.  Thanks for all that attended; there was good conversation showing that REST is indeed a topic open to interpretation.

My slide deck can be seen here:

The versioning samples I ran were run in ASP.NET Web API 2 and can be found on GitHub.

Tags: , Filled Under: Programming Posted on: November 10, 2014

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.

TRINUG on Google Play

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: , 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.

signing the apk in PhoneGap Build

This is where you upload your key for your APK

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.

Android developer console

The Android Developer Console

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: , 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:

AppHarbor setup

Connecting AppHarbor to Source Control

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:

GitHub service hook

GitHub Service Hook for AppHarbor

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.

PhoneGap Build Edit button

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

PhoneGap Build app settings

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:

PhoneGap Build debug button

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:

PhoneGap Build debug console

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:

Debug Console command

PhoneGap Build Debug 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: , 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:

PhoneGap Build control panel

PhoneGap Build project control panel

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: , Filled Under: Programming Posted on: July 2, 2012