Mobile App Approaches

Mobile: Client Considerations

Criteria for evaluation
  • Are both iOS and Android required? How about smaller platforms?
  • Is access to hardware necessary? (e.g. GPS, camera, etc)
  • Is an Offline or occasionally connected scenario required?
  • Is a native look and feel mandatory?
  • How much effort/resources/time/money are you able to invest?
  • What are the performance and responsiveness requirements?
  • How will user discover, install and upgrade the application?
Guide to performance goals
  • 0.1 Second: Looks and feels instant
  • 1.0 Seconds: Maximum before flow is interrupted
  • 5 Seconds: Maximum before losing user’s attention and focus

Overview of Approaches

  • Mobile web based application
    • Responsive HTML inside Mobile browser (e.g. Safari or Chrome)
    • Plus “turbolinks” and good caching
    • Pros/Cons:
      • Simplest to implement
      • Levarages existing HTML
      • Does not have native look and feel
      • Cannot access hardware of the mobile
      • Cannot be “installed” via the app store
      • Requires continuos connectivity
  • Native Mobile App
    • SWIFT on iOS
    • Java on Android
    • Pros/Cons:
      • Most complicated and expensive to implement
      • Hard to share code between platforms
      • Perfectly native user experience
      • Full access to hardware
      • Distribution through app store
  • Hybrid App
    • Mobile web app
    • Embedded in a thin native shell application
    • Some of the screens are web and some are native (degree differs)
    • App is installed via stores
    • Pros/Cons
      • Not much more work than mobile web app
      • Solves some of their key weaknesses
      • Be very careful picking the framework. They come and go!

Enhancing Mobile Web Based Applications

  • Rails specific solution
  • Fully revamped in Rails 5
  • Unlike Rich JS Clients, controllers are sending html to clients
  • Fights to preserve state in the browser instead of re-sending it (JS, CSS and even parts of the DOM)
  • Pros/Cons
    • Stay in Rails. Far smaller incremenental investment for better web performance
    • On mobile, network delay is typically 300-700ms, so Turbolinks is not going to break the 100ms barrier
Rich Client GUI JS Frameworks
  • Very hot right now
  • Personally not (yet) a super fan
  • Awesome results, but very high investment
  • Shifting sands
  • Web Components: Combining appearance and behavior. Still in flux, e.g. Component Based Web UI
  • Examples: Ember, React, Angular, BackBone, Aurelia, and many others
How they work
  • Create a stateful experience in the browser
  • Use REST to get and store application state
  • Use browser’s local data store as needed to achieve disconnected experience
  • Data mapping to connect data displayed in a view with data in the model
  • Use a REST-like API to access data and state from the server
  • In Rails world, use Rails-API

In conclusion

  • Remember the YAGNI principle
  • Make sure you understand your requirements
  • Don’t invest in an architecture before your users/market demand it
  • Be very careful of building on unstable/shifting/marshes!