Posted on

Mobile Cross Platform Development : Cordova

Apache CordovaApache Cordova (aka Phonegap).

A little clarification on the name.  The NEW name will be Apache Cordova.   After Adobe bought the development firm that was working on Phonegap the Phonegap project itself was given to Apache Software Foundation to maintain its open source roots and continue development.  As of this writing the transition is still underway with MOST, but not all, elements haven taken on the Apache Cordova persona.

Our First App On Cordova

Our first app that we wrote using Cordova was the Abundascan application for Abundatrade.   The first release is a simple app that uses the camera to scan a barcode then sends the UPC to the Abundatrade server to get real-time prices that they will pay for used books, CDs, DVDs, and video games.    Functionally the app is simple and works well.    However one key element here is the primary reason we started with Cordova over other cross-platform tools like Corona, the camera.

Turns out that many of the cross-platform tools do NOT support the camera interface. That shot down Corona right away, which otherwise looked promising.

Cordova And Cameras

The nice part about Cordova is that the system is basically a wrapper for the native web browser.  That means coding in HTML5, CSS, and JavaScript.  It also has a number of third party plugins that hook native mobile functionality (via Java or Objective-C) to a JavaScript class.   In theory that sounds great.

Luckily there is a good camera scanner app that reads UPC,and other machine-enabled codes like QR, codes created by Google released in the ZXing project.  The ZXing applet is ported and ready to use for Cordova as a plugin.

Cordova Camera Caveats

The problem is that theory does not work out in reality.   The plugin for Android works wonderfully.  The plugin on OS-X, not so much.  Not surprising that a Google app talking through JavaScript to an Apple owned OS and development environment doesn’t work well.  Apple really does go through a lot of effort to put a stranglehold on their development pipeline.

The bottom line, we have yet to get the camera plugin to work on IOS4 or higher devices.   In theory the demo app works, but we’ve yet to see it on our iPod Touch or newer iPhones.

The Android Version of Abundascan is out, but we still are having issues with Cordova on IOS.

Our Second App

Our second app is a little less ambitious as it is testing the waters for a larger project.  This app is simply a screen that shows your current GPS location with exact latitude and longitude.   Where Am I Standing? is a free app that does just that.   To make it a little more interesting we wanted to add an info page with our name and logo and a little bit of graphic “window dressing”.

Again, here we ran into multiple issues.  This time noticeable right on the Android before we even attempted the iPhone release.    We want a simple app with no glitches yet there are several things that still aren’t right.  We can spend a good bit more time addressing in convoluted code to workaround quirky UI elements.  Others are as-yet un-fixable.

Technically it was easy & works well. Aesthetically it is NOT of the caliber I want it to be at.    As I dug deeper into this I uncovered a lot of hidden secrets about mobile app development and why 99.99% of these cross-platform tooks like Cordova fail.

The Compromises

Here are the “little details” that are compromises I don’t want to make.  I want to build QUALITY apps.  That means making them as perfect as we can, and this stuff is far from it:

Swipe Right / Left : I wanted to be able to simply swipe the main screen to see the info screen (“created by Cyber Sprocket”).     One swipe works, then it breaks.  This is a fundamental issue in the browser kit Cordova uses as the foundation for their solution.   Google developers refuse to address it saying it is “as designed”.

Vertical Page Scrolling : I don’t want ANY page scrolling, jitter, etc.   The pages are too “tall” and are scrollable if you swipe up or down.  This can be fixed but takes extra coding to do so.   What a pain.

Button Highlighting : Sometimes the highlights on the info/home buttons “stick”.  This is a built-in feature of jQuery Mobile and Cordova.  It is wonky at best.

Screen Hesitation: Even on a mid-range phone with just about the simplest app possible, sometimes going to the “info” page hesitates, same with going back to home.

Navigation History : Go to info, then back to home.   Each time you do this is adds to the “history”.  Do it a few times and your back button is loaded up with a bazillion loops of home/info/home.   Again, fixable with code (mostly) but why?

