Jan. 20 2011 - Stefane Fermigier - Nuxeo

Mobile ECM Appswith Titanium and PhoneGap

JSE 2011

Outline

• What? And why?

• How?

• Experience reports

• Future work

Why content-enabled enterprise mobile apps?

• Open source ECM (Enterprise Content Management) vendor, since 2000

• 50 people, in Paris, Boston and San Francisco

• Provides and supports a Java-based, modular, extensible platform for ECM, as well as Document Management, Digital Asset Management and Case Management applications

Gartner: mobile apps and tablets are HOT

Source: http://blogs.techrepublic.com.com/10things/?p=1871

Gartner again(but emphasis is mine)

• “Enterprise apps will need to be designed for the tablet;”

• “Delivering these apps gets complicated due to the selection of platforms;”

• “Marketing will drive a lot of projects to utilize tablets, but these devices can be used for inspections, surveys, image capture, documentation and training.”

• “The PC era is over. Think of mobile design points.”

Technical limitations

• Limited screen size

• No keyboard; touch interface not a mouse either

• Limited computing power

• Limited network availability and bandwidth

• Limited content types

• Platforms proliferation!

• Etc.

New opportunities

• Just use your finger! (ex: Zosh)

• Geolocation

• Camera

• Ex: Barcode scanning

• Other sensors?

Don’t fight, but embrace the constraints!

• Well defined (but per-platform) UI guidelines

• New standard to the rescue: HTML5

• Mobile-specific enhancements to CSS

• Local storage (file and DB)

• Offline mode

• ...

Technological optionsMobile apps or mobile web?

Our Focus: Smart Phonesand Tablets, for Enterprise apps

Web Apps vs. Native Apps

vs.

• Objective-C

• Java / Dalvik

• C++

• .NET

• ...

Web Apps

• Multi-platform

• Depending on HTML5 support by your platform vendor

• Easy deployment

• But: UI won’t look and feel “native”

• Users will know they are in a browser

• And: Limited access to device APIs

Native Apps

• Optimized for a single platform capabilities

• Optimal user experience

• Access to sensors and proprietary APIs

• Tempting business model (App Store)

• But: Need platform-specific training, longer development time, too many platforms

Web Apps

• Pure HTML (with ad-hoc CSS)

• HTML “enhanced” with jQuery

• One Page or SOFEA web apps

• Cross-platforms, “web oriented”, frameworks

• Cross-platforms, “native UI oriented”, frameworks

• “Pure” Native apps

Native Apps

Actually there are more options

Note: 4 out of 6 are JavaScript platforms

“Pure” HTML

• Classical web application made of pages, with a bit of CSS to make them more readable on a tiny screen

• Good enough for mobile web sites

• For any kind of web applications, we can do better for a very tiny price

Example: mobile Wikipedia

“Enhanced” HTML• HTML content delivered with AJAX requests

using “link hijacking” techniques (using usually a bit of jQuery love)

• CSS and JS tricks to emulate native UI

• Libraries: iUI, jQTouch, jQuery Mobile...

• iUI: already mature, full-featured

• jQuery Mobile: recent project, focus on portability

1-page Web apps

• Applications built using the SOFEA paradigm (Service-Oriented Front-End Architecture)

• Web assets (html, js, css...) are loaded only once, then all interaction with server takes place as web services (usually JSON RPC or other “kinda restish” API)

• (Too?) Many frameworks, still immature: GWT, Sencha Touch, SproutCore Mobile, Dojo, etc.

Example:mobile gmail

• Embeds your web app into a custom-built web browser

• Removes URL and bottom tab bars

• Extends the browser JS API with platform-specific API

• Easiest transition from web app to native

• But you still get a web-like UI

• Open source community project

• Initially similar to PhoneGap (browser API extensions)

• Then refocussed on providing a JS-based API to native UI and platform APIs

• 3 supported platforms: iOS, Android and BlackBerry

• Open source startup, raised 9 M$ of VC money

“True” Native Apps

• Develop native APIs using vendor SDKs

• iOS: Objective-C / Cocoa Touch

• Android: “Java”

• BlackBerry: another Java (without “”)

• Symbian: C++

• Etc.

• Main problem: to many platforms, too little time :(

Experience report

Challenge

• Write an (iPhone) app to browse and interact with content managed by a Nuxeo DM document management server

• Experiment with several technologies

“Specs”

• Initial target platform = iPhone

• Browse content on a Document Management server

• Show content (including PDF, Office...) and metadata

• Full text search

• Recently updated documents (“timeline”)

• Store contextual data on the iPhone

Initial design

4 technologies

• Native iPhone app (Objective-C + Cocoa Touch)

• Web App using jQuery Mobile

• 1-Page App using jQuery Mobile + backbone.js (Web or PhoneGap)

• Portable app using Appcelerator Titanium Mobile

Objective-C: the results

• Took 2 days to learn the basics of Objective-C, Cocoa Touch, XCode

• Took about 3 days for a very basic prototype

• Unstable, now abandoned

• Code still there: hg.nuxeo.org/mobile/iphone

DEMO

Objective-C: the Good

• Learning a new language is intellectually stimulating :)

