Building Mobile Apps (Fri Dec 1, lecture 36)

Homework due for today

Legend: : Participation | : Early | : PDF | : Portfolio | : Zipped

  1. Projects: 100% time on projects and final deliverables

Interesting (optional) reading

Mobile System Architectures

Depending on need, mobile products can be structured quite differently. Here is one way to dissect the possible scenarios.

Untethered App
  • Example: Angry Birds game
  • Server: never or rarely requires one
  • UI paradigm: must be a Local App
  • Difficulty: Can be the easiest, although there are super complex and rich games
Mobile Only App
  • Example: Instagram
  • Server: requires your own server, with intermittent or constant connection
  • UI paradigm: local App by definition. There is no user interface for the ‘server’ or ‘service’
  • Difficulty: Significant challenge to provide all the functionality over limited device.
Pure web-ui
  • Example: GMail application on iPhone
  • Server: requires your own server, and connected all the time
  • UI paradigm: web based UI, by definition
  • Difficulty: You save a lot of trouble by not having to develop local app. Much less mobile platform dependence
Mobile front end to rich web app
  • Example: Facebook app on iPhone and Android
  • Server: your own server, providing it’s own user experience, plus a connection to the mobile app
  • UI paradigm: Looks like a native app, often is a hybrid
  • Difficulty: One of the most difficult. You need to design two separate and complete user experiences
N.B. The acceptable and popular approaches are constantly evolving based on user expectation and available tools and platforms

Mobile GUI

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?

Reference: Mobility Client Architecture

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

Reference: Response time in man-computer conversational transactions

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
    • Leading framework is: PhoneGap
    • Pros/Cons
      • Not much more work than mobile web app
      • Solves some of their key weaknesses

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

*References: [100ms to Glass with Rails and Turbolinks( and Ilya Grigorik’s Breaking the 1000ms to glass mobile 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!