Behavior, Content, Money – 3 Things you should never give away for free!!!

BCmoney MobileTV

Working with Apache Cordova to make a cross-platform hybrid Mobile App

Posted by bcmoney on January 30, 2018 in AJAX, HTML, Mobile with No Comments


No Gravatar

Write once, run anywhere

English: A pile of mobile devices including sm...

A pile of mobile devices including smart phones, tablets, laptops and eBook readers. (Photo credit: Wikipedia)

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 file using only the most essential native Java library packages/APIs, which could then 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.

However, speaking of practical day-to-day realities, many devices such as all of Apple’s devices, certain versions of Android (itself written in Java), Nokia’s Symbian OS and most versions of Windows Phone have measures in place to block this from happening (root/unlocked/jailbroken access that is) or make it tough if not impossible to do so. Even if it is theoretically possible, 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. For some of the most popular devices, the deals unfortunately never came, and neither did proper Java support. Even with the advent of Java 2 Micro Edition (J2ME), it has been difficult for Java to make much meaningful traction into the mobile device space, despite its use on Blu-Ray/DVD players, TV set-top boxes and other home 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 subset. However, the “write once, run everywhere” concept was simply not possible due to limited implementations of only certain portions of the Java stack. BlackBerry’s Java and Sony’s Java had many differences. Even for example, Android, the current “Java-based” leader in Mobile came along and rather than pay Oracle for the rights to use the latest versions of Java as-is, its creator Google opted to form an open source alliance of Apple-hating OEMs, fork the Java JVM to roll their own version called Dalvik, and enter a long legal battle with  Oracle (over unlicensed Java use) and Apple (over copying user interface elements and infringing on IP patents), thereby alienating many developers and supporters aside from the big corporations with money to fight legal battles like Samsung. 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.

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 (to develop an iPhone/iPad/iPod/iWatch app)
  2. the Dalvik-specific subset of Java (which varies depending on Android phone/tablet/notebook/watch devices, and also Amazon Fire)
  3. while you’re at it, better check out several different J2ME subsets of Java (for BlackBerry and other legacy mobiles i.e. Sony-Ericsson, Motorola, LG, Samsung, HTC, etc)
  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)
  5. you’ll even need to sharpen your low-level programming skills and get into memory management with C++ (to get a native app onto the large number of Nokia Symbian OS devices already in circulation even though the platform has been discontinued for new production but apps have some compatibility with OperaMobile)
  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. BlackBerry’s App World (BB)
  4. Amazon’s App Store (Fire/Android)
  5. Microsoft’s Windows Phone Store (Windows for Mobile)
  6. Nokia’s Ovi Store (Symbian/OperaMobile)

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:
Mobile_NativeApp

 

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. Tphonegap_cordovahe 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.

 

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

Yes, this takes some serious work to pull-off a Hybrid experience that rivals or beats a Native App user-experience, but it is possible.

http://www.comentum.com/phonegap-vs-native-app-development.html

 

 

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 Cordova
  2. Download the IDEs of the platforms you want to publish to
  3. Setup “Whack-a-Weiner” Cordova project in each of the IDEs
  4. Copy over code
  5. Build & Deploy as a Mobile Application
  6. 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 App Stores
  8. Download your App from the App Stores
  9. Test that all works good
  10. Share the link and hope for the best!

 

Leave a Reply

No trackbacks yet.

No post with similar tags yet.

Posts in similar categories

BC$ = Behavior, Content, Money

The goal of the BC$ project is to raise awareness and make changes with respect to the three pillars of information freedom - Behavior (pursuit of interests and passions), Content (sharing/exchanging ideas in various formats), Money (fairness and accessibility) - bringing to light the fact that:

1. We regularly hand over our browser histories, search histories and daily online activities to companies that want our money, or, to benefit from our use of their services with lucrative ad deals or sales of personal information.

2. We create and/or consume interesting content on their services, but we aren't adequately rewarded for our creative efforts or loyalty.

3. We pay money to be connected online (and possibly also over mobile), yet we lose both time and money by allowing companies to market to us with unsolicited advertisements, irrelevant product offers and unfairly structured service pricing plans.

  • Archives