Hi, we're VaffelNinja

Espen Hovlandsdal
@rexxars

Kristoffer Brabrand
@kbrabrand

  • Mainly "full-stack" web developers
     
  • Some experience with Android apps
     
  • Big React fans

Our background

Agenda

  • The festival 🍺
  • The app 📱
  • The tech 🤓
  • The development process
    • getting started 🚀
    • initial reactions 😱 ✨
    • awesomeness 🙌 🥓
    • big problems 🔥
  • Things we wish we knew 🤔
  • Conclusion 🏁

Mikkeller

Beer

Celebration

Copenhagen

98 breweries

715 brews

4 sessions

2 days

The
app

  • Unofficial app
  • Android only
  • Native
  • Fully offline

Previous
years

This year

  • Official app
  • Mikkeller-branded
  • More functionality
  • Cross-platform
  • Fully offline
  • Beer list
    • Rating, comment, favorites
    • Search
    • Updates over-the-air
  • News w/ push notifications
  • Map of locations (bars etc)
  • Mikkeller Beer Week schedule
  • General festival information

Functionality

Tech

Let's talk about React Native.

  • You'll still need a mac for iOS
  • Android is still a pain to setup
    (unless you've done it before)
    • Studio, SDKs, emulator
    • Env vars, udev rules (Linux) 
  • Apart from that? Breeze.

Getting started

Initial thoughts?

HERREGUD REACT NATIVE;
To timer arbeid...                9:34 PM

Wat? Du har kommet dit på to timer? I alle dager. Jeg spilte fotball i to timer og du lagde en app.                                 10:33 PM

🥓 ✨ 🏅

The [many] awesome bits

It really feels native

Async JS is awesome

Styling with flexbox is great

Cross-platform

  • Status bar hidden on iOS
  • Map marker bug on iOS
  • Rippling touchables on Android
  • Back-button handling on Android

Cross-platform

Platform switches/differences

😨 😓

The less
awesome bits

Lets talk about lists.

Core component
(only one when we started)

 

  • iOS: Pretty smooth, high memory usage
     
  • Android: Lazy rendering rows too slow, reached end of list before new render

ListView: performance

  • Kind of clunky to use
    • DataSource
    • rowHasChanged
    • cloneWithRows
    • initialListSize / pageSize/ onEndReachedThreshold 

ListView

  • We built a wrapper, SimpleListView
    • willReceiveProps: build new DataSource if needed
    • Assume immutable data
  • Does not solve the main pain point:
    • Performance

ListView

Lists: view complexity

Brewery - Beer name

Brewery - Beer name

Brewery - Beer name

  • Full width
  • One view

Lists: view complexity

Brewery - Beer name

Brewery - Beer name

Brewery - Beer name

  • Full width
  • One view
  • Session indicator
  • Row touchable
  • 2x text views
  • Fav. touchable
  • Favorite image
  • Checkmark image
  • ~10 views

Brewery - Beer name

Beer description

Lists: view complexity

Brewery - Beer name

Brewery - Beer name

Brewery - Beer name

  • Full width
  • One view
  • with rating view:
  • 6 more views
  • Total ~16 views

Brewery - Beer name

Beer description

4.5

...user comment...

  • Reduce view complexity
    • Single, static view for session indicator
    • Try to minimize containers
    • Set static height on rows if possible
  • Be sure to test it on release build
    • Really does matter. A lot.

ListView: speeding up

  • Keeps limited number of rows
  • Fixes data passing (no more DataSource)
  • Few caveats:
    • State not maintained, pass to parents
    • Replaces "end-of-list"-problem with "blank screen"-problem if rendering is  slow

FlatList to the rescue?

  • Yay, less memory usage!
  • Ouch, rendering still slow
  • Blank screen less sexy than end-of-list
  • So... we stuck with ListView
  • Possible fixes?
    • Hunt down "worst offenders" in views - style props that are slow to render
    • Go full native. But...

FlatList: our experience

Apple certificates.. 😔

Certificates in the apple developer world is there for a reason, obviously, but it's not one bit intuitive..

  • No namespace prompt - "MyProject" becomes "com.myproject". Not great when publishing
  • Default Android permissions a bit greedy, documentation on what permissions are used for and how to remove them not documented

A few snags

  • Documentation quality varies greatly. Android docs usually lacking in depth
  • Feels kinda beta. Minor release upgraded to React Fiber, introduced a range of bugs
    • Clicking on a text view that contained a number crashed the app

More snags

  • Building release build; PITA (Android).
  • No concept of unsigned release.
  • No automatic setup of keystore/credentials
  • Documentation:

Release build

react-native run-android --variant=release
  • Result:
Task 'installRelease' not found in root project
  • Output destination:
$APP_DIR/android/app/build/outputs/apk/app-release.apk

The things we wish someone told us

  • certificate management
  • application screenshoting and uploading
  • building and submission
  • +++

 

fastlane.tools

Really awesome open-source suite of tooling for app development workflows.

"Knowing what performance bottlenecks you encounter is hard. Test early"

- VaffelNinja employee of the year 2017

The good

  • Super fast iteration
  • Cross-platform, for real
  • Good iOS dev experience
  • App does feel native
  • Reuse your JS-fu
  • NPM modules
  • JS parts are pretty fast
  • Rock-solid in production (our experience)

The bad

  • Certain parts still slow (view complexity)
  • Tooling could be better
  • Documentation is lacking
  • A little unstable in development

So... building our next app with RN?

Thanks 🎩

Real-World React Native

By Espen Hovlandsdal

Real-World React Native

  • 1,055