Architecting Cross-Platform Mobile Frameworks Spencer Chan – Quora
Motivation Two extremes ● Fully native ○ Fully HTML+JS ○ How can we get the best of both worlds? ●
Motivation Two extremes: ● Fully native ○ Fully HTML+JS ○ How can we get the best of both worlds? ● For the last 3 years, Quora has used a custom hybrid ● framework We're very happy with it ○
Agenda 1. How Quora's app works 2. Design Decisions 3. Learnings from the past 3 years
Takeaways What can you expect if you follow the same path we did? ● Is this approach worth exploring for your apps? ● What should you look for in a publicly available ● framework? Are you better off building your own? ○
How it Works
This is a question page
This is a question page Webviews outlined in red
Meanwhile on the Server The webview loads a url ● The page is rendered by a tree of ● component objects This component is used across all platforms ●
After page load
After scrolling to the end of the answer
Pressing the button HTML + CSS
Pressing the button HTML + CSS + JS
Pressing the button HTML + CSS + JS No native code involved at all!
Now for a different example...
Here's a user profile page
Tapping here is going to show a menu ...
Native menu
Native menu
Message Passing
Message Passing
Message Passing Implemented differently for each platform ● Asynchronous message passing is more future proof ● Minimal, but can build on top of this ●
Abstraction is your friend Android iOS Java Obj-C/Swift Application JavaScript
Abstraction is your friend Web Android iOS Framework Java Obj-C/Swift JavaScript Application JavaScript
Abstraction is your friend Abstracting away platform specific code simplifies the remaining ● application code Also useful for cross-browser compatibility ● This is one of the main benefits of things like jQuery ○
Design Decisions
Design Decisions 1. HTML Content 2. Native Navigation 3. No Page Types
HTML Content Webviews outlined in red
HTML Content HTML + CSS + JS No native code involved at all!
HTML Content Alternative: native views powered by shared application code ● HTML views increase potential code sharing with websites, if you ● have one Client side vs. Server side rendering ○ HTML is great for text-heavy products like Quora ●
Design Decisions 1. HTML Content 2. Native Navigation 3. No Page Types
Native Navigation Each navigation creates a new webview and adds it to the ● native navigation stack. Pros ● Native gestures ○ Native animations ○ Cons ● Makes prefetching harder ○ More native code, less code sharing ○
Native Navigation
Native Navigation
Native Navigation
Design Decisions 1. HTML Content 2. Native Navigation 3. No Page Types
Native UI Examples: How do we implement this?
Solution 1: Page Types "This is the notifications page" ● Native code knows it should have certain buttons and styling ○
Solution 2: No Page Types "Native UI should have these buttons and this styling" ● Native code doesn't need to know about notifications ○ This makes it easier to maintain a strong abstraction barrier ● Useful if you expect to add or modify page types often ●
Avoid Message Thrash Backwards compatibility is painful ● Easier to do without page types, but still a concern ● Avoid UI thrash! ●
Design Decisions 1. HTML Content 2. Native Navigation 3. No Page Types
Learnings
Learnings 1. Be prepared to deal with webview quirks 2. Demystify loading slowness 3. Code sharing goes deeper than views 4. JavaScript lets everyone contribute
Webview Issues Problem: ● Spike in crash reports saying app ran out of memory ○ Solution: ● It was a new image loader we were trying out ○ Don't load images in JS on that webview implementation ○
Webview Issues Our webviews have an animated loading screen (the 3 dots in the middle are animated)
Webview Issues Problem: ● We want to fade out the loading screen as soon as any content is ○ visible in the webview But we can't tell from native code when webview has started ○ displaying content Solution: ● Poll the webview pixel to see when they start changing ○
Learnings 1. Be prepared to deal with webview quirks 2. Demystify loading slowness 3. Code sharing goes deeper than views 4. JavaScript lets everyone contribute
Real issues caused by webviews Bandwidth ● HTML is bigger than JSON ○ Multiple roundtrips ● Blocking on CSS/JS ○ Web performance could be the subject of a whole separate talk ○
Issues unrelated to webviews Latency ● Loading images from a server on the other side of the ○ world will be slower than loading them from a CDN Slow application code ● Example: not paginating data ○ Again, this could be a whole separate talk ○
Be scientific and rigorous Find the real root causes of your performance problems
At least there's only one thing to optimize Our app will have performance in the same ballpark as our ● mobile website We have a mobile website and care about its performance ● All of our speed efforts are going towards the same thing ●
Learnings 1. Be prepared to deal with webview quirks 2. Demystify loading slowness 3. Code sharing goes deeper than views 4. JavaScript lets everyone contribute
Shared infrastructure At Quora, the same boxes handle all platforms ● No API tier ○
Shared deployment tools We share the same continuous deployment system we use on web
Shared UI integration tests If there are 100 buttons and 3 platforms, do you need 300 tests? ● Or just 102 ●
Learnings 1. Be prepared to deal with webview quirks 2. Demystify loading slowness 3. Code sharing goes deeper than views 4. JavaScript lets everyone contribute
Javascript lets everyone contribute
Javascript lets everyone contribute Easy ramp-up ● Designers code ● Few projects get blocked on native development ●
Learnings 1. Be prepared to deal with webview quirks 2. Demystify loading slowness 3. Code sharing goes deeper than views 4. JavaScript lets everyone contribute
Conclusion There are pros and cons to any architecture ● This one has worked very well for us over the last 3 years ● If you haven't tried hybrid app development, maybe it's worth ● considering or exploring either by building your own framework, or using a publically ○ available one
Questions?
Recommend
More recommend
