Mobile gotcha

LinkedIn MobileLessons from Building

Culture Product & DesignDevelopment Background Our Choices Server Client

Cult of Simple• Fast – App Launch – Screen to Screen Switch• Easy – Tap Count• Reliable – Don’t Crash – Repeatable

Product & DesignIt impacts engineering

Websites vs. Applications Content Focus Flow & Action FocusLong Form Layout Lists/Details Responsive DesignGood for websites; Not for applications

Interaction vs. Visual• Design a house floor plan• Focus on Rooms and Hallways• Stay away from Paint, Furniture Carpet• Has & Does for each screen• Black & White then Color

Adjust App Platforms• On Screen vs. Hardware Back• Up vs. Back / Stacks vs. Pages• Pull to Refresh vs. Button Refresh• Settings Room Location• Visual Design

Development Background Approach to Engineering

HTML5 vs Native• What is the skillset of the team?• What is your front door?• Which platforms are you targeting?• Phone Gap vs Titanium vs XXX

Libs vs. FrameworksFrameworks call App call libraries your app (Few) (Lots)

Process vs Evented Systems

Process Systems Single process/thread per requestBlock while waiting for I/O to complete Use Process/Thread Pools

Evented SystemsSingle Process for large number of requests Non Blocking for I/OUse 1 Process per Core on system for scale

Evented For MobileProcess Systems great for high compute Evented Systems great for I/O bound With mobile client rendering, evented systems best for front end

Our Choices

Server

Mobile Server• Scaling Node• Node Modules• Logging vs Tracking vs Metrics• File Structure / Code Size• Client / Server Line Format• Server / Server Line Format• Latency vs Bandwidth• Gotchas

Scaling• Load Balancer talking to each node instance running on separate cores• In Node .8, finally have master/child file handle sharing based evented model• 150 qps per core per instance• 60 MB of RAM for an instance

Node Modules• Step to Async• Express/Connect -- Framework• Vows to Mocha• Request• Underscore

Logging/Monitoring/Tracking• Logging used for sending lots of text information – useful for debugging• Monitoring is for sending counters for realtime monitoring: Product and System – Typical: Query Rate, Response Code, Time for request, Page Views, Actions – Cube from Square• Tracking is for product metric queries – Get into a database for queries – Needed for doing Uniqing and Pathing queries

File Structure / Code Size• Follow simple Rails/Django dir – Controllers, Helpers, Formatters, Templates – No Views, No Models• Code Size ~ 10K

Client / Server Line Level• Single Request per screen• JSON is template based• Updateable on Server• Don’t add: – Links – Styles – Positioning• Node is part of the client NOT the server

Server / Server Line Level Format• Stream Data – Metrics, Logging, Events, etc – Kafka, Thrift, Avro, Protocol Buffers etc.• Request/Response Data – HTTP/JSON – REST Endpoints for actual data models – Not much faster for performance

Latency vs. Bandwidth• Latency is the issue with mobile not bandwidth• Establish and keep the socket open for ping• Use a ping and pull model not a true push• Easier to scale ping/pull model

Node Gotchas• Exception Handling• Don’t listen on startup till you are connected to down stream services• Okay to die and respawn• httpClient.agent = false• Turn on console in production• NO BLOCKING!

Client Native for Infinite ScrollNative for Window MangerHTML5 for everything else

iOS / Android Native

Native GotchasWeb to Native MessagingCache/Image Management Tools / Test

Web to Native Messaging• iFrame with URL for Ping• Native Pulls from Queue• Web-Sockets suck• REST for Native Services

Cache/Image Management• Store all data in url/result hash• Render data from Hash• Render again from server response• Image src should be set to small image when off screen

Tools/Test• iWebInspector / Weinre• Charles Proxy for req debugging• Pain when OS upgrade• Selenium with Safari Simulator (Web Parts)• Instruments UIAutomation / Robotium (Native)• Layout Test: DumpRender + ImageDiff (5%)• Vcr.js – Fixture Creater• Android Emulator Super Slow to have to do on build machine with catchup

Mobile Web

Screen vs Page• App is multiple Screens in one page• Page is a browser Page and has an implication of JS Load/Parse time• Screen to Screen move is div show/hide

Backbone.js• Controls Routing from Screen to Screen• Controls Screen lifecycle (load, show, hide)• Controls View Updating based on Model Change• Has Model construct for Validation• BaseRouter to Backbone – Transitions, screen life cycle• M V C links in Backbone lead to mem leaks

Libraries• Zepto – Manipulate the DOM• iScroll – Inertial Scrolling on iOS – Does not work on Android – Pull to Refresh• Underscore – Collection helpers and binding constructs, templating

Build / Packaging• Closure – Minify, Comment Removal, Template Compilation• SASS – Variables, Functions, Selector Inheritance• Bundle (set of screens) – Local, Template, Controllers/Views• Build independently and resuable

Startup• Initial – Index.html – List of bundle files – Store all in Local Storage – Backbone starts home bundle• Upgrade – Index.html – MD5 has for each file – Compare/Download Diff – Store in Local Storage

Tools / Gotchas• Chrome Memory Profiler – https://developers.google.com/chrome- developer-tools/docs/heap-profiling• Memory Leak Tracking – http://gent.ilcore.com/2011/08/finding-memory- leaks.html• Hardware Acceleration for DIV render only on screen DIV’s• Double Render from Cache

https://twitter.com	174
http://www.linkedin.com	10
http://localhost	4
https://si0.twimg.com	4
http://twitter.com	3
http://www.twylah.com	1
https://abs.twimg.com	1

Mobile gotcha

by phegaro on Oct 10, 2012

Accessibility

Categories

Upload Details

Usage Rights

7 Embeds 197

Statistics

Mobile gotcha Presentation Transcript