Download - Mobile gotcha
LinkedIn Mobile
Lessons from Building
Culture
Product & Design
Development Background
Our Choices
Server
Client
Cult of Simple
• Fast– App Launch– Screen to Screen Switch
• Easy– Tap Count
• Reliable– Don’t Crash– Repeatable
Product & Design
It impacts engineering
Websites vs. Applications
Content Focus
Long Form Layout
Flow & Action Focus
Lists/Details
Responsive Design Good 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. Frameworks
Frameworks call your app
(Few)
App call libraries(Lots)
Process vs Evented Systems
Process Systems
Single process/thread per request
Block while waiting for I/O to complete
Use Process/Thread Pools
Evented Systems
Single Process for large number of requests
Non Blocking for I/O
Use 1 Process per Core on system for scale
Evented For Mobile
Process 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
• 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
Client / Server Line Level
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 Scroll
Native for Window Manger
HTML5 for everything else
iOS / Android Native
Native Gotchas
Web to Native Messaging
Cache/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