However, I also discovered that starting with PhoneGap 1.5 (release notes), a new key was added to the PhoneGap.plist (now Cordova.plist) called UIWebViewBounce.  It’s set to YES by default (I have no idea why).  If you set it to NO, your app will be anchored in with nails and the bounce removed.

This is also now configurable with PhoneGap Build by setting webviewbounce to false in your config.xml (documented here).

Last week, I tried a variation of this at a Tampa meetup with an audience of about 100 people and it worked really well.  Late  Friday night, I created Phraffle (phone + raffle = Phraffle!) — http://phraffle.com.  It’s obviously a very simple and somewhat silly app, but it was fun to build.  It was also my first use of TypeKit (font used in the logo).  The spinning effect is based on a blog post I found by Saurabh Odhyan.  He basically pans an image across a div using JQuery.spritely.  Once the speed increases, the image is switched to a blurred version.   I loved the effect so I took his example and made some modifications until I had the right look and feel.

Let me know if you have any ideas on how to improve this or if you have seen other interesting ways of handling raffles.  I might create a tiny app for phones/tablets for off-line use-cases.  It all depends on how bored I get next weekend.

• Tampa —  5/9/2012 6:00PM please RSVP on the site – if it’s full, try again later in the day
• Orlando —  5/8/2012 6:00PM EDT at Full Sail University – DONE – Had a packed room and over 35 online!

Even if you have looked at PhoneGap already, we’re going much deeper than an introduction.  We’re going to show how to build production-quality, high-performing apps using HTML and JavaScript.  This goes well beyond the typical demos.  Micro-frameworks such as backbone.js, twitter boostrap and more will be used.

The folks at Full Sail University put together a poster for the Orlando event (see below).  Now I feel like we need some sort of cool music playing when we enter the room!

To give you a sense of the activity levels, here are a few ChessJam stats:

• At any time, day or night, there is an average of 100 users logged in playing chess.  We’ve seen it as high as 180 concurrent on weekends.
• Our average load is about 2 or 3 chess moves per second.
• During the month of March, 2012, more than 4,500 users played 128,920 games (5.8 million moves in one month)

Not bad for no marketing budget I think.  It’s not a huge amount of activity compared to a lot of applications, but the performance demands are very high. Serious chess players don’t tolerate delays in response time, so we have to make sure we have plenty of CPU and bandwidth to spare.

Hosting history:

Late 2009/Early 2010 — development and early production – hosting from my home office

During development and the first few months of production, ChessJam was hosted from a computer in my home office.  The cost was around $70/month for FiOS fixed IP address plus whatever power my server was drawing. This was fine until the Florida summer storms took out my power twice in a single month. That’s when we realized the difference between a real data center and my personal data center! It was also a bit stressful when I traveled because it left my wife in charge of late-night server repairs.

Late 2010 — moved to rack mounted servers in a real data center

We acquired two used (circa 2008) rack-mounted IBM servers and rented some rack space at a local data center.  Reliable power and Internet were no longer a problem, but the hardware was ours to manage and eventually repair.  It was better, but it wasn’t a great situation. Once we settled in, our cost was around $190/month (rack space rental and bandwidth).

Why didn’t we move to Amazon EC2 instead of the data center?  We did consider moving from my home office to Amazon EC2 instead of the data center, but at the time, Amazon didn’t have an instance type that suited us.  The small instance type was affordable, but it only offers 1.7GB of memory, which just won’t cut it for our server app (we tried). The next step up was the large instance type with 7.5GB of memory, but it was too expensive and overkill.

Two months ago, Amazon filled the huge gap between the small and large instance type by announcing the new “medium” instance type. It provides 3.75GB of memory as well as a decent amount of CPU for a good price… so we decided it was time to make the move.

Our EC2 configuration:

• Medium EBS instance running Ubuntu Linux.  EBS is “Elastic Block Store”, which basically means that the storage is persistent.  If you haven’t looked at EC2 in the past two years, you might not know that persistent storage on server instances is an now an option.  With EBS storage, you can shut down your server and all of the data is saved (just like a physical server).
• 200GB EBS disk volume – for our MySQL database and fast growing log files.

AWS and bill anxiety

Most people exploring Amazon EC2 ask the same question I asked… “What is this really going to cost me?”. When you dig into how EC2 is priced, you’ll find that there are multiple variables, which creates a bit of uncertainty. Basically, it boils down to the server instance type, the disk space used, and the amount of data moved in and out of the instance. There are other small charges for number of I/Os and any unused IP addresses, but these are typically only a few cents and don’t have much impact on the final bill (based on my experience).

• The server instance — this one is easy and predictable. Amazon charges by the hour. For example, our medium instance is $0.16 per hour. You could fire up a medium server instance and spend a full 8 hour work day playing with it and only pay about $1.30. Not bad! Our app runs 24/7 so 24 hours per day * 30 days = 720 hours per month. So, our monthly cost can be calculated with $0.16 * 720 = $115/month.  (later in this article, I explain how reserved instances work and how they can lower this price by nearly half)
• Disk volume – this one is also easy and predictable as well. It cost $0.10 per GB per month. We have a 200GB volume, so that’s 200*$0.10 = $20/month.
• Disk I/Os — The EC2 pricing page also shows a $0.10 charge per million I/Os. We do about 300,000 I/Os per day (based on my last bill) so that comes to about 9 million I/Os per month resulting in less than $1/month… so we’ll just call that a rounding error.
• Data transfer charges — this is the part that scared us. Amazon charges $0.12 per GB of data transferred out of our EC2 instance. They do not charge for inbound traffic. This method of charging for data is very different than how our data center charges us. The data center uses “95th percentile peak billing” which means we are charged based on the average rate that we move data, not the volume of data moved. I’ll spare you the details, but it doesn’t translate to Amazon’s model. However, our data center provider does have a report that shows the total amount of data transferred each month and we used that number to estimate. Now that we’ve been up and running a few days, I know that we transfer about 250MB of data every hour or 6GB of data per day. So, 6GB * 30 days * $0.12 = $21/month.

