Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Mobile ECM with JavaScript - JSE 2011


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Mobile ECM with JavaScript - JSE 2011

  1. 1. JSE 2011 Mobile ECM Appswith Titanium and PhoneGap Jan. 20 2011 - Stefane Fermigier - Nuxeo
  2. 2. Outline• What? And why?• How?• Experience reports• Future work
  3. 3. Why content-enabledenterprise mobile apps?
  4. 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. 5. Gartner: mobile apps and tablets are HOTSource:
  6. 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. 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. 8. New opportunities• Just use your finger! (ex: Zosh)• Geolocation• Camera • Ex: Barcode scanning• Other sensors?
  9. 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. 10. Technological options Mobile apps or mobile web?
  11. 11. Our Focus: Smart Phonesand Tablets, for Enterprise apps
  12. 12. Web Apps vs. Native Apps • Objective-C • Java / Dalvik vs. • C++ • .NET • ...
  13. 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. 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. 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. 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. 17. Example: mobile Wikipedia
  18. 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. 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. 20. Example:mobile gmail
  21. 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. 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. 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. 24. Experience report
  25. 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. 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. 27. Initial design
  28. 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. 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:
  30. 30. DEMO
  31. 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. 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. 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. 34. DEMO
  35. 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. 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. 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. 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. 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
  40. 40. 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
  41. 41. 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!)
  42. 42. Conclusion of the experiment
  43. 43. 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
  44. 44. 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
  45. 45. 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
  46. 46. 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
  47. 47. One more thing...
  48. 48. These apps have not been (eventually) written inJavaScript but in CoffeeScript
  49. 49. 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
  50. 50. Code Sample
  51. 51. Conclusion and Future Work
  52. 52. 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
  53. 53. 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
  54. 54. More info• Watch• Source code: • mobile-web • mobile