Homework due for today
Legend: : Participation | : Early | : PDF | : Portfolio | : Zipped
- Projects: 100% time on projects and final deliverables
For further study
- Please close all laptops and other electronics during class from now on
Mobile System Architectures
Depending on need, mobile products can be structured quite differently. Here is one way to dissect the possible scenarios.
- 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: WikiPanion
- Server: requires your own server, with intermittent or constant connection
- UI paradigm: local App. The primary (and sometimes only) access to functionality is over an app. There is no user interface for the ‘server’ or ‘service’
- Difficulty: Significant challenge to provide all the functionality over limited device.
- Example: CNN Lite
- Server: requires a dedicated 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: Server/Service Considerations
- Practically all mobile apps are backed by a server
- Do you own it or does it belong to a third party?
- Can you change the API? Can the API change from under you?
- What kind of information needs to be sent between mobile app and server?
- How to think about this information
- How much data are we talking about?
- What are user expectations of perforamnce and latency?
- What should the app do when there’s no network?
- Are there likely to be firewalls in the way?
- Does the client have to reach the server, or vice versa or both?
- Commonplace today is “REST” over “HTTP”.
- But all is changing all the time!
- FollowTheMusic (Abhishek Kulkarni, Lizzie Koshelev, Devi Acharya, Deniz Amado)
- Health Insurance Decoder (Ziyu Qiu (Andrea), Ian Hankin, Xi Chen (Cici), Alyssa Goncalves)
- AspirinX (Yaoming Zhan, Shulin Chan, James Wang, Guillermo Narvaez)
- AR DnD (Akiba Sato, Bruce Chen, Cam Braunstein, Tom Willkens)
- Off Campus Housing (Ian Leeds, Yan Shneyderman, and Jonathan Turner)
- MyJira (Haotian Sun, Jinli Yu, Yuan Zhou, Phoebe Zhang)
- WExchange (Alec Rodgers, Kevin Wang, Abu Batjargal, Paul Cabrera)
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
- 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
- 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
- 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
What is TurboLinks?
- 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)
- 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
- 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!
Look at next class