Modularization

With modularization being all the hype, should you also modularize an SDK? Are fat aar files really needed? And how do you prevent internal APIs from being exposed on your public interface?

Wrapping up this series on modularization I’d like to share some of the things we’ve learned at Philips Hue while going through this process the past year.

Now that we have a clear idea of how a modularized app could look like how can this be applied to an existing app? Part four will dive deeper into how existing apps can be sliced and how you can gradually migrate to a fully modularized architecture.

With a clear view on how multi-module apps should be architected, let’s dive into a real-life practical example. We’ll discover how the architecture results in a clear application structure, how navigation is handled, how to use staged rollouts, how to test everything and even look at a production app that is using this architecture.

Now that we’ve established that modularization is a really good thing to strive for, how should a modularized app look like? How are the different modules connected?

Modularizing your app seems to be all the hype these days. But why should you actually care? What are the benefits for you and your team?