400 Fragments in 40 Days

My presentation will focus on one of my most recent Android projects for Pinterest, which was finished in 40 days after being planned for a four-month delivery time.

We were tasked with redesigning our Fragments to reduce risk and enable common Jetpack design components. Unfortunately, the task was not scriptable or mechanized. The tl;dr is that they had to migrate 400 fragments from a bespoke lifespan to a new pattern. This was expected to take four months, but it was completed in forty days.

The talk will go over how we sequenced it, how we put it together, how we set up support from it, how to turn it into code changes (diffs), pre-work done, what we did to get this project that had been planned for four months to be completed in 40 days, lessons learned, if we wanted to replicate it, and our three biggest takeaways.

Transcript

1. Adam Greenberg & Kurt Nelson 400 Fragments in 40 Days
2. Hello, Thank you for coming to our talk 2 Kurt Nelson Android Engineer Kurt Nelson Android Engineer Kurt Nelson Android Engineer Adam Greenberg Android Engineer Adam Greenberg Android Engineer Adam Greenberg Android Engineer
3. 3 3 We are here to discuss the project we both spent a few months on And what we did to get this project that was scoped out for 4 months to be delivered in 40 days. Why we’re here
4. Agenda 4 2 3 4 5 1 Teams & tooling Stats, metrics, & objectives 400 Fragments In 40 days Wrap up
5. A 10x engineer doesn’t believe in computers, only software. They only eat freshly printed pages of source code from the latest version of the Linux kernel. 5
6. 6 Team
7. The Pinterest App is old enough to go to high school. 7 As such, the Android app is built and maintained by a number of teams: • Our team’s job is to build the logic between the features and the system. • This leaves us with a lot of functional systems that are no longer excellent. • Eg: EventBus, RxJava, Volley, Java, Realm, React Native, RenderScript, etc.
8. 8 What makes a 14 year-old application work to serve half a billion people? • IDE: Android Studio • Build: Gradle Enterprise, groovy & python scripts, and Buildkite • Architecture: Multi-module, monolithic, (mostly) single-Activity application Tooling
9. 9 The numbers that reflect what we do. Stats, Metrics, & Objectives
10. Confidential | © Pinterest 12,819 commits 10 Last year our codebase had over
11. Confidential | © Pinterest ~90 FTE 11 The Android team is made up of
12. Confidential | © Pinterest 43 releases 12 The Android app had
13. Our team name is “androidx” (we had it first) 13 a bit of historical context.
14. 14 Seven years ago, before a Google IO keynote introduced Jetpack navigation, we had our own complicated mechanism that determined how the application lived and was traversed. Something done right that is now wrong is worth redoing.
15. 15 ScreenManager's role is to construct Controllers and their Views from a Screen definition. ScreenManager
16. 16 The NavigationManager is responsible for handling the application navigation. NavigationManager
17. 17 The NavigationManager is responsible for handling the application navigation. NavigationManager
18. 18 Bottom on-screen navigation and Floating Action Buttons. Or how did we get here on purpose? How did we get here?
19. 19 Or what enabled us to get the green light to finally burn this pattern to the ground? Forcing functions
20. 20 Goal: provide a solution capable of migrating the bespoke navigation system entirely to the Jetpack Navigation framework. Objectives
21. 21 400 Fragments
22. MVP we wanted 22
23. 23 Problem: Navigation, like FragmentManager transactions, necessitates zero argument fragment constructors. Result: Failure as a result of attempting to make too many adjustments at once. Learning was that we must first disassemble our custom architecture. Attempted Task 1: Launch a fragment via Jetpack Nav
24. 24 Problem: Our base fragment that everyone inherits from has constructor parameters. Attempted: Switch to field injection Result: With the way we built on top, as soon as any field was injected, we couldn’t guarantee the order of injection versus access. Tedious. Attempted Task 2: Move to field injection in base fragment
25. 25 Problem: All of our fragments extend from a root fragment. Can we change it so that when using field injection, it won’t break the entire application. Result: Ability to launch the a demo fragment via Jetpack navigation! Attempted Task 3: Fork the base fragment
26. Simplify things to make it easy 26 Our app has a fun little developer playground that allows you to have an sandbox in the app. Build a playground
27. 27 Problem: As a result of inheritance as a design pattern we were left with root-ish fragments still in java. Result: Successfully integrated in app and in developer menu playground. Attempted Task 4: Kotlin convert a root fragment
28. Problem: We needed some way to get the system to use the Jetpack navigation standards Result: The forked fragment can be compiled, but there is no good way to launch the fragment from our current custom architecture. We will need to build out the XML graph and the relevant pieces to support navigation onto and off of the surfaces. 28 Attempted Task 5: Fork a fragment to Jetpack’s NavHostFragment.
29. Problem: We give up. We just want to make sure we can launch fragments via FragmentManager transactions if we need to. Attempt: Manually scrub constructor parameters from fragments and ensure they can be launched traditionally with just args + field injection Result: Prototype success! 29 Attempted Task 6: Remove the need for fragment dependencies.
30. “Success is most often achieved by those who don't know that failure is inevitable.” 30
31. 31 40 Days
32. Problem: We arrived at a great solution to get our application to Jetpack navigation and off of the bespoke architecture. The dilemma was now that it would require MASSIVE changes to the system. Result: Break down the project. 32 What did we do to make the project a success
33. 33 We all know that projects evolve very quickly. In a well defined role, it’s on you as engineer to dictate what these become when they change. The new project became: • Modern Lifecycle Readiness • Lifecycle Implementation • Navigation Implementation What the success metric became
34. 34 02 03 04 05 01 06 Step one Identify the impact Step two Ensure backward compatibility. Step three Define; current, migrating and end-state Step four Mapping of legacy code to new code. Step five Set up tools to monitor progress Step six Shouldn’t take more than two lines Helpful steps controlling redefinition
35. Mythical man math sometimes works? 35
36. 100% 0% 36 2023 2024 Getting unblocked.
37. Thank you 37