Mobile ECM with JavaScript - JSE 2011

JSE 2011 Mobile ECM Apps with Titanium and PhoneGap Jan. 20 2011 - Stefane Fermigier - Nuxeo

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 ﬁnger! (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 options Mobile apps or mobile web?

Our Focus: Smart Phones and Tablets, for Enterprise apps

Web Apps vs. Native Apps • Objective-C • Java / Dalvik vs. • 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-speciﬁc training, longer development time, too many platforms

Actually there are more options Web Apps Native Apps • Pure HTML (with ad- • Cross-platforms, “web hoc CSS) oriented”, frameworks • HTML “enhanced” • Cross-platforms, with jQuery “native UI oriented”, frameworks • One Page or SOFEA web apps • “Pure” Native apps 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

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

• Embeds your web app into a custom- built web browser • Removes URL and bottom tab bars • Extends the browser JS API with platform-speciﬁc 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 :(

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, Ofﬁce...) and metadata • Full text search • Recently updated documents (“timeline”) • Store contextual data on the iPhone

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

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

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!)

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 ﬁrst 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

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

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

Mobile ECM with JavaScript - JSE 2011

More Related Content

What's hot

Similar to Mobile ECM with JavaScript - JSE 2011

More from Nuxeo

Recently uploaded

Mobile ECM with JavaScript - JSE 2011

Editor's Notes