Summary: $115.20/month for our server instance, $20/month for our disk volume and $21/month for data transfer which comes to about $156.20/month. That’s already about $30 less than we were paying the data center.  That price is already lower than what we were paying… but with reserved instances, we can lower it considerably.

Saving money with reserved instances

A lot of companies use Amazon EC2 in a much more “elastic” fashion than ChessJam does.  They set up load balancers and auto-scaling to dynamically increase and decrease instances based on the load. However, our app is not nearly that sophisticated (although eventually our usage may justify re-architecting our back end!).  Our app uses a consistent amount of EC2 resources.  Thankfully, Amazon offers special pricing for this type of use-case called reserved instances. Reserved Instances give you the option to make a one-time payment for each instance you want to reserve and in turn, receive a significant discount on the hourly charge for that instance. Basically, Amazon is rewarding you for being predictable. There are three different options, light utilization, medium utilization, and heavy utilization. Our server is up and running 24/7, so our best deal is the heavy utilization model.

I reserved a medium instance for one year by paying an upfront fee of $390. Now, instead of paying $0.16 per hour, we pay $0.032 per hour (just over 3 cents!).  Some simple math shows the savings:

• With a normal “demand instance”, we paid $0.16 per hour * 24 hours per day * 365 days per year resulting in a yearly cost of $1,401.60 (plus disk, I/O, transfer)
• With the reserved instance, we paid $390 up front and then $0.032 per hour * 24 hours per day * 365 days per year resulting in a yearly cost of $670.32 (plus disk, I/O, transfer)

Bottom line cost including disk, data, etc.

• We paid around $2,280 a year to the data center.
• We now pay $1,160 a year to Amazon EC2 – saving us over $1,000 per year (not counting any hardware costs we could have incurred).

There are two smaller instance types – micro and small.  You might can get by far cheaper for your app/site.  With reserved instance pricing, you can get a micro instance for about $100 per year!  I currently host 6 low-use websites on a single micro instance (local bagel store, my aerial photo site, etc.).

TIP: If you plan to use Amazon’s micro instances, you should be aware of how they throttle CPU.  It’s unique to the micro instance type.  I blogged about this months ago.

TIP: Amazon’s billing data is updated several times per day, so you can quickly determine what your run-rate is for everything. I was able to project our monthly cost after 24 hours of activity.

We didn’t move to EC2 just to save money

Yes, we’re saving some money – that’s awesome, but to be honest, it’s not the reason we moved.   The real reason we wanted to move to a cloud solution like EC2 is for peace of mind and to prevent us from dealing with a hardware failures.  We had a backup server in the data center, but if there was a failure in the primary server, it would likely result in a 30 minute drive to the data center and a few hours in a cold room moving hard drives from server to server and hoping it all goes well.  It was a precarious situation!  Now, if there is a hardware failure (rare, but they happen on EC2), I simply launch a new instance with a few clicks of the mouse, mount our disk volume to it, tweak a few things, and get us back online.  All of this while watching Big Bang Theory in my PJs!

I know that a few of you IT-minded folks are seeing some holes in my final architecture, and yes, you’re correct. The above scheme doesn’t address a disk volume crash. Disk volume crashes are very rare on EC2, but I do plan to make a few more enhancements to the architecture. I could start up a new instance and use it as a slave server to replicate data from the primary server’s database (MySQL).  I could start this backup instance in a completely different zone, which basically means that it’s in a different physical facility.  This would allow us to quickly recover if Amazon has a massive failure like the one a year ago that brought down several popular sites for a few hours. However, I might go the cheap route and create a 2nd disk volume and use a file system that allows me to mirror the database between the two disk volumes. I think this will be adequate until someone buys us for a $1 billion.

Another option to mention is Amazon RDS (MySQL in the cloud). If we used RDS for our database, it would give us more redundancy and scalability, but for now, we’re going to avoid that cost and stay on the single instance until we grow more.

It may not be for all applications

Our experience with EC2 was very positive, especially with this application.  However, it’s not perfect for all applications.  The server is still “virtual” so the performance is not perfectly
consistent.  Things like disk I/O speed, network bandwidth, etc., is what it is.  You can’t tell Amazon that you need a SSD for your swap drive and 10,000RPM drives for your databases. In other words, you don’t have as many ways to tweak performance as you do by managing your own real hardware.  However, if your app runs well on EC2, why bother with that stuff?!  I personally feel that I’ve served my time in computer rooms during my career.

The rest of the Amazon Web Services world

Everything we’ve talked about in this article has been specific to the low-end instance types of Amazon EC2.  There are many other instance types and other related features including load balancers, auto-scaling, monitoring, automatic alerts, etc.  Also, EC2 is only one of many services offered by Amazon.  Check them all out at http://aws.amazon.com/.

Check it out for free

Amazon recently started offering a “free tier” for EC2 newbies. You basically get a year free of a micro instance along with some disk space and bandwidth. See http://aws.amazon.com/free for more details. Remember – you can resize instances anytime. It’s very common to use a micro instance during development, and then upgrade as needed when you go live.

May 2012 table of contents:

