Checking in on Cordova

I’ve made a little progress on Cordova.

I’m also hanging out with Rolf and Roger at Imagechef, and working to add some chat features to the mobile web version of TuneTug, http://tunetug.com. I will post more when we are able to push to production. And then there’s that class I want to take Thursday/Friday, but it’s in Santa Clara, and I don’t want to drive down there.

Gee, life is sure tough being unemployed.

Well, I’m anxious to get back to Cordova. I’d like to finish the happy path for user, and test with client-side AJAX requests to a live Google API feed. I think this weekend may be ambitious, so will aim for mid-next week. Afterwards, will need to work on server-side response and connect it all together. Then make it bidirectional. Should be fun… Will put you on hold for now, Cordova.

Eating my words

I should know better than to claim that anything is easy, let alone super-easy.

But it was easy to get Cordova up and running. Cut/paste the full example from the camera API, and voila! You have ios and android native camera apps in 10 minutes flat.

So the real work begins, and I’m trying to create pages each invoking separate device features. For my dev environment, I’d like to bypass IDEs in favor of using an editor and command line. If Eclipse is needed in order to debug android code, Cordova loses 90% of its value. Then I’d need to hire someone who has some understanding of Android programming to do this stuff. The idea was for anyone with HTML and javascript knowledge be able to design native phone apps, and the best way to debug HTML and js is through a browser.

Well, I was trying to do just that with the Cordova serve android command, but it turns out I’ve had to fire up Eclipse anyways. Now I’m scratching my head wondering why Activity classes aren’t used, and if they’re not used, how does Cordova do it? I think I need to revert back to the helloworld example…

Anyways, Cordova is not trivial.

Cordova is super easy

From here on out, I’m referring to PhoneGap as Cordova, which I’m using to build my idea.

Firstly, ignore the documentation out there, which I’ve found either outdated or misleading… At least the setup for Cordova 2.2.0 and some of the development process deficiencies I blogged about before have already been addressed.

If you are using OS X, just follow these simple commands which installs Cordova, and creates project directories for ios and android, builds all, and launches both ios simulator and android vdm.

# Download the Android SDK https://developer.android.com/sdk/index.html 
# Unpack and place into ~/.devlib

# Install Node
brew install node
brew install ios-sim

# Install cordova
npm -g install cordova

# Set Path in .bash_profile
export PATH=${PATH}:~/.devlib/adt-bundle-mac-x86_64/sdk/platform-tools:~/.devlib/adt-bundle-mac-x86_64/sdk/tools
export PATH=${PATH}:/usr/local/share/npm/bin

# Create a project
cordova create <projectname> <projectname>
cd <projectname>
cordova platform add iOS android

# Check it in
git init .

# Build the package and run the simulators
cordova build
cordova emulate

Thanks to my dear brother, Dave, for setting me straight 🙂

From here, you can look at the Cordova API docs to install device features. I’ll blog more on how this is going for me.

Sencha, PhoneGap, or TriggerIO

There’s a lot of content out there, and another framework at every turn. I feel constantly directed toward different products… use jQuery Mobile instead of Sencha, Trigger.io instead of PhoneGap… (not to mention server side) node instead of ruby. And then there’s express, meteor, firebase, and derby.

Needless to say, my attention is a little scattered. So rather than diving in and building a demo today, I read up on various cross-platform mobile frameworks and what advantages one has over the other. And honestly, they all look pretty good.

Found this article which gives an awesome summary of various development technologies and approaches. http://trigger.io/cross-platform-application-development-blog/2012/05/21/making-sense-of-mobile-development-platforms

It is a little biased.

The article addresses all those issues I had with installing PhoneGap yesterday, and explains how certain hybrid frameworks combines HTML5 and native environments, but complicates the development process. Put simply:

Sencha Touch – Pros/Cons
1) Super easy to build cross-platform.
2) It’s geared more toward mobile web look & feel.
3) Limited native device capabilities.
4) It’s free.
5) Lot’s of docs.

PhoneGap (with jQuery Mobile for UI) – Pros/Cons
1) Awesome native api’s – for accelerometers, location, calendar…
2) Different code base for each device – This becomes a problem not just in development time, but isolation of bugs and testing.
3) Builds for each native app separately – This means a lot of manual processes.
4) It’s free.

Adobe addresses and monetizes the two PhoneGap shortcomings with a their PhoneGap Build product. Developers upload source code into the cloud to generate native apps.

Trigger triumphs Adobe by providing 4 simple commands to create app, build native, launch simulator, and package the mobile web app. They also offer a stand-alone build, which I like. Their pricing model does seem a bit scary, if you’re a small shop who’s making a lot of updates and scaling quickly.

Honestly, I’d like to try Trigger for this project I’m thinking of, but don’t want to pay money to generate a proof of concept. As a disclaimer, I’m not affiliated with Trigger in any way. It’s only a gut feeling that if I were a developer (which I’m not BTW), based solely on ease of process, and not looking into performance, pricing, or extensibility, I would be inclined to use their toolkit for cross-platform mobile development.

Tomorrow, I’ll try to make a decision on which technology to use client-side for my little POC.