Mobile gotcha


Published on

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

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mobile gotcha

  1. 1. LinkedIn MobileLessons from Building
  2. 2. Culture Product & DesignDevelopment Background Our Choices Server Client
  3. 3. Cult of Simple• Fast – App Launch – Screen to Screen Switch• Easy – Tap Count• Reliable – Don’t Crash – Repeatable
  4. 4. Product & DesignIt impacts engineering
  5. 5. Websites vs. Applications Content Focus Flow & Action FocusLong Form Layout Lists/Details Responsive DesignGood for websites; Not for applications
  6. 6. 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
  7. 7. 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
  8. 8. Development Background Approach to Engineering
  9. 9. 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
  10. 10. Libs vs. FrameworksFrameworks call App call libraries your app (Few) (Lots)
  11. 11. Process vs Evented Systems
  12. 12. Process Systems Single process/thread per requestBlock while waiting for I/O to complete Use Process/Thread Pools
  13. 13. Evented SystemsSingle Process for large number of requests Non Blocking for I/OUse 1 Process per Core on system for scale
  14. 14. 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
  15. 15. Our Choices
  16. 16. Server
  17. 17. 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
  18. 18. 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
  19. 19. Node Modules• Step to Async• Express/Connect -- Framework• Vows to Mocha• Request• Underscore
  20. 20. 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
  21. 21. File Structure / Code Size• Follow simple Rails/Django dir – Controllers, Helpers, Formatters, Templates – No Views, No Models• Code Size ~ 10K
  22. 22. 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
  23. 23. 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
  24. 24. 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
  25. 25. 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!
  26. 26. Client Native for Infinite ScrollNative for Window MangerHTML5 for everything else
  27. 27. iOS / Android Native
  28. 28. Native GotchasWeb to Native MessagingCache/Image Management Tools / Test
  29. 29. Web to Native Messaging• iFrame with URL for Ping• Native Pulls from Queue• Web-Sockets suck• REST for Native Services
  30. 30. 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
  31. 31. 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
  32. 32. Mobile Web
  33. 33. 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
  34. 34. 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
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. Tools / Gotchas• Chrome Memory Profiler – developer-tools/docs/heap-profiling• Memory Leak Tracking – leaks.html• Hardware Acceleration for DIV render only on screen DIV’s• Double Render from Cache