BCmoney MobileTV

Write once, run anywhere

Despite its best intentions, the motto of Java did not ring quite so true when it came to natively supporting the complex slew of Mobile devices such as Smart Phones, Tablets, E-Readers and Fitness Devices (wearables, smartwatches, etc) that began to emerge in the mid 2000’s through to today. Theoretically, yes, one could write a small basic Java project using only the most essential native Java library packages/APIs, which “should” then pretty much just run on any device upon which you were able to get root access and install a JVM (if one weren’t already installed), and then run your compiled code. On smaller less powerful devices like Mobile phones in the early days we could use various flavours of Java Micro Edition (or “JME”, then called “J2ME”, although rarely used it is still deployed in edge contexts, mostly just for IoT and embedded devices these days). The problem was we could not use the full suite of Java Swing or later JavaFX UI components, and had to learn a whole new set of UI programming techniques which was more similar to the “bad ol’ days” of Applets and raw GUI programming via the Abstract Windowing Toolkit (AWT). Inefficiently re-painting the complete GUI with each interaction programmatically, and commonly needing to get right down to X,Y,Z graphics programming, rather than deferring to UI libraries for rendering reusable components.

“Ok, I’m sold already” you say? Then jump to the Apache Cordova instructions! If not read on for the rest of the abbreviated/opinionated take on Mobile development history.

However, speaking of practical day-to-day realities, many devices such as all of Apple’s iOS devices, certain OEM/Carrier-locked versions of Android (itself written atop Google’s Dalvik flavour of the Java Virtual Machine or “DVM”), Nokia’s Symbian OS and most versions of Windows Phone have measures in place to block this from happening. In these cases, a Developer would need to step through sometimes risky rooting/unlocking/jailbreaking to get the required access, and it was typically tough if not impossible to do so.

As it turns out, other low-level languages like C & C++ tended to operate with better performance than Java and have a wider selection of libraries when it came to graphics manipulations, so the most graphics-intensive Mobile Apps ended up being written in Device/OS-specific, compiled C/C++ anyway. Even where it was theoretically possible with the required rooting, one would need to port the JVM itself (if a port didn’t already exist) to be able to run Java on the target hardware. For the average consumer with a mobile device, Java was simply not an option from the get-go, unless Sun (or later Oracle) could strike deals with the Mobile OEMs to make concessions to put a version of Java on the device. As we know, on many of the popular handset versions, the formal deals unfortunately never came, and neither did proper Java support. Even with the advent of J2ME, it was still difficult for Java to make much meaningful traction into the mobile device space, despite its heavy use on Blu-Ray/DVD players, Smart Cards, TV set-top boxes and other home or portable electronics devices.

For the first decade of the 21st century, BlackBerry and Sony-Ericsson boasted the best Java support, with most of their applications being written in a Java or J2ME subset. Several Motorola and Nokia handsets eventually came around too, but even in Java’s “slow release train days” with many years between subsequent JDKs, devices ended up way behind in features. BlackBerry’s Java and Sony’s Java implementations had many differences even between their own device iterations. Seen as Java’s savior in the Mobile app market, Android, came along but unfortunately rather than pay Oracle for the rights to use the latest versions of Java as-is when the offer was made, its acquirer Google opted to form an open source alliance of “Apple walled garden hating” OEMs, fork the Java JVM to roll their own version called Dalvik, and thereby enter a long legal battle with Oracle (over unlicensed Java use) and Apple (over copying user interface elements and infringing on IP patents). The entire situation alienated many developers and supporters aside from the big corporations with money to fight legal battles like Samsung, LG, HTC and later those other Mobile device makers who originally supported Java like BlackBerry and Sony-Ericsson who threw in the towel with their own Java platforms and started releasing Android devices.

Lawsuits aside, Android development today is hardly the same as firing up an IDE and starting a Java project in any version you feel like, such as the latest Java 8 with all the nice snazzy features, then simply hitting deploy. Specific versions of Android will only support specific APIs (a small, customized subset of the Java programming language), and even then only up to Java 1.6 (limited support for 1.7 in some newer Android devices) while the current version of Java with the latest features is Java 1.8 with 1.9 already well on its way for early next year. None fully implemented JDK 8 for instance and Google is only now still knocking off JDK 8 compatibility in the latest Android versions. So the promised land of “write once, run everywhere” concept was simply not possible due to device fragmentation and the Mobile market’s constant innovation/improvements “eating itself” where platform support was too much of a moving target.

 

