The late Steve Jobs made it a point to say that HTML5 will end up replacing Flash. The problem is, Flash has been in the game long enough to have quite an extensive plugin, running their proprietary language. They built this plugin for one major reason: to overcome the ability to access client side system resources. This is the major shortcoming with HTML5. Users have no control over what the browser will let you do, and what you can do is very limited.
HTML5 is just a catch phrase for Dynamic HTML (DHTML), which is just a combination of HTML, JavaScript, and CSS. The DHTML coding modal has been around for years, and all HTML5 brings to the table is more DOM tags to manipulate, and a few new JavaScript methods. One of the major issues with the modal is that the user has no control over the client side computer. In other words, there is no communication possible between the app and the viewing computer, beyond the scope of web browsing. So, why code in such a limited language set?
“Because…Steve Jobs said so.”  Buwahaha, No.
It’s because of the portability of the app. The great thing with DHTML is that it will run on any browser that supports the DOM that you are using. This makes interpolation an almost painless process.
So, you want a super badass HTML5 site, and you want to build it in a way that runs on all the devices known to man. This is quite easy—as long as you don’t care about audio effects, loading times, code security, or any of the sensors/hardware on the given device. I have found that most of the mobile browsers on the market today are extremely limited. On Android (API Level 8 and below), and also on iPhone (all versions), the webkit browsers have only one audio channel, user dialog (that can take up valuable screen space), and an incessant need to run everything its own way.  How do we overcome these problems? There are many options out there to make a so-called “webapp” (like PhoneGap, and XNA). These frameworks are a beautiful start to making a library, which is a plug and play solution, to gain access to system resources, from a web page. I have often found that what our clients need, exceed the scope of what they can do— and these systems are far to bloated for what we need.
So, we are left with one option; we make our own native app, which can create a web browser in a symbiotic relationship. We have a native device app that can spin up an instance of webkit, and only use the pieces we need for our given project to work. In the coding world, this is known as a “webUIView”, which can be utilized on all of the popular, full web enabled devices. With this web view, we have a system that can expose the hardware layer to our webapp. So, how are we going to communicate, back and forth, between the device and the webapp? In a nut shell, we have JavaScript injection, in order to inject some code in the DOM and run it, access to the DOM headers and control of the URL to run GET and POST procedures, access to the JavaScript console for debugging, and finally, the power to override the JavaScript dialog system for an events model, to be used from the DOM.
JavaScript injection is a process to create a string of DHTML, and push it to the DOM before the “onLoad” events are fired. This works like any other server side system, (i.e. PHP, ASP.NET, etc.) in that they have the ability to execute code before we hand it off to the browser. Having this, gives us the ability to pass information (and code) to the webapp for its own use (i.e., geo-location). This can also offer some security to your site by making the webapp worthless, unless executed from your native app.
Having access to the URL allows us to focus the user’s browser where we want them to go, and nowhere else. We can also place URL parameters in a load.url statement, forcing a POST action to happen. Lastly, this means that we can execute callback function, to run anything within our web app.
This is great. We have everything we need to push information to the webapp to enrich the user’s experience, but what about when we need the webapp to fire an event, inside the native code? Well, we can use the JavaScript console to pass serialized data to the native app, or we can use a JavaScript alert. In practice, I use the JavaScript Console for debugging, and the JavaScript alert system for events, mostly because I never use the JavaScript alert system at all (not cool enough). This benefits me, by keeping the debug system and events (JavaScript alert) system apart.
So, now I’ve come full circle, and have the ability create robust applications that will run on any platform (the way I want them to), without eating up resources, better utilized elsewhere. As time passes, technology will become better and these new standards will be finalized. When this happens, it will (without a doubt) be the way to develop on mobile platforms.
– Jack