The Hybrid Application Developer's Workflow by Michael Rheinheimer
Kathleenholm 2700009BHX Visits (3708)
Hybrid app development is a different world. Or is it?
So back to my workflow...now using IBM Worklight Studio (the developer edition is free, and available in the Eclipse Marketplace). I write up my HTML5/CSS/JS code in the common folder under my Worklight project's application. If I'm just doing user interface bits, not testing use of native phone features, and not testing network connectivity, I might be tempted to set up some third-party web server whose document root points to that common folder. This is problematic because I would be treating my code as if it was not in the mobile hybrid context, and would have to violate the initialization routines that make Worklight so powerful in the first place. If I did this, I would later have to re-work my initialization code when I moved into a hybrid context. So what's the better choice? Use the tools! The iterative development cycle is fast in Worklight. I write my code in the common folder, right-click the application folder above it, use Worklight's "build all and deploy" plugin feature, which starts an embedded Jetty web server in seconds, and I'm up and testing. Now I can ensure not only that my user interface is what I intend, I have all the browser debug tools I want, I can test and debug server connectivity, and I'm a happy hybrid app developer.
What about all the native hardware feature APIs my code is calling? Won't those break the app in the web browser? Short answer is yes, but you've coded for that, right? Personally, I would add a little initialization code that detects that the client is a web browser, and overrides calls to native APIs so my app can do something meaningful for the web browser visitor. Perhaps my client detection is smart enough that I simply hide unsupported features, or maybe I pop up a link to download the hybrid app, explaining why their experience would be much enhanced by doing so! If my app is intended to be strictly native (meaning it will never be served to web browser clients), then during the development phase, I would override the calls to native APIs to feed mock data so I can do 99% of my application development using Chrome, Safari, or Firefox with Firebug. It's like comfort food for the web developer heading into the hybrid world. I get to stay in my happy place.
The last step is device testing. That's right, I said device testing, not device development. You've already ensured your user interface is awesome and bug free. You've used Chrome or Safari to send a mock User-Agent header, so you know your app is behaving properly based on which device it thinks is visiting, you mocked the return values from native API calls, now you just need to do that last little bit of testing on a real device. This is where Worklight really shines. You simply create an "environment", such as Android, iPhone, iPad, etc, "build all and deploy", build the app using the Android or Mac XCode tools, and you've got yourself a full-featured hybrid application. You didn't have to write a single line of native code. You didn't even need a device during development!
Dojo Mobile: http
IBM Worklight: http