Mobile and IBM Worklight Best Practices
Download as PPTX, PDF5 likes8,718 views
This document provides an overview and best practices for developing mobile applications using IBM Worklight. It discusses development tools and frameworks, RESTful services, Worklight adapters, and the Worklight application lifecycle including building, testing, and deploying applications. It also covers updating applications and provides other tips such as preferring a single page architecture and versioning services and adapters. The document is intended for a WebSphere User Group presentation on Worklight mobile development.
Mobile and IBM Worklight Best Practices
- 1. Mobile and IBM Worklight Best Practices WebSphere User Group, Edinburgh, 24th Sept 2013 Andrew Ferrier andrew.ferrier@uk.ibm.com Contributions from: Nick Maynard Sean Bedford Jon Marshall and others….
- 2. Agenda • Recap: Web 2.0 & Mobile Landscape • Development Time – Toolkits & Frameworks • “Run” Time – RESTful Services and WL Adapters – Worklight Lifecycle – Build, Test, Deploy • Updates/Other Best Practices
- 3. Web 1.0: what we used to do Static HTML content, little- to-no-dynamicity Server-side-driven content Perhaps with a small amount of JavaScript for effects or form validation Traditionally written with a variety of technologies – Servlets, JSPs, PHP, etc.
- 4. Embrace Web 2.0 Server-side-driven content J2EE, Servlets, JSPs, PHP, etc. Rich client-side JavaScript XHRs for data over RESTful Services JSON Payloads
- 5. Hire the Skills Needed! (The Programming Model)
- 6. Understand the Mobile Landscape
- 7. Understand Worklight Native Shell Web Code <!DOCTYPE html PUBLIC <html> <! - - created 2003-12-1 <head><title>XYZ</title </head> </body> </html> Device APIs
- 8. Understand Worklight EnterpriseBackendSystems& CloudServices Worklight Server User authentication and mobile trust Mashups and service composition JSON Translation Adapter Library for backend connectivity StatsAggregation Unified Push Notifications Client-Side App Resources Direct Update Mobile Web Apps Device Runtime Cross-Platform Compatibility Layer Encrypted and Syncable Storage Runtime Skinning Server Integration Framework Reporting for Statistics and Diagnostics ApplicationCode HTML5, Hybrid, and Native Coding Optimization Framework Integrated Device SDKs 3rd Party Library Integration BuildEngine Worklight Studio Worklight Console Push /SMS Management Reporting and Analytics App Version Management Public App Stores Worklight Application Center Development Team Provisioning App Feedback Management Enterprise App Provisioning and Governance Blackberry Android iOS Windows Phone Java ME Windows 8 SDKs Mobile Web Desktop Web 1 2 3 4 5
- 10. Use a Toolkit • JavaScript-based libraries, written in JavaScript, used on top of JavaScript itself • Why? – Smooth out the JavaScript’s rough edges – Add additional features, UI widgets, etc.
- 11. Use Dojo • The largest players in the market are • Generally, IBM „prefers‟ Dojo – Shipped with IBM Worklight, WebSphere Feature Pack for Web 2.0 and Mobile, etc..
- 12. Why Dojo? • Enterprise-grade toolkit and feature set • Stronger support for structuring large applications – e.g. Class system (dojo/declare) • Better focus on internationalization, accessibility, etc. • But jQuery is a supported choice too for Worklight and still a sensible choice
- 13. Consider using framework(s) • Coding without a JS toolkit in 2013 is like entering the program in binary • Frameworks sit on top of a toolkit, but gives you other things that are missing. HTML CSS JS Toolkit Framework Your Application
- 14. Consider using framework(s) • For example, a framework might give you: – Endpoint management (stubbing) – State / session management – Responsive Design Benefits (e.g. dojox/app) – Templating – Single-page architecture support – Standardised error-handling – (… other application-level stuff)
- 15. Framework Options • For Dojo: – Dojo itself - dojox/mobile, dojox/app, dojox/mvc – issw/mobile & issw/pocMobile – Your own custom framework • Not as bad an idea as it sounds! • For jQuery: – Angular (MVW), mustache (templating), RequireJS (code loading), Knockout (MVC), Backbone (MVC), Handlebar (templating) etc...
- 16. Prefer Single Page Architecture http://x.com/page1 Submit http://x.com/page2 HTTP Server http://x.com/page1 Submit HTTP Server MPA SPA Page 1 Page 2 Page 2Page 1
- 17. Prefer Single Page Architecture • (… for mobile at least) • Only one.html page • Improves performance • Dojo Mobile has this concept built in – dojox/mobile/View • Reuse this concept for Hybrid too
- 18. Understand Debugging Options • iOS 6+: Web Inspector (Physical & Emulated Phone) • Android 4.x: Chrome Remote Debugging • Desktop Browser with Debugging Support – Chrome, Firefox + Firebug (plain or Worklight simulator) • Worklight logging • Etc…
- 19. RESTFUL SERVICES AND WL ADAPTERS
- 20. RESTful Services • The world (at least UIs) are moving to simpler services – A RESTful style - plain HTTP GET, PUT, POST, DELETE – JSON as the data format • Practically mandatory for consumption by Web 2.0 clients GET http://mycorp.com/customer/12 34 { “name”: “Fred Bloggs”, “address”: “123 Anytown” }
- 21. RESTful Best Practices for Mobile Web • Use verbs liberally: GET, PUT, POST, DELETE – http://mycorp.com/services/createCustomer • Keep them stateless (independent) • Don’t send data that’s not needed – Keep payloads small – Combine related services • Think about cacheability • Think about pagination / querying / sorting
- 22. WL Adapters • WL adds adapter framework – Server-side JS and XML components – Client-side invocation using JS API • Supports HTTP, JMS, SQL, and Cast Iron adapter types – Most common use is HTTP adapter to integrate with JSON/REST or SOAP/HTTP
- 23. WL Adapters - REST & HTTP • You could use RESTful services directly from WL container with conventional XHRs, but you lose: – WL’s authentication mechanism for services – The ability to use the WL server as a “choke point” – WL Logging/Auditing – Analytics integration – Tealeaf usage is easier
- 24. Re-expose even RESTful services • Even for services already exposed over REST, re-expose them using the WL HTTP Adapter. – This is comparatively straightforward to do. • You can also use SOAP services from WL – Abilities are limited at the moment so for more sophisticated scenarios, consider an ESB (e.g. Cast Iron)
- 25. Consider Service & Adapter Versioning • For RESTful Services: URL: /maps/version/2/map?... Custom HTTP Header: X-Version 2.1 Media Types/Content Negotiation: application/json;version=1 • Versioning Worklight Adapters requires renaming them
- 26. LIFECYCLE
- 27. Library Systems • Worklight can work with most version control systems that integrate with Eclipse • Common choices: – Rational Team Concert (packaged w/ WL as IBM Mobile Development Lifecycle Solution) – Git – Subversion
- 28. Library Systems 2 • There are files that must be excluded as they are part of WL generated resources, see here: – http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0 /index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2 Fdevref%2Fr_integrating_with_source_contro.html
- 29. Building – Web Components • You will want to automate your build (minification) • Worklight Hybrid: Consider a pre-build approach for your web code. – Faster dev time turnaround • Mobile Web: Consider running a build every time, using e.g. Dojo Build: http://dojotoolkit.org/reference- guide/1.9/build/ • Running jslint / jshint to catch JS errors
- 30. Building • Then build WL project itself • WL provides the <app-builder> and <adapter-builder> ANT tasks – Only builds the Server portion of the projects - the .war customisation file, the .wlapp file, and the .adapter files. – You will need to build the .apk and .ipa files using platform-native process.
- 31. Building • During build, externalise certain things: – worklightServerRootUrl in application- descriptor.xml – server/conf/worklight.properties – maxConcurrentConnectionsPerNode for adapters – domain, port for the backend service in adapter.xml
- 32. Deploying • Deploy the .war using relevant application server method – Whenever server/conf/* changes • Deploy the .wlapp and .adapter server-side portions of the application using <app- deployer> and <adapter-deployer> ANT tasks.
- 33. Deployment Topology • Options include: – WebSphere Application Server ND - familiar – WAS Liberty Profile – simpler, newer • Consider HTTPS, load spraying
- 34. Deploying to Phones • You still need to get the native application (.ipa, .apk, etc.) onto your user‟s phones. – Dev Time/Small/Adhoc Projects: Manual install – Testing lifecycle: AppCenter - comes with WL server editions • Install via AppCenter Web or AppCenter App – B2C: public App Stores (Apple App Store, Google Play Store) – B2E: IBM Endpoint Manager or similar
- 35. Testing • Typically you‟ll want to test: – Manual UI on physical phones • Coverage across devices – Automated UI - mocking framework and automated test tool • V6.0 - Mobile Test Workbench for Worklight – (Worklight) Adapters / (Mobile Web) REST Services - load / performance / functional tests - just HTTP
- 37. UPDATES
- 38. Two Ways to Update - Method 1 • Update your web code only • Don’t change the version number of the application • Redeploy .wlapp only • Implicitly encourages a “Direct Update” next time client connects.
- 39. Two Ways to Update - Method 2 • Method 2: – Update web code and custom native code – Do update the application version number – Re-release via binary method (App Store, etc.)
- 40. Updating Worklight Itself • Upgrade all studio instances and WL environments • All apps at all existing application versions need to be re-built (.war/.wlapp/.adapter) • Re-release an app using method 2 – Gets new Device Runtime onto end-users‟ phones • But end-users can continue using old app; wire protocol is backward-compatible
- 41. OTHER TIPS & BEST PRACTICES
- 42. Client-side Worklight • Hybrid App: Don‟t optimize for size of the client like you would do for Mobile Web • Nevertheless, there is still a browser control underneath • Use WL.Logger.{debug,error} API, logging in development environment is customizable, & log the username on errors
- 43. Client-side Worklight • Understand handling errors on client- side, in particular adapter invocations: – http://www.ibm.com/developerworks/websphere/techjournal/1212_p aris/1212_paris.html?ca=drs- • Use connectOnStartup: false, with WL.Client.Connect() after startup - gives more startup control – Must be done for use of direct updates, push notifications, authentication, adapter use
- 44. Server-side Worklight JavaScript • Discourage use of more than one adapter – Cannot share JavaScript code (can share Java though) • Again, understand how to handle errors from adapter invocations (same article). • Again, use WL.Logger API - has various levels of logging, can be configured on server. Log the username on errors. – Note: Log level control is currently limited with WAS