Raymond Camden's Blog - Mobile

MAX Session: Advanced PhoneGap Build

Thu, 09 May 2013 21:49:00 -0400

Oddly, the last of my Adobe MAX sessions is available online now but none of my earlier ones. I assume they will show up in the next day or so. But for now, enjoy my eloquent presentation on the more advanced aspects of using PhoneGap Build. You can download the source code for the sample apps and slide deck as well. As always, I hope this is helpful!

Update to my Edge Inspect Viewer

Tue, 07 May 2013 14:55:00 -0400

Many moons ago I blogged about a proof of concept I built that allowed you to view Edge Inspect screen shots via a nice web interface. This was built in Node using the Express framework. I've finally gotten around to doing some updates to it as well as pushing it up to Github.First, I applied the Topcoat UI framework. This is an open source UI framework for desktop and mobile available for forking on Github. Here is a screen shot of the app in action: And here is a shot of the detail view (I'd like to add a bit more detail here): New features include the ability to filter by operating system or device. Here's a filter on Android: So, like it? As I've said before, I'm still rather new to Node so take this code with a grain of salt. You can download (or fork and improve!) here: https://github.com/cfjedimaster/inspectviewer

Visual comparisons of PhoneGap Notification UIs

Sun, 05 May 2013 08:03:00 -0400

If you are a PhoneGap users, hopefully you know about the various aspects of the Notification API. The Notification API allows for visual, audio, and tactile notifications. In this post I want to focus on the visual notifications and how they differ from the built in web view notifications.To begin, I created a simple HTML interface with buttons that would let me test alerts, confirms, and prompts. These are the three forms of visual notifications both in vanilla JavaScript as well as PhoneGap's Notification API. I used my epic CSS skills to make this a bit more touch friendly: Now let's look at the JavaScript. The first three event handlers are for the vanilla JavaScript notifications. Notice how in confirm and prompt the result is handed back to a variable. The only real customization available is with the prompt method which allows for a default. Here is the alert being fired: Here is the confirm: And finally the prompt: Now let's consider the native options. First note that they allow for customization. In each one you can tweak the button (or buttons) as well as the title. Be aware that confirm takes a list of button labels while prompt takes an array. (I consider that a bug and I hope they fix that soon.) Also note that all three have callbacks for handling button presses. I've used null as a way of signifying I don't want to do anything, but you would normally have some kind of logic there. Here is the native alert: Here is the native confirm: And lastly, the native prompt: Just to be clear, do remember that you can build your own alerts, confirms, and prompts as well if you feel like it.

Recording and Assets from my PhoneGap Presentation

Thu, 02 May 2013 16:34:00 -0400

For those who attended my PhoneGap presentation earlier this week (or those who just want to hear the sound of my silky-smooth almost Billy Dee Williams voice) you can view the recording at the URL below. Note that if you did not register for the event you will be asked to register before you can view it. To be clear, this is free. http://w.on24.com/r.htm?e=582941&s=1&k=A3BCF648B71580CC093EF1264D5D27B1 For folks who want a copy of the demos I used, you can get the source code and the slide deck here: https://github.com/cfjedimaster/Introduction-to-PhoneGap As always, thank you to everyone who showed up (apparently near 900) and I hope you enjoyed it.

Using the Progress event in PhoneGap file transfers

Wed, 01 May 2013 16:08:00 -0400