• CSS Regions and CSS Exclusions, by Deepa Subramaniam
• Drag and drop with jQuery UI on mobile devices, by Michaël Chaize
• JavaScript Object Creation, by Keith Peters
• Using Backbone with jQuery Mobile, by Christophe Coenraets
• Crafting native looking iOS apps with HTML, by Christophe Coenraets
• Demo of Handlebars, by Raymond Camden
• Real-time data exchange in HTML5, by Ryan Stewart
• Swipe to delete items, by Michaël Chaize
• App-UI, a library by Andrew Trice
• HTML5 Multimedia components, by Ian Devlin
• Interview of Pamela Fox
• Colour Match, Cutest Paw, Bit Timer: showcase
• Which Element ? Pull quotes, comments
• PhoneGap and the File API
• WTFJS: False advertising
• Generate color palettes from HTML5 video
• CSS variables draft
• News

More information at http://appliness.com/download-the-second-issue/

If you are a C++ programmer with a desire to work on a highly visible team that is having a huge impact on the future of the web, it’s time to apply!  You can go to http://adobe.com/jobs and search for the keyword “WebKit” to find the current open positions.  You can also email WebKitJobs at adobe dot com to apply.

This will be a monthly magazine with articles about writing applications using web standards. Some of the articles have interactive content and video.

All of this was done using Adobe Digital Publishing Suite (the same technology used for popular magazines such as Wired, National Geographic, and many more).

Michael Chaize was the driving force behind this and has a blog post with more details. Maile Valentine also played a huge role in the creation of Appliness – THANK YOU BOTH!

One of the challenges in the world of HTML/JavaScript/CSS app development is cobbling together your kitchen sink of frameworks, tools and other technologies. When you start looking around, it feels like there is an endless list of options, which is good and bad!  Recently, I’ve been gathering a list of what’s popular these days and thought it might be useful for others to share. If you see anything obvious missing, please let me know.  Thanks to the following for helping me put together this list: Ray Camden, Andy Trice, Philip Wilson, Christophe Coenraets, Piotr Walczyszyn, and James Brown.

In no particular order:

• Adobe Edge – HTML5/JS/CSS animation/interaction tool - http://labs.adobe.com/technologies/edge/
• Less Framework – CSS grid system/layout - http://lessframework.com/
• Less – alternative CSS syntax – supports OO-like syntax – referenced by Google at Google IO – used in many projects - http://lesscss.org/
• Saas – another alternative CSS syntax – similar to Less - http://sass-lang.com/
• Kendo UI Framework (mobile coming soon) - http://www.kendoui.com/
• Sencha - http://www.sencha.com/ - multiple products – including Sencha Touch, Charts, etc.
• JQuery UI - http://jqueryui.com/
• JQuery (core) - http://jquery.com/
• JQuery Mobile - http://jquerymobile.com/
• xui -minimalist JQuery-like framework - http://xuijs.com/
• zepto.js – minimalist JQuery-like framework - http://zeptojs.com/
• Backbone.js MVC framework for JavaScript - http://documentcloud.github.com/backbone/
• Underscore.js – Kitchen-sink utilities for JavaScript - http://documentcloud.github.com/underscore/
• Modernizr – JavaScript library to detect device features – very popular - http://modernizr.com/
• cubiq.org – home of iScroll, a very popular scroll/list lib - http://cubiq.org/
• appMobi – web-based dev with emulation, etc.  Also has an HTML5-framework - http://www.appmobi.com/
• LeviRoutes - lightweight routes framework for hooking in to HTML5 history - https://github.com/PaulKinlan/leviroutes
• Mustache – “logic-less templates” – mentioned by Google presenters at Google IO - http://mustache.github.com/
• Midori – JavaScript framework – JQuery-like with some unique features - http://www.midorijs.com/
• Knockout.js – JavaScript UI framework – implements MVVM pattern – recommended by Greg’s brother – popular - http://knockoutjs.com/
• AngularJS – MVC framework, two-way data binding, JQuery-compatible - http://angularjs.org/
• JSFiddle – online tool for doing lint/tidy/debugging - http://jsfiddle.net/
• HighCharts – fantastic looking charts - http://www.highcharts.com/
• ZingCharts – HTML5/SVG/VML and Flash charts - http://www.zingchart.com/#welcome
• AMCharts – JavaScript/HTML5-based charts.  They also offer Flash-based charts. - http://www.amcharts.com/javascript/
• HTML5 Boiler Plate – assist with cross-browser issues and other utils - http://html5boilerplate.com/
• Bootstrap, from Twitter - Bootstrap is a toolkit from Twitter designed to kickstart development of webapps and sites. http://twitter.github.com/bootstrap/
• Popcorn.js – HTML5/JS Media Framework - http://popcornjs.org/
• Three.js – JavaScript 3D engine - https://github.com/mrdoob/three.js and http://www.aerotwist.com/lab/getting-started-with-three-js/
• PhoneGap – http://phonegap.com
• PhoneGap Plugins - https://github.com/phonegap/phonegap-plugins
• Require.js – http://requirejs.org - RequireJS is a JavaScript file and module loader
• Brunch - http://brunch.io/ - A lightweight approach to building HTML5 applications with emphasis on elegance and simplicity.

Stuff needed:

• Small Phillips-head screwdriver
• T6 Torx screwdriver (I found one at the local CompUSA as part of a small computer toolkit that cost less than $15)
• New hard drive – in my case, it’s the Intel 320 Series 300GB SATA 3.0 GB-s 2.5″ Solid State drive
• SATA USB Docking station – allows you to access the new hard drive as a USB drive.  There are many alternatives.  I’ve had the Thermaltake BlacX for a couple of years.
• Software to clone hard drives.  There are a few options, but I use Carbon Copy Cloner.  This software is also good for creating bootable USB drive images of your main drive.  In a pinch, you could boot off your USB drive and keep going if your main drive crashes.
• Good directions on replacing the hard drive.  The iFixit site always has good directions.  For my early-2011 MacBook pro 15″, I used this page.

     

