Mobile gotcha
Upcoming SlideShare
Loading in...5
×
 

Mobile gotcha

on

  • 4,374 views

More Detailed Information about LinkedIn Mobile and its Gotcha's :)

More Detailed Information about LinkedIn Mobile and its Gotcha's :)

Statistics

Views

Total Views
4,374
Views on SlideShare
4,029
Embed Views
345

Actions

Likes
16
Downloads
40
Comments
0

8 Embeds 345

https://twitter.com 209
http://www.linkedin.com 66
https://www.linkedin.com 54
http://localhost 4
http://www.twylah.com 4
https://si0.twimg.com 4
http://twitter.com 3
https://abs.twimg.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mobile gotcha Mobile gotcha Presentation Transcript

  • 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