Here’s a video from the “What Developers Love and Hate about iOS, Android, Windows and HTML5″ panel discussion that I took part in during MoDev East back in December. The panelists represented native app developers, HTML/web developers, and myself-representing the HTML/hybrid app paradigm.
I thought it was a great discussion, and nearly everyone acknowledged the benefits of choosing a hybrid solution such as PhoneGap. (That’s me in the brown jacket.)
I am asked all the time “How do I get started developing PhoneGap applications?”. My normal answer is to advise people to check out the PhoneGap Getting Started Guides, which provide a great starting point for every platform. However after further thought, I’m not sure this is always what people are asking. Rather than “how do I get started?”, I think people are often looking for insight into the workflow for developing PhoneGap applications. Everything from tools to developer flow, to getting the app on devices. The Getting Started Guides are essential for setting up the initial project structure, but once you get that setup, you might be wondering “what do I do next?”. In this post, I’ll try to shed some light on the workflow and tools that I use when developing PhoneGap applications.
Know What You’re Going To Build Before You Build It
First and foremost – it is essential to have at least some kind of idea what you are going to build before you build it. If you just start hacking things together without a plan, the final result is seldomly great. Complete (pixel perfect) UI/UX mockups are fantastic, but you don’t have to have a fully polished design and screen flow. Just having wireframes/sketches are a great start. Heck, even a sketch on a napkin is better than starting with nothing.
The UX design/wireframes help you understand what you application should be doing from the user’s perspective, which in turn helps you make decisions on how you tackle a project. This can be purely from a HTML level, helping you figure out how you should position DOM elements and/or content. Or, it can help you gauge your project’s technical complexity – How many “moving parts” do you have, how much of the app is dynamic or asynchronus, or how do different visual elements need to work together? You can leverage this design/mockup to analyze the needs of your application and determine if a particular framework/development methodology is a best fit (Bootstrap, Backbone.js, Knockout.js, Sencha, jQuery Mobile, Angular.js, etc…).
When working with a designer, I use Adobe’s Creative Suite Tools for pretty much everything – wireframes, UI/UX designs, chopping up assets, etc… I’m currently working on a project that was designed by the talented Joni from Adobe XD. Joni designed everything in Creative Suite, and I’m using Photoshop to view screen flows and extract UI assets for the actual implementation.
Note: This app will also be free and open source as a sample/learning resource for PhoneGap, including all of the design assets – I’ll follow up with another post on this later, once the app is available in the app stores.
If you aren’t a “graphics person”, or don’t have creative suite, there are a bunch of other tools that you can use for wireframing and/or sketching (but c’mon, Creative Cloud is only $50 a month). Here are several I’ve used with great success, but this is not a comprehensive list at all:
OmniGraffle – A drag & drop wireframing tool for OS X. This is fantastic for wireframing or documenting screen flows. In fact, the screen flow image shown in Photoshop above was originally composed in Omnigraffle, using the mockups created in Photoshop.
Visio – A powerful drag & drop wireframing/design tool for Windows – much like OmniGraffle, but for windows.
PowerPoint or Keynote – These aren’t just for presentations. They can be really useful for putting together screen flow diagrams, or annotating images/content.
Often people like to sketch out ideas & wireframes on their tablets, here are a few tools that I use for that:
iBrainstorm – A great app for collaboratively taking notes and sketching. I’m partial to this one b/c used to be on the dev team, and I wrote a good chunk of the graphics sketching logic.
There are a bunch of other tablet sketching apps out there, but I haven’t used most of them.
I’m a bigger fan of of using a complete IDE (integrated development environment) than I am of a lightweight editor, simply b/c IDEs tend to have hooks into more features/languages, etc… I know people complain about startup time, but there is no startup time if you leave it open all the time.
There are a few catches when talking about IDEs with PhoneGap. The first is that if you want to deploy anything locally to devices (without using PhoneGap Build), you have to delpoy using the IDE for the particular platform that you are targeting. That means Xcode for iOS, Eclipse for Android, or Visual Studio for Windows Phone, etc… However if you wish, you can use your editor of choice, and just use the IDE to deploy to devices locally. You can even share source code across several IDE installations using symlinks (which I describe here). I very often use this type of a configuration to share code between Xcode, Eclipse, and WebStorm.
My preference for coding PhoneGap applications is to use WebStorm by JetBrains. WebStorm has great code-hinting (even for your own custom JS and 3rd party libraries), great refactoring, hooks into Git, CVS, or SVN repositories, and is a very mature IDE.
I tend to use this as my primary coding tool, then switch to Eclipse or Xcode when I want to locally deploy to a device for testing. When using PhoneGap Build to simplify cross-platform compilation, I just push the code to git, then recompile via PhoneGap Build.
I’m not a fan of Xcode’s HTML/JS editing, and haven’t found an HTML/JS plugin for Eclipse that I really like. To target Windows devices, I use Visual Studio.
I’m a bigger fan of larger IDEs than lightweight editors, but Adobe Edge Code (also known as Brackets) is a great lightweight editor for quick edits. Edge Code/Brackets is an open source HTML/JS editor that supports live editing in the browser and inline editors for CSS styles, without leaving your HTML files. If you tried Edge Code Preview 1, but weren’t sold on it, you should try Edge Code Preview 2. The team has come a long way very quickly. It’s fast, easy to use, and there is a plugin to tie it into PhoneGap Build. I sometimes use this for quick edits.
There are tons of other lightweight editors out there, and everyone has their favorite. As long as you’re happy with the tool, and it can edit text (HTML, CSS, JS) files, you can use it to build PhoneGap applications.
I’m not necessarily the primary target for Dreamweaver, but it has some nice features. Dreamweaver gives you a great programming environment plus a WYSIWYG editor for HTML experiences. It also features PhoneGap Build integration directly inside the coding environment. If you’re used to Dreamweaver for creating web experiences, you can continue to use it and target mobile apps as well.
Yes, that is plural… Debugging Environments. Due to the cross-platform nature and PhoneGap’s leveraging of native web views for each platform, debugging PhoneGap applications can sometimes be tricky. Here are some tips that will make this significantly easier.
The PhoneGap Emulator
The PhoneGap Emulator is my primary development/debugging tool for all PhoneGap apps. It is a browser-based emulator leveraging the Google Chrome browser and the Ripple Emulation Environment. The PhoneGap Emulator runs inside of Google Chrome, and provides emulation of PhoneGap’s core APIs. Since it is built on top of Chrome, it enables you to leverage Chrome’s Developer Tools, which in my opinion are second to none for web/application development. This is a highly-productive developer environment.
Here’s why I like the PhoneGap/Ripple/Google Chrome development environment:
First, this combination enables you to emulate most core PhoneGap APIs without leaving the desktop environment. It enables you to test various APIs including geolocation (with simulated locations), device events (deviceready, back, etc…), sensor events (accelerometer, compass), and even let’s you test with different device aspect ratios – all without having to push anything to an actual device. This saves a lot of time in development iterations. You can read about the supported Ripple emulator features here.
Second, Chrome’s Developer Tools are awesome. Here are just a few things that you can do while developing/debugging your app, live within the emulation environment:
Analyze all resources consumed by your app, via the resources panel. This includes all scripts, images, html files, cookies, etc… it even includes insight into any local data stored via PhoneGap’s local storage database (WebSQL implementation).
View/query all local databases within your app. You can write your own queries to view/alter data in the WebSQL database. Thanks to Ray for sharing this, it’s not immediately intuitive.
Monitor function execution time, memory consumption, event listeners, and frame rendering time via the timeline panel.
The PhoneGap Emulator enables developers to be extremely productive with development, however I cannot emphasize enough that on-device testing is critical for having a successful app. On-device testing can expose performance problems or browser rendering variances that you may not notice in the emulator environment.
On-Device Remote Debugging
As I mentioned above, on-device testing is critical for successful applications. iOS and BlackBerry have an advantage over other platforms b/c the latest developer tools allow you to remotely debug content live on a device.
Since the release of iOS 6, you can debug content in the iOS simulator using Safari’s Developer Tools. Safari’s developer tools give you many of the same debugging capabilities that I mentioned above for Chrome.
To debug an app running in the iOS simulator, just go to Safari’s “Develop” menu, select “iPhone Simulator”, then select your app’s index.html file.
You’ll end up with a full remote debugging experience, just like if you were debugging inside the Safari browser, complete with JS breakpoints, DOM inspection, etc…
When All Else Fails
If you’re still debugging your apps, and the solutions mentioned above don’t work, you can always resort to plain-old “alert()” statements to pop up debug messages, or use “console.log()” statements to write to system logs.
On Android, all console.log('...'); messages will appear as printouts in the command-line tool logcat, which is bundled with the Android SDK and integrated into the Android Eclipse plugin.
On BlackBerry, all console.log('...'); are printed to the BlackBerry’s Event Log. The Event Log can be accessed by pressing ALT + LGLG.
On iOS, all console.log('...'); are output to the Xcode Debug Area console.
The PhoneGap getting started guides will point you to the right direction for getting started with a particular platform. If you are just targeting iOS, you can use Xcode for building. If you are just targeting Android, you can use Eclipse, etc… It is all very easy to get up and running.
However, this process gets much more complicated when targeting multiple platforms at once. When I have to do this, PhoneGap Build becomes really, really handy.
PhoneGap Build allows you to either upload your code, or point to a Git repository. PhoneGap Build will then pull your code and build for 7 different platforms, without you having to do anything special or setup multiple environments. All that you’ll have to do is install the cloud-compiled binaries on your device. You can do this by copying/pasting a URL to the binaries, or by capturing a QR code that will directly link to the compiled application binary.
One other advantage of PhoneGap build is that it lets designers/developers build mobile applications without having to install any developer tools. If you want to compile a PhoneGap app for iOS, but are on Windows – just use PhoneGap build and you won’t need Xcode or a Mac.
Probably the most common PhoneGap question that I get asked is “what MVC/development framework should I use?”. If you’ve been waiting for me to answer this, don’t hold your breath. It is impossible to be prescriptive and say that one solution fits all use cases for every developer.
When people ask me this, I like to paraphrase Brian Leroux from the PhoneGap team: “Use HTML, it works really well.”
I think people often overlook the fact that PhoneGap’s UI renderer is a system web view. Anything that is valid HTML/CSS content can be rendered as your application’s user interface. This could be something incredibly simple, like text on the screen, or it could be incredibly creative or complex. The important factor is that you need to focus on a quality user experience. If you’re worried about your UX, and are worried that Apple may reject your app, then read this article where I explain Apple rejections in detail.
HTML/JS developers come from many different backgrounds, with varying degrees of programming expertise. Some frameworks appeal to some people, other frameworks appeal to other people. There also seem to be new UI & architectural frameworks popping up every week. It would be a disservice to all people who use PhoneGap for us to proclaim that we should only use one singe framework.
If you are interested in UI frameworks, take a look at these:
Today Raymond Camden and I hosted another open session on PhoneGap as part of an Adobe TechLive event. These sessions are an opportunity for anyone to stop in and ask us questions.
The Q&A transcript from today’s session is below. Thanks to everyone for sticking around, and bearing through our technical difficulties – The normal Q&A pod wasn’t working for some reason, so we had to improvise. We’ll make sure this is working for next time.
This was our third event, and we’ve had a great turnout so far, so we will be holding these open sessions once a month. If you weren’t able to make it this time, we’ll be having another one soon. Just check the Adobe TechLive page for future events.
The Fresh Food Finder is an open source mobile application built using PhoneGap (Apache Cordova) that helps users locate local farmers markets that are registered with the FDA. You can search for specific markets, or find the closest markets to your current location. Check out the video below to see it in action:
It was originally intended to just be a sample application for app-UI with full source available here, but happens to be quite popular and useful in the “real world” as well.
In fact, the Fresh Food Finder made it all the way up to #18 in the iPad “Lifestyle” category on iTunes in the first week of its release, and even made one of the featured apps in the Lifestyle category:
All of the information displayed within the Fresh Food Finder is freely available from the US Department of Agriculture through data.gov. This data set was last updated on April 25, 2012.
The top request that I’ve received for the Fresh Food Finder is improved data, with market schedules. I’ve heard everyone loud and clear, and am happy to say that I have some improved data on the way (including schedules and times), so keep an eye out for it in the not-to-distant future.
The Fresh Food Finder can be downloaded today in the following markets:
The Fresh Food Finder uses the following technologies:
PhoneGap: http://www.phonegap.com – PhoneGap is an HTML5 app platform that allows you to author native applications with web technologies and get access to APIs and app stores.
Mustache: https://github.com/janl/mustache.js – Mustache is a logic-less template syntax. It can be used for HTML, config files, source code – anything. It works by expanding tags in a template using values provided in a hash or object.
The code is organized into the following structure:
assets – This folder contains fonts, images, and CSS styles used within the application.
views – This folder contains UI/Mustache templates. Each template is within a separate HTML file.
When the application loads, all templates are loaded into memory as part of the bootstrapping/startup process. Once all the data and templates are loaded into memory, the UI is presented to the user. The majority of the application logic is inside application.js, all views are rendered from the Mustache templates inside of viewAssembler.js, and all UI styling is applied via CSS within styles.css.
Mustache is a templating framework that enables you to easily separate presentation layer (HTML structure) from application logic and the data model. Basically, you create templates that Mustache will parse and convert into HTML strings based upon the data that gets passed in. I’ll write another post later about Mustache, but it can be extremely useful for larger applications.
If you’ve ever used a Windows Phone device’s web browser, then you have probably noticed the gray highlight that the Windows Phone browser puts on top of the HTML content any time that you click on a link. For static web pages, this isn’t a big deal. It indicates that you have clicked on an item. However, if you are building apps with dynamic content, this can become much more frustrating and can have a negative impact in overall user experience. Fret not, TouchClick.js is here to help!
In PhoneGap applications, you can build experiences that respond to mouse/touch events, which can be more dynamic than what is supported in the device browser. Note: The device browser does not support mouse events. All touch input gets translated into mousedown, mousemove, or mouseup events inside of the PhoneGap container. This gray highlight can become a major pain point in highly-dynamic applications. Luckily, I’ve found a way to get rid of it. Check out the video below to see an example of the gray highlight, as well as the workaround in action:
Through lots of trial and error, I’ve found that the gray highlight is applied to all <a> anchor elements, and any html element that has a “click” event handler or lingering “mousedown” and “mouseup” event handlers. Luckily, you can manage event listeners and add/remove event handlers as necessary so that you minimize the gray box. This approach does not get rid of the gray box 100% of the time, but I think it’s safe to say that it gets rid of it 90% of the time. After applying these techniques, I only see the gray highlight if you tap on multiple clickable items in rapid succession.
Here’s how I was able to get rid of the gray highlight box:
Do not use <a> anchor tags ever.
Assign a “mousedown” event handler to the <span>, <div> or other element that you want to be clickable.
When the “mousedown” event handler is invoked, remove the “mousedown” event handler, save the mousedown input coordinates, and add a “mouseup” event handler to the window object.
When the “mouseup” event handler is invoked, remove the “mouseup” event handler, and then compare the mouse coordinates. If the mouse coordinates have not changed, and its within a reasonable amount of time, you can infer that this should be a “click” event, and invoke an action as desired.
Set a timeout to restore the “mousedown” event handler in an asynchronus operation. If you re-add the “mousedown” event handler inside of the “mouseup” event handler, you will still get the gray box.
To make things even more confusing, if you have dynamic content (changing DOM elements) underneath of your touch input, then you get multiple mousedown and mouseup events invoked on different DOM elements underneath where you touched. This happens even if you only touched the screen once. I was able to intercept mouse events and prevent their default actions to mitigate this behavior.
Once you include TouchClick.js, you add event listeners as you normally would, and it even works with jQuery’s event wrappers: