[EN] High-Performance Android: Rebirth of our US App

Transcript

1. Mercari Tech Conf 2017 Mercari Android Engineer Tsuyoshi Yoshioka (@tsuyogoro) High-Performance Android: Rebirth of our US App
2. About me Tsuyoshi Yoshioka (@tsuyogoro) Android Engineer Mercari, Inc (since Mar, 2016)
3. Summary • Redesigned the US Mercari app in June of this year • Huge UI/architecture changes • All changes were made in order to improve the overall product • Mercari Android team used our trademark “high-performance” teamwork!
4. Android team history since 2016
5. Mercari Android Team in 2016 JP/US
6. You know what needs to be done. Every Section 9 member has a unique ability. And you work best on your own. But individual success is a reflection of strong teamwork. We’re just like Public Security Section 9 “ ” Daisuke Aramaki, 2002 (Ghost in the Shell: Stand Alone Complex)
7. Optimized teamwork across the Pacific • 6:30 daily sync meeting • Screen Hero
8. Mercari Android Team in 2017 US JP UK
9. US Android Team in 2017
10. US Android Team in 2017 Too difficult to list all...
11. Re:born
12. Technical view introduction
14. Working with “speed” in mind 1. Code that anyone can replicate 2. Minimize all problems to optimal size 3. Actively integrate new technologies
15. 1. Code that anyone can replicate Same blueprint Same weapons
16. • Layer that houses the data • Has an interface that does not need to worry about storage location 1. Code that anyone can replicate View View Model Service Repository • Activity/Fragment/View • Only layer that touches Context • Slave to ViewModel (no logic) • Houses logic not directly related to display • Network access, storage access, etc. • All logic is stateless, and the Service layer does not hold a state • Houses the display logic • Pure Java, is JUnit testable
17. Connect all layers via RxJava2 stream → Use RxJava2 together as a team 1. Code that anyone can replicate
18. Making our weapon (RxJava2) high-context Recalculate the shipping cost when the method, payer, or weight changes Flowable.combineLatest ( shippingClass, shippingPayer, (c, p) -> { .... } Process input as fields are filled out .filter (signal -> !itemName.get().isEmpty() && itemCategory.has() && itemCondition.has()) .flatMapMaybe(signal -> ... Preventing overuse (backpressure) RxTextView .textChangeEvents(hashTag) .throttleLast ( 100, TimeUnit.MILLISECONDS )....
19. 1. Code that anyone can replicate Same blueprint Same weapons MVVM + Flux oriented layered architecture RxJava2 ...etc
20. 2. Minimize all problems to optimal size • Trying to tackle big problems all at once is too much • We want to split big problems into small pieces • Shoving everything into Activity when creating the screen • Shoving multiple API requests and processing into one class • ...etc Break it down and make it configurable with DI !!
21. Any issues that aren’t directly related should be solved outside You know DI, right? class SellService { private SellApi sellApi; private ItemApi itemApi; private AddressApi addressApi; private SuggestApi suggestApi; SellService(ItemApi itemApi, SellApi sellApi, AddressApi addressApi, SuggestApi suggestApi) { this.sellApi = sellApi; this.itemApi = itemApi; this.addressApi = addressApi; this.suggestApi = suggestApi; }
22. You know DI, right? Instead, focus on what you should be solving yourself! /** * Get user's default deliver address. */ @CheckReturnValue Maybe<DeliverAddress> getDefaultAddress() { return addressApi.getDeliverList() .filter(resp -> !resp.addresses.isEmpty()) .map(resp -> { Optional<DeliverXX> address = Stream.of(resp.addresses) .filter(addr -> Defaults.get(addr.isDefault)) .findFirst(); if (address.isPresent()) { return address.get(); } else { // if couldn't found default, use first one return resp.addresses.get(0); } }); }
23. 2. Minimize all problems to optimal size • Smaller than View/ViewModel/Service/Repository • Try to use constructor injection when possible Wait, but Activity and Fragment don’t have constructors... Dagger 2 !!
24. Implement injection into the classes that can’t touch constructors Activity injection public class ItemDetailActivity extends BaseActivity { @Inject ItemDetailViewModel viewModel; @Inject UrlConstruct urlConstruct; @Inject MasterData masterData; ... @Override protected void onCreate(@Nullable Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_item_detail); AppComponent.Holder.get(this) .plus(new ItemDetailComponent.Module(this, itemId)) .inject(this);
25. 2. Minimize all problems to optimal size • If the problem is simple, the road to the goal is shorter • High-quality communication within the team • Unit tests become easier to write, and the fastest way to test code • (side-effect) Making use of Dagger2’s scope, 　　　　　　　　　　　　　　we were also able to deal with the Activity lifecycle 　
26. 3. Actively integrate new technologies • Protocol buffers • ReactNative • Kotlin +
27. Kotlify progress Every other week - Discuss how Kotlin is going in Tokyo and San Francisco - Share technical information - but still we’re looking for a strong reason, why Kotlin? Kotlin used for all new files since Google I/O announced support
29. Working with “speed” in mind 1. Code that anyone can replicate 2. Minimize all problems to optimal size 3. Actively integrate new technologies
30. Challenges we face with transpacific development Strategizing before writing code High-quality PRs Branchify large requirements Early mornings Screen hero (Rough) daily reports Travel Same blueprint Same weapons “To be a high-performance development team, we must…as;ldkfjasdlfkjasd” (←all talk) “High-Performance” Really high-performance “This should work, right? Let’s go for it!!” (←action!)
31. Next...
32. Highly Scalable Android Team in the near future… 100 Android Engineers More than 100 times performance
33. Refer to... https://eng.uber.com/plugins/
34. Summary
35. Summary • We redesigned the whole US Mercari app in June • We’re going to capture the US market with the new architecture focused on a high-speed, high-performance team • Then we’ll go even higher, creating a scalable team whose performance just keeps increasing with size, and taking over the “global marketplace” • We’re so high-performance, like a racecarrrrr
36. Thank You