Earlier today I was happy to hear that PhoneGap 2.7 was released. While perusing the changelist, I thought I read that progress events for file transfers were added in this release. However, I was wrong. FileTransfer has supported a progress event for a few months now. But since I figured this out while halfway through a demo, I figured I'd finish it up anyway and share it on my blog.As you can imagine, the onprogress event is a property of the FileTransfer object. It is passed a progressEvent that is - unfortunately - not documented as far as I can see. The code example though gives you enough information I think to deal with it: So from what I can see - you get a property that determines if the total size is known, and if so, you can get a percentage by using it with the loaded property. Otherwise you're just guessing at the time left, but at least you know something is going on. For my demo, I thought I'd build a simple MP3 downloader/player. I googled for 'free open source music' and came across this incredible MP3 by Kansas Joe McCoy and Memphis Minnie: When the Levee Breaks. Go ahead and listen to it. As much as I love indie music and trance, the sound of old recordings like this is like pure gold to the ears. Anyway - I began by creating an incredibly simple web page. It lists the name of the artists and the song along with a picture. I've included a button that will trigger the download. Also make note of the status div I'll be using for - you guessed it - progress events. Here's a screen shot of it in action. Ok, now let's take a look at the code. Starting from the top, the first thing that may interest you is the file system request. I ask for the temporary file system so I have a place to store the mp3. Once I've got a hook to the file system I then enable the button in my web page and start listening for a touch event. The function that handles the download, startDl, creates the FileTransfer object and points it to the remote MP3. I've used almost the exact same onprogress event as demonstrated in the PhoneGap docs. I changed it to write out a percentage when possible and in other cases, simply append dots to the end of a string. That way people know something is still being transferred. The final portion simply handles the media portion. I didn't bother adding any real controls so it just begins to play the track and that's it. (To be clear, this wouldn't be hard to add, just check the Media API for more information.) Watch the video below to see it in action: As a last tip, note that the docs for Media seem to imply that you need a URI, not a file path. On iOS it seems to require a path, not a URI. Thanks to Simon MacDonald for helping me with this.

Note about PhoneGap Build and Splash Screens

Tue, 23 Apr 2013 11:54:00 -0400

I'm currently working on my MAX Advanced PhoneGap Build presentation (wait, scratch that, of course I'm done already, I mean, who waits to the last minute???) and ran into an interesting issue. Using a splash screen is rather easy via the PhoneGap Build config.xml file.To test this feature, I used Placekitten.com to quickly create an image sizes 320x480. PhoneGap Build supports multiple splash screens of multiple sizes and densities, but I wanted to see how well a default splash screen would work. I dropped the kitten in my folder and added this to config.xml: <gap:splash src="splash.png" /> I zipped up my folder, uploaded to PGB, and everything worked fine. I noticed, though, that my splash screen only lasted for about a second. I did some digging and found that you can disable the automatic hide of the splash screen by doing this: <preference name="auto-hide-splash-screen" value="false" /> I then wrote a bit of JavaScript that made use of the PhoneGap Splash Screen API: In theory, that should be it, but I noticed something odd. I launched my app, and then saw this: What the heck? At first I thought I had broken something, but then I noticed the image went away after 5 seconds. I then realized what my issue was... size. When using the a default splash screen, PhoneGap is able to size it correctly for any device (afaik), but if you keep the splash screen around, it then reverts to the proper size for the device. In my case, I was testing on an iPhone 5. So I created a new image sized 640 by 1136 and added this to my config.xml: <gap:splash src="retina.png" width="640" height="1136" /> And it worked perfectly. You can see via this exciting YouTube video: So I guess the take away from this is - while a default splash screen may work on multiple devices, if you are doing anything with the splash screen (like keeping it on screen longer), you want to ensure you build out properly sized images for your supported platforms. Frankly, that's probably the best idea in general anyway.

Presenting on PhoneGap Next Week

Tue, 23 Apr 2013 10:15:00 -0400

On Tuesday, April 30th, I'll be giving a free, online presentation about PhoneGap as a preview of my Fluent 2013 presentation in San Francisco next month. This presentation will be your basic "What the frak is PhoneGap"-type presentation, but if you are looking for a chance to get introduced to the product, please join me. Developing Mobile Applications with PhoneGap (Wow - I need to update my bio there. Apparently I'm still an independent contractor focused on ColdFusion.)

Recording from my PhoneGap Build Ask a Pro Session

Tue, 02 Apr 2013 16:24:00 -0400

Miss my presentation last week? You can watch the recording below. If you would like the slide deck or any code samples from what I demonstrated, just ask. http://seminars.adobeconnect.com/p8cm5w6pyyx/ As always, if you have any questions, just let me know. If you have any suggestions, let me know as well.

Google Analytics and PhoneGap

Thu, 28 Mar 2013 15:19:00 -0400