• This is good old UNIX, you can use open source libraries in C if you need

• Small ecosystem of open source libraries around iOS

Objective-C: the Bad

• Learning a new language takes time, learning a new IDE even more, and you don’t want to switch from two IDEs too often

• Objective-C feels like I’m back in 1990 (explicit pointer and memory management)

• Only for iOS, as you would guess

jQuery Mobile: the results

• Took 1/2 a day to get a basic demo (browsing, search) running

• Standard HTML pages generated on the server, AJAX magic managed by the framework

DEMO

jQuery Mobile: the Good

• Very easy to do on the server

• Fast turnaround thanks to Nuxeo WebEngine

• Easiest deployment option (you don’t need to deploy on the phones!)

jQuery Mobile: the Bad

• The browser’s forward/back buttons are in the way, but you have to use them after looking at a piece of content

• No easy way to develop a tab bar as in my design (and there is already the browser tab bar on the way)

Variant: as a 1-page app

• Exact same application, built as a 1-page app using jQuery Mobile and backbone.js

• Only interaction with the server (after initial assets loading) is via JSON-RPC

• HTML generated on the client (mustache.js)

And as a PhoneGap App

• It’s trivial to convert the whole app into a native App using PhoneGap

• The browser URL bar and navigation buttons disappear

• But now there is no way to come back from a PDF or image view

• Have to rely on third-party PhoneGap plugins or develop our own (-> back to native)

Appcelerator: the results

• Took about 1 day to learn how to use the platform

• Took about 3 days to create a reasonably good looking, alpha-quality app

• 90% of the time spent on front-end, 10% on back end (JSON REST API with WebEngine)

• Will probably take 2 or 3 more days to make it App Store ready

Appcelerator: the Good

• JavaScript much easier to learn than Objective-C

• Specially when you already know JavaScript ;) (or even Java)

• Productivity 2x to 5x higher that with native Cocoa-Touch, slightly lower than SOFEA

• Multi-platform promise seems to work

Appcelerator: the bad

• “IDE” is quirky and unstable

• And not really an IDE actually!

• Might change with the Aptana acquisition

• No debugger, longer code/compile/deploy turnaround

• Slower than native

• Another layer of indirection

• Apple doesn’t want you to use it (resolved!)

Conclusion of the experiment

Native (Obj-C)

• Not worth of your time, unless you:

• Are (or have) a dedicated iOS developer

• Want to compete on design to make $$ on the App store

• Want to be the first to leverage newly introduced iOS features

• ... which was not our focus

Mobile HTML (5)

• The fastest way to get a simple application up and running (no App Store hassles)

• The most multi-platform approach

• But: Doesn’t provide users with a 100% native look and specially feel

• Doesn’t give you access to all the local features of the device

• Specially wrt document viewing

• Can be complemented with PhoneGap

Appcelerator

• Gives you native look and feel and platform access, with an original but familiar API, at the price of slightly longer development time than pure HTML

• Supports the platforms that make business sense to us

• Not 100% bug-free, will always lag behind native platform, slower than native

Additional insights

• JavaScript programming (API, not language) felt initially very ≠ between HTML5 and Titanium

• But if you do two projects in parallel (HTML5 for maximal portability, Titanium for native goodness) you can probably share some code

• Utility functions and low-level stuff (network, models, preference...)

• And maybe some of the interaction stuff too

One more thing...

These apps have not been (eventually) written in

JavaScript but in CoffeeScript

CoffeeScript?

• Alternative syntax (syntactic sugar) for JavaScript (only “the good parts”), inspired by Ruby and Python

• Gives: classes, “->” notation, list comprehensions...

• Much (IMHO) easier to read than JS

• Semantically, it’s still JavaScript though

• Cons: no IDE nor debugger support

Code Sample

Conclusion andFuture Work

Generic document browsing App

• New web mobile browsing module to be added to Nuxeo Markeplace and Nuxeo DM 5.4.1 release

• Companion iOS App (based on Titanium)currently under review on the App Store

• Work will continue to provide access to more Nuxeo DM features, better

Business-specific apps

• We’re ready to work with our customers and partners on business-specific apps

• Choice between web apps and native (Titanium) apps is up to the customer, and will depend on features, devices used, etc.

• We intend to leverage our business API (Content Automation) + develop a specific framework to ease development

More info

• Watch http://blogs.nuxeo.com/

• Source code:

• https://bitbucket.org/sfermigier/nuxeo-mobile-web

• https://github.com/sfermigier/nuxeo-mobile