Mobile ECM with JavaScript - JSE 2011
Download as KEY, PDF0 likes869 views
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.
Mobile ECM with JavaScript - JSE 2011
- 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
- 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.
- 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 :(
- 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
- 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
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: \n
- #6: \n
- #7: \n
- #8: \n
- #9: \n
- #10: \n
- #11: \n
- #12: \n
- #13: \n
- #14: \n
- #15: \n
- #16: \n
- #17: \n
- #18: \n
- #19: \n
- #20: \n
- #21: \n
- #22: \n
- #23: \n
- #24: \n
- #25: \n
- #26: \n
- #27: \n
- #28: \n
- #29: \n
- #30: \n
- #31: \n
- #32: \n
- #33: \n
- #34: \n
- #35: \n
- #36: \n
- #37: \n
- #38: \n
- #39: \n
- #40: \n
- #41: \n
- #42: \n
- #43: \n
- #44: \n
- #45: \n
- #46: \n
- #47: \n
- #48: \n
- #49: \n
- #50: \n
- #51: \n
- #52: \n
- #53: \n
- #54: \n
- #55: \n
- #56: \n
- #57: \n