1. I cleaned up my existing hard drive.  Since I was downsizing (for the first time in my life!), I had to do some serious space making (long overdue).
2. I plugged my new SSD into the SATA USB Dock and connected it to my computer.
3. I formatted the drive using Disk Utility.  I used the same format as my main drive (Mac OS Extended (Journaled)).
4. I ran Carbon Copy Cloner and set it to copy everything.  This took about 4 hours on my machine.  During that 4 hours, I continued to work knowing that I would be slightly out of sync when the cloning process was complete.
5. After the clone was finished, I shut down Mail, Calendar, Eclipse, Evernote, etc., and ran the clone process again as an incremental update.  This took less than 30 minutes.
6. I then shut down the MacBook Pro, unplugged it and flipped it upside down to start the surgery.
7. I followed the instructions at http://www.ifixit.com/Guide/Installing-MacBook-Pro-15-Inch-Unibody-Early-2011-Hard-Drive-Replacement/5895/1 to swap the drives.  Depending on which model of MacBook you have, you may need to find alternative instructions.  For the early 2011 MacBook Pro 15″, it’s a piece of cake.  The only nervous moment was getting the bottom panel to snap off.  It takes some gentle prying.  Everything else was easy.  Since I was only replacing the hard drive, I skipped the step about disconnecting the battery.  (Do this at your own risk)
8. I put everything back together and booted it up.
9. After it was up and going, I turned off the hard drive sleep feature in SETTINGS, ENERGY SAVER (uncheck the “Put the hard disks(s) to sleep when possible” on both BATTERY and POWER ADAPTER).
10. All modern MacBooks have sudden motion sensors that halt the hard drive when motion is detected to save the drive heads.  Since this is a solid state drive with no moving parts, I turned off this feature using the following command in terminal: sudo pmset -a sms 0
11. I then went to disk utility and verified the disk, and ran the repair permissions function.  This is always a good idea after doing any drive swap.

• diskutil eject /dev/disk1  – ejects my 2nd hard drive which forces it to power down.  The drive is then unavailable until you remount it using the following command.
• diskutil mountDisk /dev/disk1  — mounts the drive again.

The OWC Data Doubler:

Simply modify the main Java Class of your PhoneGap Android project and set the loadInWebView property to true – then simply load your content using http:// instead of file://. If you try using http:// without setting the loadInWebView property, it will open the page in the device’s browser and your code won’t have access to the device APIs.

For example:

package com.gregwilson.gregpg1;

import com.phonegap.*;

public class GregPG1Activity extends DroidGap {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        super.setBooleanProperty("loadInWebView", true);
        super.loadUrl("http://somewebsite/index.html");
        //ORIGINAL--> super.loadUrl("file:///android_asset/www/index.html");
    }
}

Since the web content is loaded and executed in the PhoneGap container, you can use any PhoneGap JavaScript APIs you desire just as if the code was loaded from the device. A few thoughts:

• This could actually speed up parts of the development workflow because now I can simply modify the HTML/CSS/JS and reload the page (once I add a reload button!). It avoids having to deploy the app over and over.
• This opens up a huge security hole. Imagine if someone could hack your web server and inject some new JavaScript. Since the JavaScript executes on the device, in the PhoneGap container, it could easily extract or delete your contacts, determine your location and many other devious things. Therefore, I would NOT recommend doing this for anything other than testing.
• There might be some interesting hybrid apps where some of the content is sourced from the server while other content is on the device, but I’m fairly sure this would not be a “best practice” without further code changes to avoid the security issues.
• Assuming this is possible on iOS, I’m fairly certain that your app could be rejected since you are loading external code (a no-no in iOS-land).

I’m not a PhoneGap expert (yet!), so feel free to correct me. I’m basically blogging as I learn!

The PhoneGap announcement at MAX 2011 really got a lot of people excited (including me!), and it raised a few questions about how it changes our jobs as evangelists.  PhoneGap gives us the means to build cross-platform apps with HTML5 with hooks into the device’s native APIs (see my previous post).  Having new things to show off to developers and customers is always a good thing, especially when this new thing lets us stretch our new HTML5 muscles on mobile devices.  I’m already playing around with using Adobe Edge to animate some interactions in a mobile app (stay tuned!).

As a technical evangelist talking to developers, having PhoneGap in my arsenal removes the  ”HTML vs Flash/Flex” religion  from the discussion and allows us to have a real conversation about which technology is the best solution for the requirements at hand.

Here’s an analogy:  If I worked for a company that sells tile flooring, it would be tough for me to convince someone that tile is the best choice for a particular room because they will expect me to say that tile is best for everything.  Conversely, if I worked for a company that sells wood flooring, they expect me to say wood is best.  However, if I work for a company that sells both types of flooring, I can have a real discussion about which is best on a room by room basis because I will have credibility in both types of flooring.

Now the conversation starts at a higher level and allows me to be more effective at demonstrating the value that Adobe offers to anyone building mobile apps.

There are clearly use-cases where PhoneGap will indeed be the better choice because of the lightweight nature, broader device support and the availability of the required skillset to build these types of apps.  However, there will continue to be use-cases that go beyond the capabilities of HTML5 and will demand the more capable Flash/Flex platform.  Features such as collaboration, complex UIs, handling of large data sets, real-time data processing, and rich data visualization are just a few examples where HTML5 simply won’t cut it today.  However, as the capabilities of the platforms evolve, Adobe is in a good position to provide solutions across the spectrum.

Our team is in rapid learning mode now, but that’s why we do this job.  New products, new technologies and new ways of approaching problems is what fuels us.  We’re basically professional learners.  During the next few months, you’ll see more content related to PhoneGap as well as the new features coming in Flex 4.6, and much more.  Fun, fun!

