Mobile App Journey - Part V

In the prior post we briefly discussed calling the PG API in order to interact with the device's (such as  a cell phone) API.  Just because I glossed over it do not ignore reading the PG docs and exploring what is available.

You will have more flexibility and power if you are building your app with say, PhoneGap + Eclipse + the Android SDK than you will if using PhoneGap Build.  But you can still do a lot with PGB.

One need for me was the ability to browse the web from within my app.  Remember, a PG app is a native app, that is, it is a native "wrapper" around your HTML5/javascript/css.  So when you are running your PG app that started out as HTML5/javascript/css, you are not running a web app -- you are running a native app.  So, navigating to a web page from within your native app is different than simply navigating to a new page from a web app.

I think there are primarily two choices:  the PG API InAppBrowser, and the PGB Plugin ChildBrowser ( you can read more about what a PGB Plugin is here).

I used the ChildBrowser Plugin, so I have no experience with InAppBrowser.

I had previously asked you to ignore the reference to childbrowser.js in my Index.html page.  To get childbrowser to work you will need to first have a childbrowser folder (off of your app's root folder) with the assets, which are some .png files -- see the link above.

[Edit on July 6, 2013 - assets folder for CB no longer needed]

Next, you must reference childbrowser.js in your page even though you do not have/need this file.

So, in my Index.html:

          <script src="phonegap.js"></script>
         <script src="childbrowser.js"></script>
         <script src="js/jquery-1.9.1.min.js"></script>
         <script src="js/bootstrap.min.js"></script>
         <script src="js/main.js"></script>
     </body>

And finally, in your config.xml (more on this later) you need this line (for PGB):

    <gap:plugin name="ChildBrowser"/>

So to browse, I could have something like this:

        <a class="link1" href="#" onclick="Navigate('http://www.oppositecoast.com');">Opposite Coast</a>.

"Navigate" is a user function in my main.js:

function Navigate(thisUrl) {
     var cb = window.plugins.childBrowser;
     if (cb != null) {
         cb.showWebPage(thisUrl);
     }
    else {
         showAlert("Childbrowser does not exist", "Can't Browse");
    }   
}

 
First I try to initialize the cb variable.  If successful I can then call showWebPage, else I let the user know things went wrong.

I think the moral of this story is that when using PGB you will need to see (if the PG API doesn't have what you want) if a PGB Plugin exists that can be used, then learn how to use that plugin.  PG people occasionally add new plugins so the list changes.

to be continued...

Mobile App Journey - Part IV

Once you have a an editor and testing environment, you can write much of your mobile app without any regard to PG.  This article will not attempt to teach you HTML, javascript, or CSS.  Nor will it attempt to teach you how to call a web service and retrieve data.  I will show you certain things I did, which may or may not be "best practices".  I will show you how I got my idea on Google Play using HJC and PGB and how I handled various issues.

Disclaimer:  Much of what I share is not my own invention, nor is it meant to be the only or best way.  I'm just trying to recount how I got from "nowhere" to an app that doesn't crash. :-)

Phonegap.js

Earlier I asked you to ignore this file in Index.html.  When using PGB you don't actually need the physical file but you do need to reference it in your .html files.  PGB needs to see the reference to it in order to do its build properly.  I tried having it only in Index.html, but then I couldn't get PhoneGap functions to work on other pages, so I added it to each page.  I don't know if this is optimum or correct.

PG has an API, which allows you to communicate with the device itself.  But, it's important that you do not call the API until PG has finished loading on that page!  The PG deviceready event will fire when PG has finished loading.  For example, you wouldn't check navigator.connection.type until after PG was done loading.

While there is code that may need to be called in the user function called by the deviceready event, you can call PG API code outside of the user function if you do it properly.  Sometimes you are testing on your desktop, perhaps using Chrome + Ripple, so there is no PG loaded as PG is only "alive" inside a real PG build, on a device.

You may want to leverage native device behavior when it's available because it may just look better than javascript.

Take the beloved javascript alert() function for example (I think I ripped off a variation of this routine from Ray Camden):

Rather than calling javascript alert(), we call the user function showAlert() with a message and an optional title as parameters.  if (navigator.notification) looks for the existence of PG's API.  Either it hasn't been loaded yet or it won't be because we are running in desktop mode or the device doesn't support it.  If the API doesn't exist on our page we fall back on the good old alert().  Otherwise we call the device's native version of "alert", courtesy of PG's navigator.notification.alert, which will probably look more, um, 'native-like' and polished than the javascript alert().

I guess the moral is that I did not do any interaction with deviceready here -- since normally PG will be loaded by the time the user does something, and I check for PG's "existence" first, and finally I have the javascript alert() as my fallback.

But there are times that you will want to execute code when the page loads that does involve the PG API, and for that you'd better put that code into the function you have deviceready calling.

to be continued...

Mobile App Journey - Part III

I highly recommend the PhoneGap (and other) articles by Raymond Camden.  I also encourage you to view the PhoneGap and Twitter Bootstrap classes on Pluralsight (even if you only get as much done as you can using the Trial license).

Typically, your application will have a file/folder structure something like this (ignore the "childbrowser" folder for now, and all other files besides index.html are up to you):

Each of your .html files would need (given that I am using jQuery and Twitter Bootstrap) to look something like this at the top:

And like this at the bottom (please ignore phonegap.js and childbrowser.js for now):

I would start out with downloading a Twitter Bootstrap template as your index.html, and add the jQuery references.  "main.js" is my application's javascript file.  Test your index.html both as a "normal" web page and also in an emulator (such as Google + Ripple).

Learn how the Twitter Bootstrap menus work.  Their responsive capabilities will cause them to display differently based on screen size.  Learn the TB classes.

As to user input, HTML5 has many validation niceties -- unfortunately many browsers do not use them!  So while, yes, you should code them in your HTML, you will also need to manually validate in your javascript, and if you are passing the values up the wire somewhere to a service of yours, validate there too.

My form code has this:

But since the validations are ignored on my phone's browser, I also have this code:

And this too, once I'm sure I have a number:

The code for isNumber (my apologies for forgetting the author whose post I lifted this from):

// is it a number...
function isNumber(n) {
    return !isNaN(parseFloat(n)) && isFinite(n);
}

to be continued...

Mobile App Journey - Part II

For convenience (mine namely), I shall refer to the HTML/javascript/CSS mixture as "HJC".

The next major point to cover is that while I know some HTML, some CSS, and some javascript, I am by no means an expert, at all, in any of them.  What I am good at is finding solutions to problems.

I suggest you read up on PhoneGap.  Then read up on PhoneGap Build.  If I were just using PG, then I would perhaps be using Eclipse and compiling using various SDKs for Android, iOS, etc.  PGB doesn't give me all the options that the Eclipse/SDK combination does, but it saves much time if you can live with what it does give you.

Next, I needed to settle on an editor.  Having a .NET background I could have used Visual Studio, but to try something (quite) different I chose JetBrains Webstorm, which ties nicely into Google Chrome (using the Ripple emulator) for testing.  There are any number of combinations you can decide on.  I'm not saying this is the best.

Next, I decided on what extra libraries I wanted to use.  My inclination is to use as few as possible.  I chose the ubiquitous jQuery, and Twitter Bootstrap.  I decided not to mix in jQuery Mobile.  jQuery has ease of use with making AJAX calls, notation, etc., and TB's framework does a good job of allowing one to build a web app that fits on about any screen.

We will leave PG out of the picture for now.

A reminder:  this series' purpose is not to teach you HJC (be thankful for that!).  It's merely retracing the things I learned and went through to get an app to market, using HJC and PGB.

to be continued...

Mobile App Journey - Part I

As for many, the idea of building and deploying a mobile app was for me a compelling idea.  This series will recount my decisions and actions to bring my first app into fruition.

Perhaps the first questions is:  native or HTML/javascript/CSS (from now on I will refer to these as 'native' and 'mobile app')?  For certain scenarios native is best or necessary, and yet for many applications a mobile app will suffice.

The second question then became:  if I go mobile app, should I try a hybrid approach such as PhoneGap (Cordova)?  There are other good hybrid choices such as Xamarin (although not free).

The advantages of a hybrid approach was that in theory I could write an app once, and have it deployed to Android, iOS, Windows, etc.  The other advantage of course was that I wouldn't need to learn Java, Objective C, and other languages.

Since my initial app was going to consist of gathering a few inputs from the user and sending the inputs off to a web service, then getting data back and displaying the results, I decided that the mobile app (HTML, javascript, CSS) approach was fine.

I then decided that "yes, I would like to be able to install my mobile app as an 'app' on Android, iOS, and Windows", and therefore I wanted a build solution that packaged my HTML, javascript, and CSS into a native wrapper that could be deployed as a native app.

After a week of back and forth I chose PhoneGap (PG), and more specifically PhoneGap Build (PGB).  PGB allows me to zip up my mobile app and upload it, and then PGB dutifully generates native apps which are wrappers around my HTML, javascript, and CSS.  Thus far I am happy with this decision, although there are some important details not obvious and which I learned about in Shawn Wildermuth's PhoneGap class on PluralSight.

to be continued...

The Everybody Meeting

Historically, in software development, one sure way to kill developer enthusiasm and slow productivity is to have the infamous "everybody meeting", daily.

These meetings come in many forms, but let's use the "defect call" call as our example. This is particularly painful when the team is large and spread across multiple physical locations. At any one time a particular defect may involve 5-10% of the people on the call. Rather than the developer, business stakeholder, and QA person discussing the defect together offline, they spend 30 minutes or so reviewing the ticket, re-visiting the actual business requirements, whether it really is a defect, etc.

The other 15-20 people on the line may have no interest -- and they are relatively unproductive while the conversation continues.

Let's assume $50 per hour per person. For 20 people this is $1,000 per hour. If 15 people are not engaged in the defect being discussed then $750 per hour is being wasted, NOT counting the work they could be doing which is going undone. NOT counting the "why did I just waste my time" de-moralization effect.

Managers have a tendency to feel comfortable when everyone is attending the meeting and available for discussion. But caution must be exercised when these meetings involve more than 4 or 5 people. People need to do their "homework" first, and bring suggestions and solutions to the meeting if at all possible, reducing the negative effects (and costs) that a large meeting can cause.

Finding Lost Family Members

This post is completely off-topic, but is one that hit home personally and I felt deserved mention.

Family members can become displaced from one another through divorces, war, moving, and traumatic events such as Katrina. What is needed is a free, electronic "bulletin board", where people can leave a "post-it" so they can be found, and likewise search for a missing loved one or friend.

I came across such a site at FindMyFamily.LastISawYou.com. After a painless, non-invasive registration, you can leave an electronic "post-it", and also search the database for any family members you may be looking for.

The downside is that the database is based upon participants who leave a message, but if the word gets out for this free service that should not be a problem.

In this day of paid services for employees, classmates, matches, etc., it's nice to find a free site doing such a noble service. I encourage you to spread the word!