Summary

While Apache Cordova will help you build apps using technologies you likely already know like HTML5 and JavaScript, the implementation is far from simple.  Getting stuff to work on more than one platform requires extensive knowledge of all the quirks.  Like IOS requires a special onDeviceReady hook or it won’t even load properly.   The apps also feel “heavy”.    The UI is not responsive and, depending on the hardware, often misbehaves.

While Apache Cordova may be a great tools for building a functional prototype or possibly building corporate apps where users may value function over form, in my opinion Cordova is a compromise.

Yes,  you can probably build a well-polished UI.   But it takes a LOT of extra effort because you are hamstrung by the JavaScript/web interface.  Of course you can write custom Java or Objective-C hooks and/or make your own plugin, but isn’t that point to get away from native custom code?    You can also get around *some* of the quirks with a good bit more coding, but how you get around which quirks often requires intimate knowledge of the quirks for the particular mobile OS that is giving you problems.

I’m sure we can build quality apps with Apache Cordova, but this is not about CAN we do that, it is about what are the benefits of doing so.  From a business perspective there appears to be little gained here over a process that includes solid architecture, documentation, code design, and good old-fashioned cross-platform awareness and porting.

Posted on

App Inventor First Impressions : Setting Up

Google App InventorIn the previous article I went over some of the notable items on the Terms of Service for Google App Inventor. Here we get into building our first simple app.

App Inventor and Java

While you don’t need to know how to code in Java, you will need Java installed on your computer. Don’t worry, your computer probably already has Java on it. If not, it is usually a simple process to install or upgrade Java on your system. It is not any more difficult than installing or upgrading Flash. That said, sometimes getting Flash or Java upgraded and installed can be a challenge depending on your computer security settings, hardware, disk space, memory, and other unique factors that require you to hire a Comp Sci major just to get started.

Notes about App Inventory and Java…

  • Requires Java 6.
  • Upgrading (or intsalling) Java can be a challenge on some systems.
  • Get Java at http://www.java.com/inc/BrowserRedirect1.jsp?locale=en

Java Exposes It’s Ugly

Now that we have our Java environment up-to-date we can get started. Surf to your App Inventor login and launch the program. If everything is going well you can follow the Google tutorial and start creating your first app, a picture of a cat that will meow when clicked.

This is where things get ugly for App Inventor and Java.

There are 3 main parts to creating your App Inventor mobile app:

  • The App Inventory Palette – where you draw your interface by dragging & dropping components onto a mockup phone.
  • The Block Editor – where you drag and drop logic components using a puzzle analogy. In essence you are writing Java code visually.
  • The Phone – connecting your Android phone is your staging (or testing) environment to see how things really work when “glued” together.

All was going well. The palette came up, got the button, the photo, the MP3 file all in place. Got the phone connected and the PC loaded the device drivers for the HTC Incredible being used as the test device.

Ok… let’s start writing some code. Fire up Block Editor. And…

We get “Java Ugly” in full effect. While Java has some very cool things that deserve bragging rights, over a decade into its existence and it still retains the uglies UI contest hands-down. Not only do all default Java interfaces look like they were designed for a 1987 character based terminal, they are often less than helpful in helping you interact with whatever files, folders, devices, or web addresses you need to resolve a problem.

In my case the “command interpreter” that allows the App Inventor to talk to the phone cannot be found. The ugliness ensues:

"Java Ugly" Command Directory
“Java Ugly” Command Directory

Yikes. Welcome to 1987.

Fixing The Missing Blocks Command Directory

Turns out that I missed an important step before setting up my environment. Not only do you need to upgrade/install Java, but you also need a desktop program that Google App Inventor uses to communicate with the phone (among other things). The Windows version is here:

http://www.appinventorbeta.com/learn/setup/setupwindows.html

Next Problem : Windows And Google Not Playing Nice

