Level 1: Meme app with big dreams
Back in March 2017, PogDroid was maintained by a very small team of engineers, and covered the most basic functionality of Twitch: browse and watch a stream with Chat.
Mobile, and Android in particular, was getting more and more users, and the company decided it was time for a serious investment in PogDroid. The plan was to give the app a fresh new look, and build up some important features that were missing. The team grew only a little bit, but were tasked to take on this big project.
As with most apps maintained by a very small team, the code structure was a mess. It became clear that such a big redesign compounded with adding new features could not be built cleanly on top of the current foundation. There was no common pattern to build screens, not a single unit test, and a lot of core classes were more than 3,000 lines of code long, with very complex state management, handling everything from network requests to UI rendering.
We all agreed that in order to make PogDroid what we were dreaming of, we first needed to rethink its foundations.
Step 1: Agree on a common architecture pattern
The first thing we did is come up with a common design pattern to build features and screens. We wanted this design pattern to be:
- easy to understand
- hard to get wrong
- flexible enough to be applied to any feature or screen
- easy to unit test
We quickly settled on a straightforward MVP pattern that looks like this:
With these layers in mind, it became easy to categorize the type of classes we needed for every feature:
Typical classes living in the Data Layer:
- API
- Repository
- Models
Typical classes living in the Presentation Layer:
- Presenter
- Tracker
Typical classes living in the View layer:
- AdapterBinder (wrapper that manages our RecyclerView adapter)
- ViewDelegate (wrapper that inflates and holds our actual Android views)
With this design pattern and injected dependencies (manually, with static create methods for now), writing unit tests for the data and presentation layer became extremely easy, removing any excuse for not testing your code.
The team quickly adopted the pattern and started rewriting all our main screens in this fashion, adding unit tests in the process! It was also easy to onboard new team members to write consistent code with the rest of codebase.
Having a common pattern that everybody agreed on really accelerated the pace of development of new features and screens, and the team got really good at it. In only three months, we had completed the redesign of the app along with big new features, with around 70 percent of our main screens rewritten from scratch, and about 15 percent unit test code coverage. By this point, the team had tripled, but was still quite small.
Website: LINK