Why do we need Hybrid Apps?

Hybrid Mobile Apps are web-based application that run web-based code in a native “wrapper” which can communicate with the device APIs through cross-platform libraries. Compare the Hybrid App skillset (HTML/CSS/JS) which most developers already possess or can easily pick up, is in stark contrast to needing to learn:

1. Objective-C & Swift (to develop an iPhone/iPad/iPod/AppleWatch/AppleTV app)
2. the Dalvik Android-specific subset of Java (which varies depending on Android phone/tablet/notebook/gear-watch/tv-box devices, and also Amazon Fire and many other slight OEM differences in implementations and update processes)
3. while you’re at it, better check out several different J2ME subsets of Java (for BlackBerry and other legacy mobiles i.e. Nokia, old Sony-Ericsson, Motorola, LG, Samsung, HTC, prior to Android’s launch)
4. don’t forget to learn XAML for the front-end and C#/Visual Basic for the back-end (if you want to reach Windows Phone users in their native platform, although it seems like that’s not shaped up to be nearly the contender to iOS & Android that Microsoft was hoping it would be)
5. as mentioned earlier you’d eventually need to sharpen your low-level programming skills and get into memory/graphics management with C or C++ (whether to optimize your Android app as you can combine Java with C++ via JNI to get better performance in those graphics or memory-intensive apps, or even as a throwback to get a native app onto the large number of legacy Nokia Symbian OS devices already in circulation even though the platform has been discontinued for new production there are millions of handsets out there being under-served by developers at this point)
6. On top of learning all these different languages, one would also need to learn the device AND platform-specific tools, IDEs, building/signing processes, etc for deploying applications to the actual end-user devices

Last but not least, you’ll have to familiarize yourself with and be sure to pass all requirements for, each of the manufacturers’ Application Stores:

1. Apple’s iTunes App Store (iOS)
2. Google’s Play store (Android)
3. Amazon’s App Store (Fire/Android)
4. BlackBerry’s App World (RIM devices)
5. Microsoft’s Windows Phone Store (Windows for Mobile)
6. Nokia’s Ovi Store (Symbian/OperaMobile devices)

Even within these platforms, there is significant variation of tooling, language support and requirements between devices and OS versions. This excellent graphic from Ritesh Gupta Sr. Manager of Technical Operations at Motorola back in 2013 summarizes just a snapshot the rediculousness of the situation quite well:
This was the inspiration for Mobile Hybrid App frameworks which could be “built” for each spearate platform as needed.

What is Apache Cordova?

Into this fragmented device hardware, operating system, technology stack and myriad of application ecosystems, enters Apache Cordova. The Apache Cordova project, according to its project page: “is a set of device APIs that allow a mobile app developer to access native device functions such as the camera or accelerometer from JavaScript. Combined with a UI framework such as jQuery Mobile, Dojo Mobile or Sencha Touch, this allows a smartphone app to be developed with just HTML, CSS, and JavaScript“. Its goal is to simplify the mobile development lifecycle.

The need for a simple, common platform to reach the wide array of device and OS combinations described above, should be pretty clear by now. The Hybrid App approach, such as that of Apache Cordova (which we’ll focus on here) and similar libraries/tools like it,  can finally realize Java’s “write once, run everywhere” dream, (everywhere with a client software installed that runs/integrates with the web, that is, which is increasingly every new device). The fact of the matter is, the Web has reached an even broader set of devices than the various versions of Java’s JVM has.

Interestingly enough, it also evolved out of the W3C Widget set of specifications on packaging and running HTML/CSS/JS WebApps in a consistent manner, as can be seen by its continued use of the “config.xml” configuration and permissions file. See my earlier posts on W3C Widgets to learn more about those:

• How to build widgets following the W3C Widget specification
• Creating a W3C Widget with the Wikipedia API
• WordReference API, AJAX SDK & W3C Widget example

 

