Lessons Learnt implementing a Worklight-based eCommerce mobile solution – Why is it good?

View Github Repository Open presentation in a new window

bedfordsean

See all presentation from bedfordsean

Lessons Learnt implementing a Worklight-based eCommerce mobile solution – Why is it good?

0 0

bedfordsean.github.io

On Github bedfordsean / bedfordsean.github.io

Lessons Learnt implementing a Worklight-based eCommerce mobile solution

Sean Bedford / @bedfordsean / SEANBEDFORD@uk.ibm.com

What is Worklight? - Server side

  • Sits inside a WAS/J2EE container
  • Connects to a variety of back end services
  • Geared up specifically to serve mobile devices
  • Contains more "plumbing" than just Cordova, although it does include Cordova

What is Worklight? - Client side

The Bigger Picture

  • Easy to do authentication
  • Mashups easy in WL adapters
  • Direct "Hybrid" updates to devices possible
  • Mobile specific analytics "for free"

Why is it good?

  • Out-of-box support for app analytics (Device, OS, code version)
  • Direct update provides a powerful way to quickly patch issues
  • App versioning scheme allows operational management of multiple deployed versions
  • Security model provides easy control of back end resources
  • Not "just Cordova (PhoneGap)" - native APIs for iOS, Android, and devices running JavaME

Cordova Primer

  • API layer between web container and native functionality
  • You can write a new Cordova plugin with native implementations on each platform you want to support
  • This plugin can then be wrapped in to JavaScript to allow for calling from a web container

Client side code

MVC approach

  • How do you store data?
  • How do you display data?
  • How do you handle the business rules?

Pick a framework that supports MVC such as jQuery Mobile, AngularJS, or Dojo. It will make your life MUCH easier :-)

  • MVC approach
  • Best to pick a framework that supports this flow
  • Stateful views that automatically update based on data = good
  • E.g. jQuery Mobile, AngularJS, Ionic, Dojo, etc

Think of the user

  • Think about how the user is going to interact with your app
  • Consider controls, text sizes, readability. Apple recommends >= 44px * 44px tappable area and 17pt+ font size
  • Design, prototype, and test with actual end-users
  • Don't be afraid to scrap a design and start again
  • Prototyping VERY important in early project stages
  • Demo early and often to the business stakeholders. UI+UX is very subjective
  • Read Apple Human Interface Guidelines (https://developer.apple.com/library/ios/documentation/userexperience/conceptual/MobileHIG/index.html)

Common UI Patterns

  • Think about common mobile patterns. Ok to have something custom, but remember that these platforms have established paradigms already!
  • Chevrons to indicate a view to transition to, coloured links that can be tapped, tabble area size, informational prompts
  • Lists, Modals, tables, all common
  • Best to also pick a framework that allows you to do all of these, or most of them, to save on custom work

Server side code

Consistent endpoint management

  • Common problem: How to handle errors, timeouts, bad responses consistently?

  • Solution: Provide a consistent client- and server-side endpoint

Allows for control point to intercept (amongst other things)
  • User session timeout
  • Back end server error (404, 500)
  • Back end server returning something other than JSON
  • Back end server redirect
  • User error/info messaging

Go-live Considerations

  • Think about end-end versioning - does your back end support multiple live versions?
  • Think about security - validation in the front end only is never enough
  • Think about how the application will load and service frequent requests (startup, browse, login...)
  • Think about operational management (logging, reporting, information for support)

Basic Worklight user authentication

  • A key feature of Worklight is it's security model
  • This allows the securing of a back end call with a single line of code (once it is set up)

Authentication flow

Example - Set up

  • Create a challenge handler in your code. This will need to issue a username/password, or some other authentication toekn
  • Set up a realm and security test in authenticationConfig.xml. In this security test, state you want to use adapter functions to authenticate the user
<customsecuritytest name="MySecurityTest">
<test isinternaluserid="true" realm="MySecureRealm" step="1">
</test></customsecuritytest>	
...			
<realm loginmodule="StrongDummy" name="MySecureRealm">
<classname>com.worklight.integration.auth.AdapterAuthenticator</classname>
<parameter name="login-function" value="AuthenticationAdapter.onAuthRequired">
<parameter name="logout-function" value="AuthenticationAdapter.onLogout">
</parameter></parameter></realm>

Example - Securing a function

  • In your adapter's XML file, add a security test to a function
<procedure name="myUnsecuredProcedure"></procedure>
<procedure name="mySecuredProcedure" securitytest="MySecurityTest"></procedure>
  • This will trigger the security test against the realm you've defined in authenticationConfig.xml
  • This in turn will issue a challenge for "MySecureRealm" if there is no user logged in for that realm
  • At this point, your client code can handle the challenge, by providing authentication details, tokens, or similar
  • After authenticating, Worklight can re-issue the original request and return a result from the back end service
  • Client req > WL Server security check > Issue Challenge > Provide auth details > WL Server verify > Re-issue orig request
  • Will issue challenge on first request to secured procedure
  • Request can then be made again after auth
  • WL server can store details of the user session, or you can handle this yourself

Questions?