Since I’m more familiar with Android than iOS, I’ll explain how it works for Android.

First, you create a new Android project in Eclipse (requires the Android SDK), add the phonegap.jar file to the lib folder, and make a few tweaks to the manifest and other files (details here). The main java file is modified as follows:

package com.gregwilson.gregpg1;

import com.phonegap.*;
import android.os.Bundle;

public class GregPG1Activity extends DroidGap {
    /** Called when the activity is first created. */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        super.loadUrl("file:///android_asset/www/index.html");
    }
}

Notice the highlighted line (line 11) —  We’ve created a native Android app, and this native app loads android_assets/www/index.html in WebView when launched.  WebView is a class in the Android SDK that allows you to display web pages as a part of your layout.  It’s like having a web browser inside of your app and uses the device’s existing implementation of WebKit.  In iOS, it’s UIWebView.  Other mobile OSes use similar techniques.

Below is my project in both Eclipse (Android) and Xcode (iOS).  The web application is in the www folder indicated by the red arrows.

Now you simply compile, build, deploy like any other Android project.

Basically, PhoneGap apps are HTML/JS/CSS apps that run within the WebView (or equiv) component. If you are like me, at this point you are thinking, “Uh – that’s lame – is that it? I can do that today without any additional software”.

But there’s more… PhoneGap extends the WebView class to give it hooks back to the device itself and exposed them as JavaScript.  Remember the jar file that is in the project?  The project also includes a phonegap.js file, which exposes many new functions that make this much more than simply displaying a web page in a WebView component.