The next problem we run into is that the Block Editor cannot talk to the phone. It just doesn’t see it. After reviewing the App Inventor setup program we learn that you should “not change the default installation directory”. Virtually every single app on my computer goes on my 500GB D: drive, NOT the default C:\Program Files directory.    Wow.  Really, “don’t change the default install location”. Back to 1987 I guess.

So we uninstall the application.  Re-install it in the default place.   All is good, right?

Well, not so fast. Now the Block Editor is looking in the original D:\ install location but it cannot find some of the necessary components.

Great. Copy all the components over from the C:\program files directory. Still not working. Uninstall and delete EVERYTHING. Reboot…  we’ll be right back…

Windows Serves Up EPIC Fail

We’ll be right back, my butt. On the reboot windows decided my Windows account no longer exists. I was immediately greeted with a rather useless “The User Profile Service failed the logon.” message as soon as I tried to get into my Windows account on my local PC. Great. Off to safe reboot & finding the answer.

Now for the favorite part of my app development experience. REGISTRY EDITING.

Yup, that’s right. To restore my account back to normal I had to edit the windows registry. What fun. Luckily that is all it took and the instructions I found on the Microsoft Support site actually worked. If you ever need to do this yourself, make sure you sacrifice the requisite number of goats then follow this link:

http://support.microsoft.com/kb/947215

Try, Try Again

PC back online. Check.

Re-install the appinventor_setup_installer_v_1_2.exe.

Open up the Google App Inventor at http://appinventor.googlelabs.com/. Check.

Open up the Block Editor. Check.

Ohhh… wait… no devices found. The editor is open, but it can’t talk to my phone. The phone is in the proper USB debug mode. No communication with the device. Wonderful.

It turns out that the AppInventor_Setup_Installer executable that we downloaded (all 90MB) may NOT have the proper driver for the HTC Incredible phone, even though Google notes it as one of the phones that works with this development IDE. Now we need to go to the HTC site and find the right driver and try this all over again.

Just to make matters even more fun, there is no simple “HTC Incredible” device driver. However, even with the phone attached to my PC and visible as an external device, a visit to the Device Manager in windows shows it as an unknown device with a name like “ADB”.

Setting Up HTC Drivers for Windows

So here I am, no obvious HTC Incredible drivers. Some hints on the “Internet at large” indicate that the full blown 30MB HTC Sync application, WHICH I DO NOT WANT, will have a driver for the phone packaged up in there. I sure as heck hope it doesn’t mess with my already working perfectly Google Sync program that keeps my contacts, calendar, and email all perfectly in sync with the Toshiba Thrive table, HTC Incredible phone, and my Windows desktop. We’ll see.

For now, I sit and wait… going on 15 minutes now… for a 30MB file to be downloaded from what must only be direct via mainland China on the 宏達國際電子股份有限公司 (HTC Corporation in case you’re wondering) website. I’m on a 50MB/10MB line, but this is slow as heck. Must be getting interrupted by some goats, stray chickens, and a stray tank rolling over the fiber line before it tunnels it’s way under the Great Wall on the way to The States. Man this is slow. Guess I’ll go practice more guitar lessons while I wait…

…I’m back.

Installation of the HTC Sync program got the drivers. Sadly I had to start the installation, let it install Adobe AIR, the HTC driver, and some other junk then cancel out right at the start of the actual HTC Sync installation. At least I got out of that.

Next.. maybe we can code our first app.

Not So Fast…

Wow, this sure is a LOT of work for a supposedly easier way to develop Android mobile apps. I had Java, Eclipse, the SDK and my first mobile app written the “old fashioned way”, you know… with CODE and an tried & true ID like Eclispe, done in much less time than the 4+ hours getting this setup.

My intention was to write a quick article on actually using the App Inventor IDE, yet here I am writing about how to setup the IDE and how to install drivers and how to debug a failed Windows login.

So much for quick & easy.

Hopefully the next article will be about actually creating a usable app with App Inventor.  Stay tuned.