I’ve been “out and about” lately, attending tech conferences, meetup groups, and meeting with developers in their offices, and I am getting great feedback on mobile development and PhoneGap. There are some common questions that I am often asked, and I hope this post helps everyone understand PhoneGap better.
PhoneGap
Before I go too far, let me attempt to clearly state what PhoneGap is… PhoneGap is an application container technology that allows you to create natively-installed applications for mobile devices using HTML, CSS, and JavaScript. The core engine for PhoneGap is also 100% open source, under the Apache Cordova project. You can read more about PhoneGap under my “What is PhoneGap?” & Other Common Questions post.
PhoneGap User Interface
The user interface for PhoneGap applications is created using HTML, CSS, and JavaScript. The UI layer of a PhoneGap application is a web browser view that takes up 100% of the device width and 100% of the device height.
Think of this as a “headless” web browser. It renders HTML content, without the “chrome” or window decoration of a regular web browser. You build your application to take advantage of this space, and you build navigational/interactive/content elements and application chrome into your HTML and CSS based user interface.
The web view used by PhoneGap is the same web view used by the native operating system. On iOS, this is the Objective-C UIWebView class; on Android, this is android.webkit.WebView. Since there are differences in the web view rendering engines between operating systems, make sure that you account for this in your UI implementation.
PhoneGap API
PhoneGap provides an application programming interface (API) that enables you to access native operating system functionality using JavaScript. You build your application logic using JavaScript, and the PhoneGap API handles communication with the native operating system.
You can read about the PhoneGap API and all of the native functionality it exposes at docs.phonegap.com.
In addition to the “out of the box” functionality, you can also leverage PhoneGap’s JavaScript-to-native communication mechanism to write “native plugins”. PhoneGap native plugins enable you to write your own custom native classes and corresponding JavaScript interfaces for use within your PhoneGap applications. You can read more about PhoneGap native plugins at: http://www.tricedesigns.com/2012/03/01/phonegap-native-plugins/ and http://wiki.phonegap.com/w/page/36752779/PhoneGap%20Plugins
PhoneGap Application Packaging and Distribution
PhoneGap applications are developed using HTML, CSS, and JavaScript, however the final product of a PhoneGap application is a binary application archive that can be distributed through standard application ecosystems.
For iOS applications the output is an IPA file (iOS Application Archive), for Android applications the output is an APK file (Android Package), for Window Phone the output is a XAP file (Application Package), etc… These are the same application packaging formats used by “native” applications, and can be distributed through the appropriate ecosystems (iTunes Store, Android Market, Amazon Market, BlackBerry App World, Windows Phone Marketplace, etc…)
PhoneGap High-Level Application Architecture
Specific application architectures are going to differ on a case-by-case basis, however most data-driven applications employ the following basic architecture. The PhoneGap application acts as a client for the user to interact with. The PhoneGap client communicates with an application server to receive data. The application server handles business logic and communicates with a back-end data repository.
The application server is normally a web server (Apache, IIS, etc…) and has a server side scripting language such as ColdFusion, Java, .NET, PHP, etc… PhoneGap is agnostic of back-end technologies and can work with any application server using standard web protocols. The application server performs business logic and calculations, and generally retrieves or persists data from a separate data repository – this is normally a relational database, but could be any structure or mechanism for data persistence.
PhoneGap applications generally do not talk directly to a database; communication is routed through an application server. The client to application server communication can be based upon standard HTTP requests for HTML content, REST-ful XML services, JSON services, or SOAP (or websockets if your OS supports it). These are the exact same techniques that you would use in a desktop-browser based AJAX application.
The client-side architecture generally uses the single-page application model, where the application logic is inside a single HTML page. This page is never unloaded from memory. All data will be displayed by updating the HTML DOM, data is retrieved from the application server using AJAX techniques, and variables are kept in-memory within JavaScript.
Multi-page client-side application architectures are supported, but are not recommended because you lose in-memory variables when loading a separate page.
Ready for the new era in multi-screen development?
Available now on labs.adobe.com, Adobe Shadow is a new, free tool that enables synchronized browsing and remote inspection across desktop and mobile experiences, in real time.
Rather than having me try to describe it, check out this video from Adobe TV…
Adobe® Shadow is a new inspection and preview tool that allows front-end web developers and designers to work faster and more efficiently by streamlining the preview process, making it easier to customize websites for mobile devices.
Shadow will be updated regularly to stay ahead of web standards, web browser updates and support for new mobile devices entering the market, while incorporating user feedback to provide the best functionality and experience possible.
This version of Shadow focuses primarily on the following:
Device pairing
Synchronized browsing and refreshing in sync with your computer
Perform remote inspection and debugging so you can see HTML/CSS/JavaScript changes instantly on your device.
Be sure to keep up with the latest and greatest information on Adobe Shadow:
I often encourage people to develop as much as possible in desktop browsers when they are building PhoneGap applications. While there are remote debugging tools such as weinre for remote debugging on devices, the developer experience is still better inside of a desktop browser because it gives you breakpoints and memory inspection capabilities. In most cases, you can develop the vast majority of your application within the desktop browser, and switch to a physical device when integrating with PhoneGap APIs or for performance testing. Personally, I use Chrome, and take advantage of the Chrome Developer Tools.
However, when developing from the local file system, you will run into a few roadblocks with desktop browsers. A big issue is the browser security model. If you try to asynchronusly request files when the application is loaded from the local file system, you’ll like get an error like:
XMLHttpRequest cannot load (filename or url). Origin null is not allowed by Access-Control-Allow-Origin.
Luckily, there are a few tricks you can use to get around this… local HTTP servers and relaxing the browser’s security. Note: I’m on a Mac, and I don’t know the syntax for these on Windows.
Local HTTP Server
The first option is to use a local web server to host files. You can fire up a simple HTTP server from any directory in OSX by opening a terminal and using the following command:
python -m SimpleHTTPServer 8000
An HTTP server will start, and you’ll be able to access any content from that directory and child directories from the URL http://localhost:8000/ Thanks to @mesh for this trick.
However, this will only work for static content that is within your directory structure. If you need dynamic content, you’ll need some sort of application server infrastructure.
Relaxed Browser Security
OK, that’s great, but it doesn’t cover every situation. What if you don’t want a local application server configuration? What if you want to develop against services that are remote, and you don’t control them? Well, you are in luck.
You can disable security restrictions in Chrome to allow you to access these services. The following command will allow unrestricted access from the file system, and will also allow cross-site requests. Kill Chrome, then relaunch from a terminal window with the following flags:
open -a /Applications/Google\ Chrome.app --args --allow-file-access-from-files --disable-web-security
Using this configuration, you’ll be able to open an HTML file from the local file system, and that file will be able to make requests to other sites to access data or other resources.
In the screenshot below, you can see that I launched my Census Browser application from the local file system, and it can access services from http://www.tricedesigns.com. With the default browser security policy, this would not be possible.
Local Application Debugging With Remote Services
WARNING: ONLY USE THIS FOR DEBUGGING!
Do not use this configuration for normal web browsing because it will leave your browser security wide open, and able to be exploited and compromised. Do not browse the web when you’ve relaxed the security policy.
Thanks to fellow Adobe evangelist Piotr Walczyszyn for introducing me to this trick.
In PhoneGap 1.5, the naming conventions were changed to use the Apache Cordova naming conventions. EX: PGPlugin is now CDVPlugin, phonegap.js is now cordova.js, etc… If you are running into issues, please be sure to check the PhoneGap version and appropriate naming conventions.
As promised, here are my slides, and I’ll also try to provide a bit more detail since there isn’t much of an explanation within the slide content: PhoneGap Native Plugins.pdf
PhoneGap Native Plugins Presentation
Here’s a brief synopsis of my presentation…
PhoneGap allows you to create natively installed mobile applications using web technologies (HTML, JS, CSS). PhoneGap provides an API that lets you access capabilities of the native device/underlying operating system. “Out of the box”, PhoneGap provides APIs for Accelerometer, Camera, Compass, Media, FileSystem, etc… (You can get more info about the PhoneGap API from docs.phonegap.com.)
However, PhoneGap does not attempt to recreate every native API. Luckily, if you need to access native functionality that isn’t already exposed, then you can easily create a native plugin to provide access to that native functionality. For example, low latency audio processing, multi-screen iOS experiences, or anything else that has a native API.
PhoneGap native plugins shouldn’t be thought of as “plugins” like Flash Player inside of a browser, rather you are “plugging in” additional functionality that extends the core PhoneGap framework. Even the PhoneGap core API itself is built upon this plugin model. If you examine PhoneGap.plist in an iOS project, or phonegap.xml in an Android project, you can easily see the API mappings to native classes.
All PhoneGap plugins consist of a JavaScript class that exposes your functionality to your HTML/JS applications (red box in figure below). The JavaScript class (green box in figure below) communicates to the native layer through the core PhoneGap class using PhoneGap.exec(). This invokes native functionality in your native plugin (purple box in figure below).
You develop your JavaScript class to mirror the API of the native class. In the JavaScript class, you invoke the native function using PhoneGap.exec, as shown below:
Where “success” is a reference to a JavaScript function that will be invoked upon a “success” callback from the native code, “fail” is a reference to a JavaScript function that will be invoked upon a “fail/error” callback from the native code, “NameOfClassMapping” is the plugin class reference (from phonegap.plist or phonegap.xml), “nameOfFunction” is the name of the native function that should be invoked, and [params] is an array of parameters to be passed into the native function.
In both Android and iOS, native plugin classes extend the PGPlugin class.
iOS
In iOS applications, this function is invoked directly, so invoking a function “myFunction” on the class “MyPlugin” is basically the same as calling the Objective C syntax:
[MyPlugin myFunction];
In iOS applications, you “return” a result to the web view using the writeJavascript method of the PGPlugin class, which invokes a JavaScript string inside of the web view. You create a PluginResult class instance, and write the JavaScript string back to the web view:
You can also write native-code-generated JavaScript strings back to the PhoneGap web view using the writeJavaScript method – you can use this to “push” data or instructions to the web view at any time without being requested. An example of this is below:
In the web view, this would invoke the “myJSFunction” JavaScript function with the parameter in the “val” variable.
Android
In Android applications, functions are not invoked directly, instead, the “execute” method of the PGPlugin class in executed. Inside of your class, you override the “execute” method, and determine the behavior based upon the “action” parameter, as shown below:
public PluginResult execute(String action, JSONArray data, String callbackId){
//do something based upon "action"
if ( action.equals( "foo" ) ) {
//handle the "foo" action
}
else if ( action.equals( "myFunction" ) ) {
//handle the "myFunction" action
}
result = new PluginResult(Status.OK);
return result;
}
When you return the PluginResult class at the end of this function, that PluginResult will be evaluated to call back to the success or error handler function.
You can also communicate back to the PhoneGap web view using the PGPlugin sendJavascript function to invoke custom JavaScript at any time, just as I described the iOS writeJavascript function above:
this.sendJavascript( myJavaScriptString )
It is important to understand that regardless of iOS, Android, or any other platform, communication between the web view JavaScript and the native code layer is not synchronous. Do not expect that your native code has executed in sequence after you have requested a native command. You need to use the success/error callback paradigm, and build your application logic using asynchronous coding practices.
Also keep in mind that writeJavascript or sendJavascript can be invoked at any time, not just after a method has been invoked by the JavaScript interface. Using sendJavascript and writeJavascript can enable you to “push” data to the web view. For example, let’s say you are monitoring a specific piece of hardware attached to a mobile device … perhaps a heart rate monitor. You could have a native heart rate monitor class that communicates with the device in a separate thread, and it pushes data back to the JavaScript layer in real time.
AIR 3.2 and Flash Player 11.2 release candidates are now available for download on Adobe Labs. These latest versions have some exciting new features, including Stage3D for mobile devices, broader Stage3D support on desktop machines, multi-threaded video decoding, and better mouse support for gaming scenarios. Get ready for some incredible mobile and desktop experiences powered by Adobe Flash & AIR.
You can read more about what’s new in Flash Player 11.2 and AIR 3.2 on the Adobe Digital Media blog, or check out the videos below to see some of the new features in action.
As promised, here are the slides from my presentation “Introduction to Mobile Development with PhoneGap” from the MobileDev@TU meetup last night. Many thanks to Towson University for hosting the event and inviting me to speak!
I am embarking on a new PhoneGap project that will have to run on many platforms… iOS, Android, BlackBerry, and Windows Phone. This will actually be my first foray into modern Window Phone development. (I did some experimental work with the Windows Mobile platform many years ago, but a lot has changed since then.)
One of the caveats with Windows Phone development is that it has to be done from Windows, just like iOS development has to be done from OS X (normally, although some cross platform technologies enable development via other OS/platforms).
Of course, I did not want to give up OS X, so here’s how I have my environment setup… I have a virtual machine running Windows 7, in which I can run the Visual Studio development tools. I am able to deploy to a physical Windows Phone device using the USB connection.
Windows Phone Development with PhoneGap, on OS X
However, with this configuration you will NOT be able to use the Window Phone emulator, which is a part of the Windows Phone development SDK. The Windows Phone emulator is not supported inside of a VMWare virtual machine because the emulated operating system environment does not meet the minimum requirements (specifically the graphics drivers are not WDDM 1.1 compliant). If you try to use the phone emulator inside the virtual machine, you will just get a blank screen. I spent a few hours trying to find a workaround, to no avail. You can use the Windows Phone emulator if you boot your Mac into Windows using Bootcamp, but I wanted to keep OS X as my primary operating system.
Being able to deploy directly to a device works for me, and is (in my opinion) better than being able to deploy to an emulator, thus I am happy with this workflow. I have heard that other people have had trouble deploying to Windows Phone devices through a VMWare emulator, so here are the details on how I have my environment setup and a few “getting started” links for PhoneGap development on Windows Phone:
Note: All of the project setup work will be done through the Windows virtual machine instance.
There is a detailed “Getting Started” guide for PhoneGap and Windows Phone available at http://phonegap.com/start#wp. This will provide you with all the information that you need to get started with PhoneGap applications for Windows Phone.
As a part of the setup process, you will need to download and install the Windows Phone SDK from http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=27570. This will include a copy of Visual Studio Express 2010 for Windows Phone, as well as additional tools for Windows Phone development.
To be able to deploy an application to a physical Windows Phone device, you will need to register as a Windows Phone developer on MSDN App Hub at http://create.msdn.com/en-US/home/membership. This is a very similar model to Apple’s iOS developer program. There is a $99 annual fee, and once you are registered, you will be able to debug on devices and distribute applications via the Windows Phone Marketplace. However, debug provisioning is much easier. Instead of signing each application with a debug certificate, you just have to register your device as a development device. Once the device is registered, you will be able to deploy to it without any other special steps; this is very similar to the provisioning model for Nook devices.
When linking my AppHub account to my Windows Live account (a required step), I ran into a vague error message “There’s a temporary problem with the service. Please try again. If you continue to get this error message, try again later.” After scouring the web for this error message, I found a few threads that mentioned this error is likely the result of an incomplete profile for your Windows Live account. Sure enough, I went into live.com and filled out my profile (including contact information), and this error went away.
My Setup
Below are the specifics for my setup; I did not have any issues connecting a Windows Phone device with this configuration.
To deploy an application to a Windows Phone device, you just have to use the Windows Phone Developer Registration Tool, and walk through a few simple steps to associate your phone with your developer account. This tool is installed when you install the Windows Phone SDK. You can read full details about debugging Windows Phone applications on MSDN.
As I mentioned above, I have heard that others have encountered problems when trying to deploy applications to Windows Phone devices via a virtual machine on OSX, but I have not had any problems with this configuration.
I was inspired to write this post by several recent conversations. I was in a debate about whether with the Flex/Flash platform you could easily repurpose content to the desktop using Adobe AIR (and vice-versa), but that you couldn’t easily do that with PhoneGap applications. (My stance was that yes, you could repurpose content.)
I wanted to make sure that people were aware that you can repurpose your content, and here’s an example of how.
A while back, I wrote a sample PhoneGap application that allows you to browse information from the 2010 US Census. You can read more about this application and download the source code here. This application supports lots of platforms… iOS, Android, BlackBerry, and web (everything except IE because I was targetting WebKit browsers).
While this application is a mobile app wrapped in the PhoneGap container, I actually didn’t use any PhoneGap-specific libraries, so it was very easy to repurpose as a desktop application. I created an AIR version of this application, which you can download at:
I had to use my Android 2.x branch of the US Census Browser code because the WebKit instance inside of AIR doesn’t support SVG. I also changed the container scrolling to use normal CSS “overflow: auto” instead of using iScroll for touch-based scrolling. There were a few other one-off CSS changes to tweak the layout in the AIR web container, but otherwise the code is identical.
You just need to create an AIR application XML file and point it to your HTML content, and then package it using ADT.
If you were using PhoneGap APIs, you would have to migrate your code to take advantage of AIR APIs, but all other HTML/CSS/JS could be reused with minimal changes.
Even though I used AIR for this example, AIR isn’t the only game in town for HTML-based desktop applications… There’s an open source project called MacGap, you can use HTA for Windows, and it’s not hard to write a HTML/Web View wrapper for any platform. It’s even been reported that you are going to be able to write apps for Windows 8 purely using HTML & JS, and you would be able to repurpose your code for this as well.
You can check out the AIR version of the US Census Browser at:
While looking at the analytics for my blog, I’ve recently started to see a lot of search phrases similar to “what is phonegap?”, “how does a phonegap app look?”, “how to get started in phonegap?”, among many, many others. In this post, I hope to shed some light on some basic questions to help you understand and start working with PhoneGap.
In case you don’t feel like reading the whole thing, here are quicklinks to each question:
PhoneGap is an application framework that enables you to build natively installed applications using HTML and JavaScript. The easiest way to think of PhoneGap is a web view container that is 100% width and 100% height, with a JavaScript programming interface that allows you to access underlying operating system features. You build your user interface using traditional web development skills (HTML, CSS, & JavaScript), and use the PhoneGap container to deploy to different application ecosystems and devices. When packaged for deployment, the PhoneGap application is a binary distributable file that can be distributed by the “normal” application marketplaces (iTunes, Google App Market, Amazon Market, etc…).
PhoneGap can be used to build applications that target multiple platforms, including Apple iOS, Google Android, Windows Phone, BlackBerry, HP WebOS, Symbian, and Bada.
Since the UI rendering engine is the mobile device’s web browser, PhoneGap applications can literally look like anything. You can use standard HTML & CSS to make it look like a normal web page, you can use a UI framework like jQuery UI, Kendo UI, Sencha, Twitter Bootstrap, or Skeleton (or any other HTML/CSS/JS user interface framework). You can also use CSS styles/themes to make your web content look like native apps, such as iUI to mimic iOS or Android, or bbUI to mimic BlackBerry.
PhoneGap applications can have static UIs based on normal HTML, or can have dynamic & interactive experiences developed using JavaScript. It depends upon the specific application, user experience design, target audience, and use cases to dictate how a PhoneGap application will appear.
PhoneGap applications can use pinch/zoom gestures to zoom in & out, or you can lock the viewport scale using the viewport metadata tag. You can have the page scroll using normal browser behaviors, or you can use a library like iScroll to enable touch-based scrolling of specific container elements.
There really are lots of ways to create a user interface with HTML, CSS & JavaScript, so there really isn’t any “typical” look. If you do not apply any CSS styles at all, then all user interface elements will use the operating system/browser default for that specific platform. This includes buttons, links, and color/highlight states. This behaves in the exact same manner as the operating system’s default web browser.
How do I get started in PhoneGap?
Getting started in PhoneGap is easy. For 90% of a PhoneGap application, all you need is a text editor. PhoneGap also integrates with device-specific development environments very easily. You can view “getting started” guides for all application platforms at the links below:
When developing PhoneGap applications, just keep in mind that you are running code inside of a web browser instance. You develop your applications using HTML and JavaScript, not native code, so you don’t need anything special. In fact, I personally do most of my development on the desktop using an HTML editor and the Chrome browser. When I need device-specific functionality, or I need to test on a device, then I switch over the the device-specific environments.
How do you debug PhoneGap applications?
Debugging PhoneGap applications can sometimes be the trickiest part of development. If you are testing on a physical device, you can’t always get access to JavaScript exceptions when they happen. There are a few strategies for debugging PhoneGap applications.
Develop as much as possible on the desktop browser
Since PhoneGap applications are written with HTML, CSS, and JavaScript, you can develop most of them using any HTML editor and debug them within a desktop web browser. The latest versions of all major web browsers (including Chrome, IE, Firefox, Opera and Safari) provide rich debugging features. In the developer tools for the browsers, you can inspect HTML DOM elements, inspect CSS styles, set breakpoints in JavaScript, and introspect into memory & JavaScript variables. You can learn more about the desktop browser development tools at:
Once you build the main aspects of your application using desktop tools, you can switch over to a device-specific environment to add device-specific behavior and integrate with PhoneGap APIs.
It is imperative that you test your applications on actual devices! Actual devices will have different runtime performance than desktop browsers and simulators, and may unearth different bugs/issues including API differences and different UX scenarios.
Debug With debug.phonegap.com
PhoneGap provides a hosted service that allows you to perform remote, on-device debugging through debug.phonegap.com. This uses the Weinre (Web Inspector Remote) debugging tool to allow you to remotely inspect the DOM, resource loading, network usage, timeline, and console output. If you have used any of the developer tools listed above, this will look very familiar. You will not be able to set breakpoints on the mobile device, but it is certainly better than nothing at all.
Remote Web Inspector Through iOS 5
There is a little known undocumented API introduced in iOS5 that allows you to perform remote debugging through the iOS5 Simulator. You just need to enable remote debugging
Then launch the application in the desktop iOS Simulator. Once the app is running, open a local Safari instance to: http://localhost:9999/. This will launch the remote debugger, complete with breakpoints and script introspection.
You generally architect PhoneGap applications the same way that you create mobile web experiences. The difference is that the initial HTML assets are available locally, instead of on a remote server. The PhoneGap application loads the initial HTML, which can then request resources from a server, or from the local environment. Since PhoneGap is based in a browser, it behaves exactly as you would expect a web browser to behave. You can load multiple pages; however, keep in mind that once you load/unload a page you may lose any data that is stored in memory via JavaScript. PhoneGap also supports the single-page web experience model. I strongly suggest using the single-page architecture approach.
Single-Page Architecture
A single-page architecture refers to the practice of having a single HTML page that dynamically updates based upon data and/or user input. You can think of this as closer to a true client/server architecture where there is a client application (written with HTML & JS) and a separate server structure for serving data. All client-side application logic resides in JavaScript. The client application may request data and update its views without reloading the current web page.
Using a Single-Page architecture allows you to maintain data in-memory, in JavaScript, which allows you to have a stateful, yet dynamic user interface. You can read more about single-page architectures at: http://en.wikipedia.org/wiki/Single-page_application
How do you get PhoneGap apps on devices and into application ecosystems?
PhoneGap applications can be deployed using the same guidelines for native applications for each given platform. You must follow the rules of each hardware platform/vendor, and there is no way to get around that. You can compile the executables for each platform yourself using each platform’s specific build process, or you can use build.phonegap.com to compile them for you. build.phonegap.com is a hosted service that will compile platform-specific application distributable files for you. In either case, the output of the build process is a platform-specific binary file: IPA for iOS, APK for Android, etc… You can read more about distributing to various application ecosystems, and each system’s signing/certificate requirements at:
The most fundamental differences between PhoneGap and AIR is that you develop AIR applications using tools rooted in the Flash Platform (Flex, Flash, ActionScript, MXML), and you develop PhoneGap applications using HTML, CSS, & JavaScript. AIR applications use the AIR runtime, which allows you to have a single code base, with the exact same expected behavior across all supported platforms. PhoneGap applications run inside of the native web browser component for each supported platform. For this reason, a PhoneGap codebase may behave slightly different between separate platforms, and you will need to account for this during your development efforts.
Air applications can be built for iOS, Android, BlackBerry Playbook, and the desktop (mac and windows), with future support for Windows Metro (Windows 8 mobile interface). You can read more about AIR’s supported platforms at: http://www.adobe.com/products/air/tech-specs.html
PhoneGap applications can be built for iOS, Android, BlackBerry, Windows Phone 7, HP WebOS, Symbian, and Samsung Bada. You can read more about PhoneGap’s supported platforms at: http://phonegap.com/about/features
ActionScript has strongly-typed objects and supports classical inheritance programming models. AIR applications can also be built using the Flex framework, which allows you to rapidly build enterprise-class applications. Components in AIR applications are logical objects that have behaviors, properties, and a graphics context.
JavaScript-based applications support prototypal inheritance, and have numerous open-source frameworks/tools that can be used. HTML/JS applications are all visualized through HTML DOM elements. HTML interfaces can be created through basic string concatenation or JavaScript templating, but in the end you are really just creating DOM elements that have properties and styles.
There are some fundamental difference in the syntax of building these applications, however the basic concepts of interactive design and interactive development are identical. Both platforms have valid strengths, which I could write about ad nauseum… I’ll save that for another post.
Here’s a silly/fun app I built ‘after hours’ using PhoneGap. It is a children’s drawing app built entirely with the HTML5 Canvas element, using a PhoneGap wrapper, targeting the iPad. I was inspired by magnetic drawing toys that I often use when drawing with my daughter, and this was really, really easy and a lot of fun to build. I used the exact HTML5 Canvas brush image/sketching technique that I have previously demonstrated – the only change is that I added the new UI style elements and added support for multiple touch points. Otherwise, the drawing logic is identical.
Lil’ Doodle is a great new iPad application for entertaining both you and your children! If you know how to use a children’s magnetic drawing toy, then you know how to use Lil’ Doodle. Pick a “pen” shape, and start doodling. Your imagination is your only limit. If you want to erase everything and start over, just use the slider at the bottom. Doodle and have fun!
Using the HTML5 Canvas inside of PhoneGap has great performance on iOS, and building the application using purely HTML, CSS, and JavaScript made it incredibly simple. After I wrote the core drawing engine for a previous blog post, I whipped up the UI in one evening, and then started user testing with my little beta tester. She found some issues that I had overlooked, and a few days later I submitted it to the app store.
…and yes, she really does play with it:
The app is currently available for iPad devices on iTunes – I’m about to start researching/testing performance on other platforms, so maybe soon it will be out in other ecosystems… we’ll see. You can get it now at:
Before I go too far, let me attempt to clearly state what PhoneGap is… PhoneGap is an application container technology that allows you to create natively-installed applications for mobile devices using HTML, CSS, and JavaScript. The core engine for PhoneGap is also 100% open source, under the Apache Cordova project. You can read more about PhoneGap under my “What is PhoneGap?” & Other Common Questions post.
Recent Comments