Today I decided to try out the Google Analytics plugin with PhoneGap, and more specifically, PhoneGap Build. It is one of the plugins supported by PhoneGap Build and being somewhat of a data nerd, I was curious to see how well it worked. Unfortunately, my "quick little experiment" turned out pretty horrid so I thought I'd write up my experiences to help others avoid the same mistakes I made.Based on the docs for PhoneGap Build and this plugin, I was directed to the plugin's README file. The API to initialize, and track, events was rather darn simple. It's all asynchronous, but in most cases, you can probably just ignore the results. You want to log crap and forget about it. You've got support to register events and pages, and set up custom data as well. (Note that free accounts are limited to 4 custom variables.) I whipped up a sample application that would let me test custom events and pages. I didn't want to bother setting up jQuery Mobile or a custom Single Page Architecture, I decided to just fake everything. So here is the index.html file: Note the two buttons. I'm going to use one to trigger an event and one to trigger a page load. Now let's look at the JavaScript. Again, fairly simple. You can see the initialization, you can see the button event handlers, etc. In theory, that should be it, right? The Google Analytics number came from, well, Google Analytics of course. I created a new site and used the "App" setting (since I was building a mobile app): Easy peasy. I pushed up my bits to PhoneGap Build, pointed my iDevice at the QR code (they do have a purpose), ran the app, and everything worked great. And by that I mean I didn't see the error handler firing. I went over to Google Analytics, switched to the Real-Time view, and waited. And waited some more. I knew Google Analytics, in general, took some time to process crap, but Real-Time is supposed to be, well, real time! I put it aside, did some other stuff, and every now and then I'd run the app, click some buttons with my fat fingers, check the Google Analytics site, and curse. Eventually I began to Google around for some solutions. By some random luck I found this page on the PhoneGap Build support site: Build 2.3 and Analytics Plugin . Specifically, one of the support folks posted a link to a GitHub demo of the feature in action (amirudin / pgb-analytic), and right there in the README was...

1- When creating new Analytics account, choose 'Website' under 'What do you like to track'

*sigh* So.... yeah... that's frustrating. I created a new GA site, put in a fake URL as they suggested, switched the GA variable in my code, and voila - I began to see data immediately. Surprisingly - or maybe I shouldn't be surprised - the geo data was right as well. That orange blob isn't terribly accurate, but I do live inside of it. Actually, and I just found this, it did get more accurate over time: If I had to guess, I'd say it took about one hour before data showed up in the non-Real-Time portion, but once it did, it seemed to update rather quickly. I tested on my Android device (more on that in the notes below) and it showed up pretty quickly. Also, both my events and page data were recorded. As I don't have a lot of either, I won't bother to show a screen shot, but they are showing up. So - it works.... but I've got some issues (as well as general questions out there for anyone who wants to help). 1) Number one thing is to ensure you make a GA account for a site, not an app. I've already got an email out to the PhoneGap team to see if we can document that better. I can see a lot of people making that mistake. 2) This is probably covered in the Google Analytics docs, but I'm pretty sure I screwed up by sending "new Date()" as my event value. First, GA already knows when an event occurs. So that's kinda dumb on my part. Secondly, it looks like the dates were converted into milliseconds since epoch. I've got some wonky big values for them in the GA dashboard. I'm thinking that if my intent was just to log the "event" of hitting a UI item, I'd be ok with a value of 1 there. If the event was something like, submitting a form for the # of beers you drank, then the value could be dynamic. 3) I tried to use the plugin locally - the one linked to from the PhoneGap Build docs. It never worked, and apparently is dead. But this isn't documented, and the PhoneGap Build docs link to it, so it... yeah... confusing. I was told that this is the new site for the repo: https://github.com/phonegap-build/GAPlugin. I haven't tried these bits. 4) Unfortunately, the Android version of this is throwing errors. Immediately on loading up the error handler is thrown, but all I get is a "JSON Error". Yeah, that's it. At the same time, some functionality worked (you can see in the screenshot above the device was recorded). My plan is to hook up DDMS (or whatever they call it now) and see if I can figure out the issue there. 5) I think you could do some interesting stuff with the variables aspect, especially if you have a paid account. You could make use of the device API and the connection API to log some additional information about your users.

"Ask a Pro" presentation this Friday

Tue, 26 Mar 2013 11:39:00 -0400

This Friday, March 29th, I'll be giving an "Ask a Pro" online webinar on PhoneGap Build. I'll be talking about the site and demonstrating how to use it -- both by itself, and with Dreamweaver CS6 and Edge Code. To attend, simply register at the link below. Building Mobile Apps with Adobe PhoneGap Build

