Architecture

Tired of building un-versionable, lifeless architecture diagrams? Wouldn’t it be great if you could add your diagram to Git, embed it in your documentation, and have clickable elements?

Now that we know how feature flags can help us release faster, it’s time to dive into the actual implementation details. How can we easily define feature flags?

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?

Are you living the dream? Is your code so clean it makes your eyes just tear a little? Can’t think of anything you would still like to refactor?

Architecture components are one of the most exciting things that happened to Android in the past years. But how do you effectively go about and testing this?

Too many times I’ve seen developers trying to avoid crashes at all cost. But are unhandled exceptions really that bad? And are null checks really the answer?