Check out the code below for accessing the device GPS (copied from one of the many great examples from http://docs.phonegap.com).  If you create an PhoneGap project and copy the code below to your index.html file, you can see it run.

<!DOCTYPE html>
<html>
  <head>
    <title>Device Properties Example</title>

    <script type="text/javascript" charset="utf-8" src="phonegap.js"></script>
    <script type="text/javascript" charset="utf-8">

    // Wait for PhoneGap to load
    //
    document.addEventListener("deviceready", onDeviceReady, false);

    // PhoneGap is ready
    //
    function onDeviceReady() {
        navigator.geolocation.getCurrentPosition(onSuccess, onError);
    }

    // onSuccess Geolocation
    //
    function onSuccess(position) {
        var element = document.getElementById('geolocation');
        element.innerHTML = 'Latitude: '           + position.coords.latitude              + '<br />' +
                            'Longitude: '          + position.coords.longitude             + '<br />' +
                            'Altitude: '           + position.coords.altitude              + '<br />' +
                            'Accuracy: '           + position.coords.accuracy              + '<br />' +
                            'Altitude Accuracy: '  + position.coords.altitudeAccuracy      + '<br />' +
                            'Heading: '            + position.coords.heading               + '<br />' +
                            'Speed: '              + position.coords.speed                 + '<br />' +
                            'Timestamp: '          + new Date(position.timestamp)          + '<br />';
    }

    // onError Callback receives a PositionError object
    //
    function onError(error) {
        alert('code: '    + error.code    + '\n' +
              'message: ' + error.message + '\n');
    }

    </script>
  </head>
  <body>
    <p id="geolocation">Finding geolocation...</p>
  </body>
</html>

Now your “web app” has access to Accelerometer, Camera, Compass, Contacts, and many other device capabilities.

Some observations:

• Since the app itself is super small, it loads crazy fast – less than one second on my HTC Inspire and iPad 2.  You probably won’t even need a splash screen.
• The framework is simple and lightweight, so the resulting app has a very small memory footprint. This allows apps to work on older and slower hardware like the original iPhone and older BlackBerry phones.
• The PhoneGap docs and examples are fantastic – clear and concise.  I was able to copy/paste every sample and see the results. (one note — the phonegap-1.1.0.js for Android is different than the phonegap-1.1.0.js for iOS – I initially made the mistake of assuming they were identical and killed a few hours trying to figure out why certain samples wouldn’t run)
• The platform support is broad. As of this article, PhoneGap supports iOS (iPhone, iPhone 3G/3Gs/4/4S, iPad 1/2, Android (all versions), BlackBerry OS 4.6 and newer, WebOS, Symbian, Bada and they have recently started to support Windows Mobile. See http://www.phonegap.com/about/features for a list of what’s supported on each.
• Your HTML/JS/CSS run in the native WebView so you are free to use any frameworks you desire such as JQuery Mobile, Sencha, whatever. PhoneGap gives you a WebView/UIWebView with hooks to the device. The rest is up to you.
• PhoneGap is free, open-source and will become an Apache project very soon (translation – it will remain free).
• PhoneGap is extendable via a plugin model giving you a bridge between native code capabilities and JavaScript.
• There is already a great collection of community-created plugins at https://github.com/phonegap/phonegap-plugins.
• I haven’t figured out a good way to debug these types of apps yet.  I suspect that this will be a bit of a challenge.  There is a console.log() function that will send messages back to your Eclipse console.  When the camera sample wasn’t working, I really had no clues as to why.  It’s likely that I’m missing something, so it’s too early to judge.

PhoneGap Build

As you start building mobile apps in any technology, you soon discover that each platform has it’s own deployment steps and tooling requirments (some of which are amazingly tedious and error-prone).  For example, to build a native iOS app, you use Xcode, which only runs on Mac OS X.  To build for BlackBerry phones, you have to use their tooling that only runs on Windows.  To build for both platforms, you’ll need two machines (or use virtualization).  This is why http://build.phonegap.com was created.  The service allows you to upload your www project folder (or give it a GitHub URL) and it will package your app for the supported platforms.  The specific steps are documented at https://build.phonegap.com/docs/start.  NOTE: Adobe has stated that this service will continue as part of the recently announced “Adobe Creative Cloud” but no details have been provided nor has any pricing been announced.

What’s next

If you’re intrigued, I encourage you to go to http://phonegap.com, where you’ll find everything you need to build an app. I was able to get a Hello World app running on both Android and iOS in under 30 minutes (not counting the downloading of Xcode).  The “Getting Started” section is excellent.

…but then when you turn it landscape, you get the white borders (or whatever your app background color is):

…so you change the splashScreenScaleMode property to “stretch” and you get this (destroys the image):

…so then you start looking into how to include multiple splash screens, which requires a custom preloader and additional image work.

Below is the same splash screen, but as you can see, I used a single square image that works with both orientations.

What about handling multiple device sizes? The same technique works, as long as you keep the content within the center square that has a width/height equal to the short side of the smallest device you intend to install on.

Below are two images; one for tablets, and one for phones. I’ve drawn the portrait and landscape edges of several popular devices.

Tablets:
The largest tablet I’ve seen is the Motorola Zoom and Samsung Galaxy Tab 10.1, both of which are 1280×800, so my diagram below assumes that it is the largest possible resolution by making the splash screen image 1280×1280:

Click for full-size

Phones:
Phones come in many resolutions. The image below assumes that the largest resolution is 960×640 (iPhone 4), so the image is 960×960:

Click for full-size

Depending on your splash screen design, you could get away with only two images, one for tablets and one for phones. I typically do three images, one for the low-resolution iPhone 3Gs, one for other phones, and one for tablets.

If you are building an app that targets multiple device resolutions, I suggest you use the code below as your preloader. It assumes three images – tablet, high-res phones, low-res phones. It selects the image based on the length of the longest edge of the screen.

// Based on original DPI-based code by Jason San Jose at http://www.adobe.com/devnet/flex/articles/mobile-skinning-part2.html#articlecontentAdobe_numberedheader_5
// Improved by Christophe Coenraets to select image based on length of longest edge of device - http://coenraets.org
// Simplied by Greg Wilson to use only 3 images for all devices
package
{
	import flash.desktop.NativeApplication;
	import flash.display.NativeWindow;
	import flash.display.Stage;
	import flash.display.StageAspectRatio;
	import flash.display.StageOrientation;
	import flash.system.Capabilities;

	import mx.core.DPIClassification;
	import mx.core.mx_internal;

	import spark.preloaders.SplashScreen;

	use namespace mx_internal;

	public class MultiDPISplashScreen extends SplashScreen
	{
		[Embed(source="assets/splash-tablet.png")]
		private var SplashImageTablet:Class;

		[Embed(source="assets/splash-high-phone.png")]
		private var SplashImageHighPhone:Class;

		[Embed(source="assets/splash-low-phone.png")]
		private var SplashImageLowPhone:Class;

		public function MultiDPISplashScreen()
		{
			super();
		}

		override mx_internal function getImageClass(dpi:Number, aspectRatio:String):Class
		{
			var min:int = Math.min(Capabilities.screenResolutionX, Capabilities.screenResolutionY);

			if (min > 960)
				return SplashImageTablet;
			else if (min > 320)
				return SplashImageHighPhone;
			else
				return SplashImageLowPhone;
		}
	}
}

Problem: After updating to OS X Lion, I noticed that the fans were spinning constantly and my battery was being quickly drained.  A quick look at the activity monitor showed a process called VShieldUpdate.

VShieldUpdate is a virus scanning app that is part of VMWare Fusion.  For some reason, the updater for this app gets hung after updating to Lion.

Solution:  Uninstall it with the following commands (from Terminal):

After a couple of seconds, life returns to normal. My VMWare images might be missing some virus protection, but for me, that’s not a problem.

I had WiFi on this flight... Cloud Computing?

During the past year, I’ve learned a lot about various cloud computing offerings including Amazon EC2 / S3 / CloudFront / Beanstalk / RDS / etc., Rackspace Cloud, Salesforce.com, Cloud Foundry, Heroku, and of course, the growing number of Adobe cloud-related offerings.  I’ve also learned that “cloud” is probably the most overused word I’ve come across in 20+ years in technology!  I’ve put together a crash course MAX session to introduce people to what cloud computing is really all about.  My goal is to use only a few slides and spend most of the session doing some real demos that really show off what’s cool in cloud computing.   It’ll be action packed, so come check it out!  The information is below:

When: Wednesday, October 5, 11:00 a.m. – 12:00 p.m, I’m doing the following session at Adobe MAX 2011

Migration to the Cloud: How Do I Get There?

Cut through the hype and see what cloud computing is really all about. Take a tour of cloud infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS) solutions. Watch a live deployment of a server infrastructure that supports a new mobile app built with Adobe Flex. Learn how to create a new virtual server, configure it, and bring it online—all in a few minutes. Then see how the infrastructure is horizontally scaled to support 1,000,000+ users. During the demonstration, you’ll learn about reliability, redundancy, disaster recovery, geographic distribution, and other important considerations for migrating to the cloud.

CODE:

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009"
			   xmlns:s="library://ns.adobe.com/flex/spark"
			   applicationComplete="init()">

	<fx:Script>
		<![CDATA[
			import flash.sensors.Geolocation;

			protected var geo:Geolocation;
			protected var geoLastEvent:GeolocationEvent;
			protected var geoCheckCount:int;
			protected var geoTimer:Timer;

			protected function init():void
			{
				log.text = "App Starting\n";
				if(Geolocation.isSupported)
				{
					geoCheckCount = 0;
					geo = new Geolocation();
					geo.setRequestedUpdateInterval(500); 		// suggest a very frequent update of 500ms
					geo.addEventListener(GeolocationEvent.UPDATE, onUpdate);

					// Create a timer
					geoTimer = new Timer(30000,1);
					geoTimer.addEventListener(TimerEvent.TIMER_COMPLETE,onTimeout);
					geoTimer.start();
				} else {
					log.appendText("GPS not supported on this device\n");
				}
			}

			protected function onUpdate(event:GeolocationEvent):void
			{
				++geoCheckCount;
				if(geoCheckCount <= 1) return; // Throw away the first location event because it's almost always the last known location, not current location
				geoLastEvent = event;

				if(event.horizontalAccuracy <= 150)
				{
					geoTimer.removeEventListener(TimerEvent.TIMER_COMPLETE,onTimeout);
					geoTimer.stop();
					log.appendText("LOCATION: " + event.latitude + " / " + event.longitude + " - " + event.horizontalAccuracy + "\n");
					geo.removeEventListener(GeolocationEvent.UPDATE, onUpdate);
					geo = null;
				}
			}

			protected function onTimeout(event:TimerEvent):void
			{
				geoTimer.removeEventListener(TimerEvent.TIMER_COMPLETE,onTimeout);
				geoTimer.stop();
				geoTimer = null;
				if(geoLastEvent != null)
				{
					log.appendText("Timed out - best location is: " + geoLastEvent.latitude + " / " + geoLastEvent.longitude + " - " + geoLastEvent.horizontalAccuracy + "\n");
				} else {
					log.appendText("Unable to determine location before timeout\n");
				}
				geo.removeEventListener(GeolocationEvent.UPDATE, onUpdate);
				geo = null;
			}

		]]>

	</fx:Script>
	<s:TextArea id="log" width="100%" height="100%"/>
</s:Application>

Geolocation object

There are two classes that you need in order to implement location in your app – Geolocation and GeolocationEvent. When you create a Geolocation object, it turns on the GPS sensors on the device and provides you with a couple of important properties: isSupported and muted.  The isSupported property is used to determine if the device has location support. If you run this on your desktop computer or on a Barnes and Noble Nook, this property will be false because no location capability exists on the device. The muted property is slightly different. This property indicates whether the user has turned off location support for the device or denied permission for the app itself.

iOS muted BUG: There is a known bug with the muted property on iOS devices with the SDK that ships with Flash Builder 4.5.1. On iOS, the Geolocation muted property is always true, so it should be ignored in the current version. This is already fixed in the next release.

There is one method to be aware of on Geolocation — setRequestedUpdateInterval() — it’s used to request a more (or less) frequent location update event. In other words, you are telling the Geolocation object to check for location changes more (or less) often. However, it’s important to note that the OS may choose a different interval to conserve battery power. The name of the method should actually be setRequestedUpdateIntervalPLEASE() because you are only requesting the interval, not commanding it.

GeolocationEvent object

After adding an event listener to the Geolocation object to receive location change events, you will start receiving location events in your event listener. The event contains the latitude, longitude, accuracy, speed, altitude, and heading. Here’s some important facts about location events:

• The first location event received is usually NOT the current location. It is often the “last known location” or the cached location. Your app will get this first event almost immediately, but remember, it might be an out of date location along with the associated out of date accuracy. For example, I created a simple test app that logged my location. I ran it from home and let it run for a few seconds until I was getting good accuracy of about 10 meters. I shutdown the app and drove 10 miles away and ran it again. I immediately received a location event that was the location of my house with an accuracy of 10m! If you don’t know to expect this, your app could make a bad conclusion about the location. Also, the timestamp is no help here (contrary to popular belief). I talked to the Flex engineering team to confirm this. The documentation will be updated shortly. In my opinion, it’s a bug until documented. Once documented, it’s actually a cool feature.  One of the apps I’m working on has a “I am here” button that captures the current location and sends it to the server.  In my code, I ignore the first event.  The second location event is a real attempt to report my current location.  I’ll share the full code of this in the next blog post.  UPDATE: Docs will be fixed soon.
• verticalAccuracy is always wrong in my testing (Android) — There are two properties related to location accuracy – horizontalAccuracy and verticalAccuracy. The horizontalAccuracy is exactly what you think it is. However, in all of my testing across multiple devices, the verticalAccuracy is always identical to the horizontalAccuracy, which is practically impossible. I won’t go into details because it would quadruple the size of this article, but some simple web searches will confirm what I’m saying. Vertical accuracy is usually 2 to 3 times less accurate than horizontal accuracy of any GPS device (unless it uses WAAS or another augmentation system, which no Android or iOS devices supports yet). Therefore, verticalAccuracy should be ignored because it’s simply not correct. I’ve yet to figure out if this is a bug with the flash.sensors.Geolocation class or a limitation of the underlying OS. I’ve looked through the Android SDK documentation and can’t find a vertical accuracy property anywhere. If anyone can clarify, please add a comment below. If it is indeed not being reported by the underlying OS, I think it is a bug in flash.sensors.Geolocation because the expected behavior is to report either a NaN or some other obvious invalid value rather than a value that is wrong and misleading.  UPDATE: On Android, the underlying OS returns “radialAccuracy” and both horizontalAccuracy and verticalAccuracy are being set to that single value.  This is a bug that will be addressed.  Android does not return a vertical accuracy so the value should be set to either NaN or a negative number.  On iOS, the vertical accuracy is set correctly to the vertical accuracy reported by the underlying OS.
• heading is always NaN in my testing (Android) — I’ve yet to test on a device where I get a value for heading. You could write some code to calculate it based on the location history/track, but the property itself is always NaN. I highly suspect that this is a device limitation, not a bug. If anyone has seen a value for heading, let me know in the comments.  UPDATE: On iOS, I get heading information.
• Two different types of determining location and a possible bug — Most modern mobile devices have two different means of determining  location – WiFi/Cell-ID (coarse location) and GPS (fine location). GPS is much more accurate.  I have discovered what I think is a bug with how the two types of locations are used (I’m working with engineering to confirm) — If the GPS is enabled on your device, you will not receive any WiFi/Cell-ID-based location events, so if you are out of range of GPS satellites (e.g. in the basement), you will get no location events at all (other than the initial last-known-location as mentioned above). The expected behavior (IMO) is to receive WiFi/Cell-ID-based location events until the GPS signal is acquired.  You can see this behavior in the Google Maps app.  When you first run Google Maps, it will show your location almost instantly but it will have a wide circle of accuracy.  This is the WiFi/Cell-ID-based location.  Once the GPS signal is locked in, the circle shrinks to only a few meters.  However, I am unable to recreate this functionality using the flash.sensors.Geolocation class. Oddly, if you disable the GPS on your device, you will then receive WiFi-Cell-ID-based location events as expected.  This feels like a bug to me and I suspect that the code uses either WiFi/Cell-ID or GPS and is not sophisticated enough to use both as I just described.
• Location permissions –  On Android, there are two relevant permissions related to location –  android.permission.ACCESS_FINE_LOCATION and android.permission.ACCESS_COARSE_LOCATION.  I have confirmed that setting the android.permission.ACCESS_FINE_LOCATION includes the COARSE permission. In other words, you do not have to specify both permissions because FINE includes COARSE. This is confirmed at http://developer.android.com/guide/topics/location/obtaining-user-location.html.

Hopefully this clears up some confusion on Geolocation.  It’s hard to test this stuff, so if you find any evidence of my conclusions being wrong, please don’t hesitate to let me know in the comments.

Writing location-based apps is incredibly fun and really creates some interesting app opportunities.  In my next post, I’ll share some code for a typical “Here I am” app that handles the last-known-location event and implements a simple timeout.

Developers need to know enough to use the right tool for the job at hand–and that holds true for any technology, not just Flex. Yes, some developers are using Flex for things that Flex should not be used for (this has always been the case). Flex is a framework that gives us components, a declarative language (MXML), a sophisticated event model, data binding, view management and many other useful, time-saving features. When you compile a Flex app, everything is converted to pure ActionScript as step one of the build process. Is this generated ActionScript optimized for every possible use case? Of course not. The Flex product managers and engineers put a lot of effort into prioritizing where to invest engineering time based on a wide array of use cases, but they obviously can’t optimize for every possible scenario. On the other hand, a ton of engineering hours have been invested in optimizing the Flex framework, and you should take advantage of this where possible rather than investing your own time in building custom ActionScript. It simply depends on your requirements.

So, when considering whether to build an app with the Flex framework or to build it in pure ActionScript, you are really making a decision between using prewritten/generated ActionScript that was created for a multitude of use cases or to write your own ActionScript that is specific to your specific use case. Of course, the latter is sometimes going to perform better because your code will be exactly what you need it to be, but it’s usually going to take you much longer to write your app.

You can take the quest for performance to the extreme. If you want the absolute best performance possible, write your app in machine code that targets a specific device and create a different version for each processor that your app will run on. The performance will be insane because every instruction will be specific to your app, but the development effort will take years! I realize that this is a crazy comparison, but again, we developers have to make some intelligent decisions when deciding what to use. Frameworks like Flex save us time, but they do have some costs in terms of performance. By the way, the same holds true for JavaScript. I recently wrote an application that utilized a lot of jQuery. jQuery saved me a TON of time, and thankfully in my app, the performance was adequate without me having to replace any of the jQuery functions with my own JavaScript. (If you search around, you’ll find people having the same debate on when to use jQuery versus straight JavaScript though).

We are seeing new life in the Flex versus ActionScript debate because of the recently released 4.5.x version of Flash Builder, which supports building Flex apps that target iOS, Android, and BlackBerry Tablet OS. All of us who have been building mobile apps are having to think about performance a lot more than usual because these devices have dramatically fewer resources than the modern desktop/laptop computers that we’ve been spoiled by. Suddenly we are worrying about every optimization and every byte of memory just like “back in the good ol’ days”. When performance is an issue, the choice to use a framework that trades performance for a shortened development process is not to be taken lightly, so the cost versus benefit analysis is key. However, it’s not an all or nothing proposition…

The guys at HD Interactive have written some great games that are in the Apple app store, Android Market, B&N Nook store, and other markets. The games include Kung Fu Battle Slots, Pyramix, MrMixit, Neptune, and more (their home page has all of the links so you can check them out). I have been super impressed by their app performance, so I sat down with them and looked at how they do it. The apps are indeed Flex apps and they take advantage of Flex views, the component model, and the event model. However, many of the animations, transitions, and effects were written in pure ActionScript that is specific for the game because they needed the best performance possible for the specific use case. For example, some of the effects and transitions in Flex are great for most apps, but they were not fast enough to handle the types of animations and the rich graphics that HD’s games demanded, so they made the smart decision to invest some extra time writing their own animation code. They even go to Flash Pro to build some of the animations because the tooling made more sense for a couple of specific items. They are masters at using the right tool for the job at hand. They utilize Flex where it saves them time, and they write specific ActionScript as needed.

Most of the apps I’m involved in are data-driven business apps, which are very well suited for Flex. Flex saves me a huge amount of time because the framework provides a lot of the building blocks that these apps typically require. For these apps, the decision to use Flex is a no-brainer. This is usually the case for enterprise apps. However, for other apps, the decision may not be as clear. Like many decisions we developers make, the answer is “IT DEPENDS”.