Architecting Cross-Platform Mobile Frameworks Spencer Chan Quora - - PowerPoint PPT Presentation

▶
architecting cross platform mobile frameworks
SMART_READER_LITE
LIVE PREVIEW

Architecting Cross-Platform Mobile Frameworks Spencer Chan Quora - - PowerPoint PPT Presentation

Jul 14, 2023 472 likes •1.1k views

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

slide-1
SLIDE 1

Spencer Chan – Quora

Architecting Cross-Platform Mobile Frameworks

slide-2
SLIDE 2

Motivation

  • Two extremes

○ Fully native ○ Fully HTML+JS

  • How can we get the best of both worlds?
slide-3
SLIDE 3

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

slide-4
SLIDE 4

Agenda

1. How Quora's app works 2. Design Decisions 3. Learnings from the past 3 years

slide-5
SLIDE 5

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?

slide-6
SLIDE 6

How it Works

slide-7
SLIDE 7

This is a question page

slide-8
SLIDE 8

This is a question page Webviews

  • utlined

in red

slide-9
SLIDE 9
  • The webview loads a url
  • The page is rendered by a tree of

component objects

  • This component is used across all platforms

Meanwhile on the Server

slide-10
SLIDE 10

After page load

slide-11
SLIDE 11

After scrolling to the end of the answer

slide-12
SLIDE 12

Pressing the button HTML + CSS

slide-13
SLIDE 13

Pressing the button HTML + CSS + JS

slide-14
SLIDE 14

Pressing the button

No native code involved at all!

HTML + CSS + JS

slide-15
SLIDE 15

Now for a different example...

slide-16
SLIDE 16

Here's a user profile page

slide-17
SLIDE 17

Tapping here is going to show a menu ...

slide-18
SLIDE 18

Native menu

slide-19
SLIDE 19

Native menu

slide-20
SLIDE 20

Message Passing

slide-21
SLIDE 21

Message Passing

slide-22
SLIDE 22
  • Implemented differently for each platform
  • Asynchronous message passing is more future proof
  • Minimal, but can build on top of this

Message Passing

slide-23
SLIDE 23

Abstraction is your friend

iOS Obj-C/Swift Android Java Application JavaScript

slide-24
SLIDE 24

Abstraction is your friend

iOS Obj-C/Swift Android Java Web Framework JavaScript Application JavaScript

slide-25
SLIDE 25
  • 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

Abstraction is your friend

slide-26
SLIDE 26

Design Decisions

slide-27
SLIDE 27

Design Decisions

1. HTML Content 2. Native Navigation 3. No Page Types

slide-28
SLIDE 28

HTML Content Webviews

  • utlined

in red

slide-29
SLIDE 29

HTML Content

No native code involved at all!

HTML + CSS + JS

slide-30
SLIDE 30

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
slide-31
SLIDE 31

Design Decisions

1. HTML Content 2. Native Navigation 3. No Page Types

slide-32
SLIDE 32

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

slide-33
SLIDE 33

Native Navigation

slide-34
SLIDE 34

Native Navigation

slide-35
SLIDE 35

Native Navigation

slide-36
SLIDE 36

Design Decisions

1. HTML Content 2. Native Navigation 3. No Page Types

slide-37
SLIDE 37

Native UI Examples: How do we implement this?

slide-38
SLIDE 38

Solution 1: Page Types

  • "This is the notifications page"

○ Native code knows it should have certain buttons and styling

slide-39
SLIDE 39

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
slide-40
SLIDE 40

Avoid Message Thrash

  • Backwards compatibility is painful
  • Easier to do without page types, but still a concern
  • Avoid UI thrash!
slide-41
SLIDE 41

Design Decisions

1. HTML Content 2. Native Navigation 3. No Page Types

slide-42
SLIDE 42

Learnings

slide-43
SLIDE 43

1. Be prepared to deal with webview quirks 2. Demystify loading slowness 3. Code sharing goes deeper than views 4. JavaScript lets everyone contribute

Learnings

slide-44
SLIDE 44
  • 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

slide-45
SLIDE 45

Webview Issues

Our webviews have an animated loading screen (the 3 dots in the middle are animated)

slide-46
SLIDE 46
  • 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

Webview Issues

slide-47
SLIDE 47

1. Be prepared to deal with webview quirks 2. Demystify loading slowness 3. Code sharing goes deeper than views 4. JavaScript lets everyone contribute

Learnings

slide-48
SLIDE 48
  • Bandwidth

○ HTML is bigger than JSON

  • Multiple roundtrips

○ Blocking on CSS/JS ○ Web performance could be the subject of a whole separate talk

Real issues caused by webviews

slide-49
SLIDE 49
  • 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

Issues unrelated to webviews

slide-50
SLIDE 50

Find the real root causes of your performance problems

Be scientific and rigorous

slide-51
SLIDE 51
  • 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

At least there's only one thing to optimize

slide-52
SLIDE 52

1. Be prepared to deal with webview quirks 2. Demystify loading slowness 3. Code sharing goes deeper than views 4. JavaScript lets everyone contribute

Learnings

slide-53
SLIDE 53
  • At Quora, the same boxes handle all platforms

○ No API tier

Shared infrastructure

slide-54
SLIDE 54

Shared deployment tools

We share the same continuous deployment system we use on web

slide-55
SLIDE 55
  • If there are 100 buttons and 3 platforms, do you need 300 tests?
  • Or just 102

Shared UI integration tests

slide-56
SLIDE 56

1. Be prepared to deal with webview quirks 2. Demystify loading slowness 3. Code sharing goes deeper than views 4. JavaScript lets everyone contribute

Learnings

slide-57
SLIDE 57

Javascript lets everyone contribute

slide-58
SLIDE 58
  • Easy ramp-up
  • Designers code
  • Few projects get blocked on native development

Javascript lets everyone contribute

slide-59
SLIDE 59

1. Be prepared to deal with webview quirks 2. Demystify loading slowness 3. Code sharing goes deeper than views 4. JavaScript lets everyone contribute

Learnings

slide-60
SLIDE 60

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

slide-61
SLIDE 61

Questions?