Building "Robust" PhoneGap Applications

Mon, 18 Mar 2013 15:11:00 -0400

Lately I've been thinking more about how to make my PhoneGap applications more robust. By robust, I'm not necessarily talking about performance. While that is important (see my coworker's excellent blog post on the topic: Performance & UX Considerations For Successful PhoneGap Apps), I'm thinking more about the general stability of the application as a whole. This is especially important for applications that need, or desire, data only available on the network. How you handle network conditions is just as important as how you handle the UX and performance of your application. (Well, that may be up to debate. :) In this blog post I'm going to share some thoughts and examples of what I mean by this and - as always - I look forward to your comments, suggestions, and corrections.

Net-Using PhoneGap Apps

It may seem silly to specify "Net-Using" PhoneGap applications, but to be clear, you are perfectly able to build a PhoneGap application that doesn't require any assets from the Internet. All of your HTML, CSS, and JavaScript can be packaged up with the application and if you have no real need to hit any remote sources, then don't! If you're used to loading the CDN version of JavaScript or CSS libraries, replace them with local copies. That being said, if you do need to use the Internet in your application, how can you handle network issues? PhoneGap provides two different ways to handle this. First is the Connection API. This isn't really an "API", but simply a constant you can check in your code to determine the connection status. There are various results that allow you to not only check for any connection but the relative strength of the connection. This would be useful, for example, to determine what quality of a YouTube video you want to display - standard or HD. Here are the possible values for this constant:

Connection.UNKNOWN
Connection.ETHERNET
Connection.WIFI
Connection.CELL_2G
Connection.CELL_3G
Connection.CELL_4G
Connection.NONE

One of the constant values for the Connection object is UNKNOWN. How you handle that is really up to you. In general, I think it is safer to be pessimistic and assume UNKNOWN is the same as OFFLINE, but I go back and forth on that. The second thing PhoneGap provides is an event system that can recognize network changes. You have both an offline and online event your code could listen to. In general, I think it makes sense for an application to check network status on startup, and have event listeners for changes. You can't assume that a network connection that exists when the application starts up will be there for as long as the application is alive. In order to test this, I build an application that supports Twitter searches. If you are online, then you can enter a search term, hit the button, and see the results from the Twitter API. If you are offline, the application responds correctly. The code I used also handles your device going on and offline. Here is a portion of the code. For the most part, this should just "make sense", but definitely let me know if you have questions. (I've included the entire application as a zip attached to this blog entry. It really isn't much more than this, but if you want to see it, just download the bits.) Here's an example of the application running in Ripple. Notice that I've done a search already. I can now use Ripple to take my device offline. Notice that Ripple fakes an in-device notification with a simple HTML element overlaying the device. It may be a bit hard to see, but the button has been disabled as well. This way the user can't accidentally click it again. When network access is restored, the button will be re-enabled.

Error Handling

Here is something that I've really done a poor job of. Many of PhoneGap's APIs, and most remote APIs, have some way of handling errors. But I'd be willing to bet most of your error handlers look something like this. Ignoring for a moment that the message is a bit rude, note that no attempt was made to diagnose the form of the error and make a logical decision as to what should be done. Not every error is a "Throw your hands up in the air and give up" exception. In many cases, it may be something that is purely temporary and you should prompt your user to try again. In other cases it may be so bad you would want your application to shut down. The main point I'd want you to take from this is to consider the types of errors you may be handling and try to react to them as nicely as possible. If you have error gotten a weird, obtuse error in an application before and wanted to pull your hair out, keep in mind that you're a developer. Imagine what the normal people think. Remember that JavaScript has full exception handling with try/catch support, the ability to throw your own exceptions, as well as listening for errors at the window level. Finally, don't forget you can Lint/JSHint your code. For folks new to JavaScript that can be a bit intimidating, but if you go in with the mindset that you don't necessarily need to agree with everything the Lint/Hint says, then the experience isn't quite as jarring. Of course, if you use Brackets you get JSLint built in. (You can also find an extension for JSHint.)

Tracking/Reporting Issues

So here's an interesting one. Imagine you've got your application making use of the CowBell API. You've got nice error handling/connection handling in place. You've made the experience great for the end user. But are you responding to these errors and events? Are you cognizant of just how often the CowBell API goes down? Maybe it isn't so bad. Maybe it is pretty crappy. But until you start getting a bunch of 1-Star reviews you may not necessarily be aware of it. Maybe it isn't too bad. For example, only 10% of the calls fail. That isn't terrible, but it is probably enough to warrant looking into app-side caching. You can make use of LocalStorage or the Storage API. Heck you can use the File system too. On the flip side, if your API has something like 100% uptime and your users are in an an area with darn good coverage, it may not be worth your development time to worry about it. The point is - how do you know? During internal testing, you could make use of simple code that logs to a local file. You can add a temporary button to upload that file to a central server. While your users are testing, they can make use of that button then to upload their local logs when something is acting up. Of course, you could do the same thing on a released, production application as well. How much you track and how you upload is more an ethical question than a technical one, but that option exists as well. You can consider using a third party JavaScript error-handling solution, like {errorception}. However - I do not know if they support PhoneGap apps. When I find out, I'll edit this post. I've found their results to be incredibly detailed and useful for my desktop apps.

What else?

So I know I'm missing other suggestions. Leave a comment below!

Free ColdFusion 10 and jQuery Mobile Tutorial

Tue, 12 Mar 2013 12:29:00 -0400

Thanks to reader Mikel Shilling for pointing this out to me. The most excellent (as Bill would say) folks at FigLeaf have released a free ColdFusion 10 and jQuery Mobile tutorial. You can download the bits here: http://training.figleaf.com/curriculum/cfjqm.cfm Objectives for the course are:

Define and use AJAX/JSON(P) web services using ColdFusion 10
Define and use REST web services using ColdFusion 10
Using REST services with jQuery Mobile
Implement real-time communications with HTML5 web sockets

Testing PhoneGap, Parse, and Push? Read This

Thu, 07 Mar 2013 09:57:00 -0400

Back in October of last year I wrote a guide to integrating PhoneGap, Parse, and push notifications. Recently a reader noticed that my guide no longer worked and asked me to dig into it. I did today and have found the root of the issue.I began by creating a new PhoneGap 2.5.0 project at the command line and adding in the Android platform. I then followed the directions from my blog post. Since I wasn't testing intents, just notifications, I only followed about half of the guide. Basically the portions where I updated AndroidManifest.xml and the Java source. I deployed this to my Android device, went to the Parse dashboard, and sent a push. As my reader noted, the push did not show up. I began my investigation by looking at the Data Browser. Part of the Data Browser is a grid of "Installation" objects. These are all the people who have installed your app. It also includes a channels array that signifies what push channels, if any, the device is subscribed to. Notice that every single device is subscribed to "", which represents the broadcast channel. I.e., everyone should get it. On a whim, I decided to try subscribing to a channel called foo. You can see it in the list above. I did this by simply adding one additional line of Java code: PushService.subscribe(this, "", testpush2.class);
PushService.subscribe(this, "foo", testpush2.class); I then went to the Parse dashboard and tweaked "Send to" to specify a segment. Notice that foo shows up. That's cool. It meant my Java code was definitely working, and Parse recognized that foo was a possible channel. I selected foo, entered some text, hit send, and... Boom. It worked. WTF, right? I then wondered - what would have happened if I had selected "Broadcast" in the drop down? I did... and it worked! From what I can tell, something about Parse's dashboard has changed. The default option to send to everyone wasn't the same as sending to the Broadcast channel, but it was in the past. Here's a visual representation of my tests. So as far as I know, everything still works just the same as before, it is just the dashboard that has changed in terms of how you test. I'm going to post to Parse's forums about this to see what the specific difference is and if I get an answer, I'll post a link to it in the comments below.

PhoneGap Sample - Diary (Database and Camera support)

Mon, 04 Mar 2013 13:14:00 -0400

Last week a reader wrote in with an interesting problem. They had a simple application that made use of PhoneGap's database support. They wanted to add camera support as well. Their idea was that a picture could be associated with their content. But then they ran into this issue:

iOS Quirks:
When destinationType.FILE_URI is used, photos are saved in the application's temporary directory. Developers may delete the contents of this directory using the navigator.fileMgr APIs if storage space is a concern.

So, right away, this brings up a useful reminder. Most things you do with PhoneGap will work cross platform, but it is crucial that you pay attention to the individual quirks for each platform. In this case, something that works fine in Android will cause problems in iOS. Even worse, because the images aren't removed immediately, you may think there isn't a problem at all. (As a side note, navigator.fileMgr is old code that has not been removed from the docs yet. I've filed a bug report to get this updated.) I thought I'd help out the reader by building a simple application that made use of both technologies and then work out how I'd handle the iOS issue. I started off by building a simple Diary application. The Diary would allow you to write basic content entries, each with a title, body, and a creation date. I built a very simple "Single Page Architecture" framework to handle my application views and routing. I won't even call it a framework. Really it is just one simple JavaScript function that lets me load a page into the DOM. Here's the home page - a simple list of entries with the ability to view an entry and add a new entry. And the amazingly well-designed entry page: Finally, the form to write entries: I also built a wrapper for my Diary class that would abstract out the persistence for me. Here is that wrapper. Please don't laugh at my pitiful object-oriented-ish JavaScript code. This wrapper class is used by index.js, which handles my views, adding and requesting data, etc. Basically, index.js acts like a controller in your typical MVC setup. I'm not going to share all of that file (to be clear, everything is shared via a Download link below), but here is an example. So - nothing too terribly complex. I took this as a starting point (in the zip you can download, this may be found in www1) and then began to integrate camera functionality. I started by adding a new button to my entry field. This button, "Add Picture", would request the device camera and store the resulting image in a hidden form field. I began by using FILE_URIs even though I knew it would be an issue with iOS. In almost everything I do I start slowly, take baby steps, and try to build one thing at a time. So with that in mind, I went ahead and just built it in. Here is that code: Note that I've updated my form to include a preview and the entry detail view (not shown here) has been updated to display it. Ok, so at this point, the core functionality is done. (You can find this version in the www2 folder.) I can add and view content (I didn't bother with edit/delete, but that would be trivial) and I can use the device camera to assign a picture to a diary entry. Now to look into the bug. My initial thought was to make use of the File API to copy the image to a nice location. Even though Android didn't really need this feature, I thought I'd keep things simple and just use the same logic for all. (To be fair, when I say "all", I really was just testing Android and iOS.) However, I ran into an interesting issue. When requesting the persistent file system, iOS gave me a directory that was customized for my application: /var/mobile/Applications/362CC22A-BA60-4D81-876C-21072A06CE16/Documents Unfortunately, the Android version of the exact same code returned a more generic folder. I could then make a folder for my Android app that was specific to the application itself, but that seemed to be a bit too much work. (Really, it wasn't, I was being lazy.) I rang up Simon MacDonald, my goto guy for PhoneGap questions (or at least until I annoy him ;) and in discussions with him, I discovered that right now there isn't a simple way, cross platform, to ask the file system for "a safe application-specific place to store my crap." (My words, not his.) I made a decision at this point. Even though it felt a bit wrong, I decided I'd write code just for iOS. I figured the 'forked' code would be pretty small and therefore it wouldn't "pollute" my code too much. This smells like one of those decisions I may regret later, but for now, it is what I'm going with. I began by sniffing the device using PhoneGap's Device API. Nothing too complex here. If I detect iOS, I request the persistent file system and remember the root directory it gives me. Next - before I store the Diary entry, if I am on iOS, I simply copy the image over. Overall, not as messy as I thought. You can find the complete source code attached below. Enjoy.

Quick Tip - Make Apache's Directory Indexes look nicer on mobile

Wed, 27 Feb 2013 14:12:00 -0400

If you use Apache, then you most likely have DirectoryIndex enabled on your development server. This is the feature that lets you request a directory without a home document and see a list of folders and files. This is not normally enabled in production, but in certain circumstances it may be. (For a file download directory perhaps.) If you do any testing with mobile devices though you will probably find this index to a be a bit hard to read. Here's an example. You can pinch and zoom to make that a bit easier to read, but it's a pain in the rear. Turns out Apache has a few options that allow you to customize how this index file is created. One of them, IndexHeaderInsert, allows you to add HTML to the head section of the document. I added the following to my Apache httpd.conf file: And the result was exactly what I needed: Hope this helps!