Hybrid Apps Can Perform As Well As Native, And Save Money Too!

Yes, this takes some serious work to pull-off a Hybrid App experience that rivals or beats a Native App user-experience, but it is possible. In general, so long as you embed your primary HTML/CSS/JS into the app’s download package and avoid loading all data remotely from the server, the performance should be comparable to most Native Apps in the same category. As expected, its only when you get into graphics-intensive or very frequent succession file/memory reads & writes (which should not be everyday common use cases) that performance could be an issue. Keep in mind that even during these more complex use cases, you’ll always have the option to jump in and add a bit more Native code, fattening up your initialy nice and thin Native App wrapper only where absolutely necessary. You can slickly combine Native code (WebView with @JavascriptInterface JS bridge in Java/Kotlin on Android; WKWebView with WKScriptMessageHandler & evaluateJavaScript in both Swift/Objective-C on iOS) for those “hard to reach” areas like new Device APIs or better Native low-level access.

• Hybrid .vs. Native app development: http://www.comentum.com/phonegap-vs-native-app-development.html (average total cost of ownership, project from design through implementation to maintenance & expected lifetime)

How to develop your first Hybrid App with Apache Cordova

The following is a step-by-step guide for how to develop your first Mobile Application using Apache Cordova, and due to a desire to avoid redundancy and making yet another To-Do List or Hello World app, I’ve opted to show how to do something that’s hopefully a little more interesting, and show how to get a basic little “Whack-A-Mole” game running on your Mobile device, right now:

1. Download the Cordova CLI tool
2. Download the IDEs of the platforms you want to publish to (best to start with just Android & iOS and expand out as needed)
3. Setup “Whackamole” Cordova project in each of the IDEs
4. Copy over code (beauty is you can edit your HTML/CSS/JS in any text editor from Notepad++ to VIM)
5. Build & Deploy as a Mobile Application using Cordova CLI
6. For iOS – use Device IMEI (similar to a computer’s MAC address) to install the App to test before publishing it to App Stores
7. Publish to each of Google & Apple’s App Stores
8. Download your App from the App Stores
9. Test that all works good on most common Device/OS/Browser combinations of your chosen platforms
10. Share/promote the link to the app(s) and hope for the best!

You can see how these steps could potentially shave a lot of time off of Mobile App development. As any technical hiring manager knows, web development skills are far easier to come by in the candidate pool than in-depth knowledge of the Mobile industry and Native App development skills (although thanks to innovations like Swift & Kotlin even those uneven terrains are rapidly becoming smaller hurdles at least).

Here’s the full WebApp code to get this basic game going as a Hybrid App. 

CSS

...

HTML

...

JavaScript

...

-OR-

Conclusion

Again, when I first threw this little sample together about 5-6 years ago (sometime in early 2012), I never thought I could create a fully functioning Mobile Game. Even if it is very basic and just scratching the surface, it seemed daunting to do even this much. From past times dabbling in J2ME and Android Native Apps, it just seemed too insurmountable an obstacle with a ridiculous amount of learning and nuances between platforms, so I almost gave up before I really tried (each time doing it out of interest and career/knowledge advancement “on the side” rather than out of necessity). Doing a basic Native app with an input screen or two and no bugs seemed hard enough for me in my early Software Development career from 2006-2012, and was about the upper limit of what I could do as far as Mobile Native app development back then went, due to the all the complexities I’ve covered.

Now any example I could dream up and throw together as a WebApp can be repurposed for Mobile as a Hybrid App in a day or two where it makes sense, and that’s fairly liberating. Furthermore, I even see how it could be used to rapidly prototype a full Mobile Native App or feature subset, without needing to write all the code in Objective-C/Swift for iOS, Java/Kotlin for Android or C/C++ for the legacy BlackBerry/Symbian/WindowsPhone platforms from the get go, which is borderline impossible for a single Developer. Instead, I could get a Proof-of-Concept (PoC) going fairly quickly that should run reasonable well on most of the popular platforms, and only as I run into obstacles with the Hybrid App could I branch out and look at implementing certain parts of, or, eventually all of a given project as a Native App. Hopefully you’ll agree some basic Hybrid App dev skills can go a long way, good luck with your experimentation!