This document summarizes an experience report on developing mobile apps to access content from an Enterprise Content Management system using different technologies. It discusses using native iOS development with Objective-C, mobile web apps with jQuery Mobile, hybrid apps with PhoneGap, and cross-platform apps with Appcelerator Titanium. It finds that Titanium provides the best balance of native look and feel with multi-platform support and productivity. Future work includes generic browsing apps and business-specific mobile apps.

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

2. Outline
• What? And why?
• How?
• Experience reports
• Future work

3. Why content-enabled
enterprise mobile apps?

4. • 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

5. Gartner: mobile apps and
tablets are HOT
Source: http://blogs.techrepublic.com.com/10things/?p=1871

6. 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.”

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

8. New opportunities
• Just use your finger! (ex: Zosh)
• Geolocation
• Camera
• Ex: Barcode scanning
• Other sensors?

9. 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
• ...

10. Technological options
Mobile apps or mobile web?

11. Our Focus: Smart Phones
and Tablets, for Enterprise apps

12. Web Apps vs. Native Apps
• Objective-C
• Java / Dalvik
vs. • C++
• .NET
• ...

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

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

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

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

17. Example: mobile
Wikipedia

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

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

20. Example:
mobile gmail

21. • 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

22. • 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

23. “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 :(

24. Experience report

25. Challenge
• Write an (iPhone) app to browse and
interact with content managed by a Nuxeo
DM document management server
• Experiment with several technologies

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

27. Initial design

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

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

30. DEMO

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

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

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

34. DEMO

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

36. 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)

37. 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)

38. 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)

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

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

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

44. Conclusion of the
experiment

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

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

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

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

49. One more thing...

50. These apps have not been
(eventually) written in
JavaScript but in CoffeeScript

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

52. Code Sample

53. Conclusion and
Future Work

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

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

56. More info
• Watch http://blogs.nuxeo.com/
• Source code:
• https://bitbucket.org/sfermigier/nuxeo-
mobile-web
• https://github.com/sfermigier/nuxeo-
mobile