Introduction to Evolving Android Project Architecture

Last week, at the droidcon Italy conference, my colleague, Wolfram Rittmeyer, and I had the pleasure of co-presenting a talk titled “Beyond Layer – Exploring Different Approaches to Android Project Architecture. Our discussion explained the evolution of Android project architecture over the years, with a focus on the challenges and transformations we encountered during our journey.

A Glimpse Into the Past

I vividly recall my first encounter with the legacy code of the “Polovni Automobili” app, which boasted a staggering 24-thousand lines of code in a single Activity class. The app, dating back to 2011, stood as a testament to an era when Android project architecture was still in its infancy, and widespread understanding was limited. Surprisingly, even Google’s official documentation reflected this early ambiguity, with certain codes remaining architecture-agnostic, notably observed in the YouTube SDK and Google Pay SDK.

The Influence of Community and Google’s Recommendations

Our discussion delved into the role of the community, where attempts to implement the MVC architecture proved unsuccessful, eventually leading to the adoption of the MVP pattern, which served as a successful approach until 2017. It was in that year when Google introduced their recommended architecture, incorporating LiveData, the Repository pattern, and ViewModel. While this was undoubtedly a significant stride forward, it seemingly disregarded the existing community solutions and implementations, leaving many developers to navigate a complex landscape of varying methodologies.

An Ongoing Evolution

Fast forward to 2021, and the Android architecture continued to evolve, as Google introduced the concept of a 3-layer architecture, emphasizing the importance of distinct UI, data, and domain layers. This adaptation signified a critical acknowledgment of the community’s contributions and the need to streamline development processes for future Android projects.

In our presentation, we delved into the intricacies of these transformations, highlighting the challenges and opportunities that defined our journey towards crafting a robust and sustainable Android project architecture.

Diverging Perspectives on Google’s Guidelines

During our exploration of Google’s recommended architecture, Wolfram and I found ourselves contemplating differing interpretations. From my standpoint, a feature within an Android project signifies an entity that directly translates into user value. Consequently, I advocate for isolating the UI layer, as it represents the aspect most directly visible to the user. Meanwhile, the data and domain layers are shared components accessible to multiple features originating from the UI layer.

Contrastingly, Wolfram views a feature as an independent unit within the project, encapsulating all the essential components: UI, data, and domain layers. His perspective suggests that each feature should encapsulate all layers necessary for its functionality. In scenarios where sharing between features is necessary, Wolfram proposes the utilization of Feature APIs, a mechanism designed to facilitate seamless communication and data exchange between different feature units.

Our divergent perspectives led us to delve deeper into the nuanced implications of these interpretations. We pondered the impact on project scalability, the potential for code reusability, and the overall maintainability of Android applications developed under these contrasting paradigms.

In the subsequent sections, we will delve into the specific use cases and scenarios that highlight the strengths and limitations of both approaches. Our aim is to provide a comprehensive analysis that enables developers to make informed decisions when designing and implementing Android project architectures.

The Varied Truth of Proper Architecture

In the dynamic realm of Android project architecture, it becomes evident that there is no one-size-fits-all solution. The optimal approach often hinges on a multitude of contextual factors, each exerting its influence on the development process. One such crucial factor revolves around the size and dynamics of the development team.

Consider the scenario where multiple developers are concurrently engaged in various feature implementations within a project. In this context, the risk of redundant code arises, where different team members may inadvertently tackle similar problems without awareness of existing solutions within the project. Such redundancy not only impedes progress but also hinders the efficiency and maintainability of the codebase.

Consequently, in environments characterized by smaller teams, we advocate for the adoption of my perspective on architecture. By segregating the UI layer and centralizing the data and domain layers, the likelihood of overlooking preexisting solutions diminishes. This streamlined approach allows for a more focused and efficient workflow, thereby minimizing the chances of code duplication and enhancing the overall productivity of the team.

Conversely, in projects boasting a larger team with diverse responsibilities, the comprehensive encapsulation of features within Wolfram’s approach can foster better collaboration and facilitate more autonomous feature development. Through the use of Feature APIs, team members can seamlessly integrate their functionalities without encroaching on each other’s domains, promoting a more cohesive and systematic development process.

Navigating Contract Durations and Architectural Choices

In the realm of Android project development, the duration of contracts exerts a profound influence on the selection of an appropriate architectural framework. Shorter contract durations pose a unique challenge, primarily stemming from the limited timeframe available for onboarding and knowledge sharing among team members.

Consider the scenario where project contracts extend for a mere six months. In such instances, the expedited assimilation of project intricacies becomes paramount, as there is minimal leeway for extended learning curves. It is here that my advocated approach to architecture emerges as a favorable choice. Its streamlined structure and focused layering necessitate less time for knowledge dissemination, thereby allowing teams to swiftly acclimate to project requirements and accelerate the development process.

Conversely, in projects characterized by longer contract durations, typically exceeding the six-month threshold, the comprehensive encapsulation of features within Wolfram’s proposed approach can prove to be more advantageous. With a more extensive timeframe at their disposal, development teams can delve deeper into the intricacies of the project architecture, allowing for a more comprehensive understanding and seamless integration of diverse feature components.

Unraveling Role Dynamics and Architectural Considerations

The diverse roles within an application ecosystem introduce another layer of complexity that significantly impacts the choice of an appropriate architectural paradigm. Consider an application housing a multitude of roles, including administrators, maintainers, editors, regular users, and premium subscribers. In such a multifaceted environment, the functionalities attributed to each role are often distinct and segregated, leading to a natural affinity towards Wolfram’s proposed approach. By encapsulating features within independent units aligned with specific roles, the architectural framework accommodates the unique requirements and access privileges associated with each user category, promoting a more secure and efficient application ecosystem.

Conversely, in applications characterized by a singular user role, the choice between architectural strategies becomes more flexible. Both my advocated approach and Wolfram’s encapsulation methodology offer viable options, enabling developers to tailor the architecture based on other contextual factors, such as project scope and development team dynamics.

Documenting for Success: The Role of Communication and Knowledge Sharings

Effective communication and comprehensive documentation represent the bedrock of successful Android project development. In instances where communication channels falter and knowledge transfer becomes uncertain, the risk of inefficiencies and code redundancies amplifies significantly. Here, my advocated approach to architecture shines as it offers a streamlined structure that minimizes the reliance on extensive knowledge sharing. By compartmentalizing functionalities and centralizing critical components, the architectural framework mitigates the challenges associated with incomplete knowledge dissemination, fostering a more independent and efficient development process.

Conversely, in environments characterized by robust communication channels, comprehensive documentation, and robust knowledge sharing mechanisms such as UML diagrams, version control through Git, and other collaborative tools, the adoption of Wolfram’s approach emerges as a more favorable choice. With a well-documented and transparent development process, the comprehensive encapsulation of features within individual units fosters better collaboration and facilitates a more cohesive and synchronized development process.

Adapting Architecture to Project Dynamics: The Crucial Role of Stability and Flexibility

The adaptability of Android project architecture hinges upon the fundamental characteristics and dynamics of the project itself. A critical factor that demands careful consideration is the stability and predictability of the project trajectory. In scenarios where the project is conceived within an agile framework, characterized by frequent iterations and the potential for dynamic changes in requirements, my advocated approach emerges as the preferred choice. By fostering a modular and flexible architectural framework, developers can swiftly adapt to evolving project dynamics, ensuring seamless integration of new functionalities and features without compromising the overall stability of the application.

Conversely, in projects characterized by a fixed and well-defined scope, with minimal anticipated changes or iterations in the foreseeable future, the comprehensive encapsulation of features within Wolfram’s approach can serve as an effective architectural foundation. By consolidating the diverse layers within each feature unit, developers can streamline the development process and ensure the seamless integration of predetermined functionalities, fostering a stable and robust application framework.

In the subsequent segments, we will delve deeper into the significance of project stability and flexibility in shaping the architectural fabric of Android applications. By examining real-world case studies and practical insights, we aim to equip developers with a comprehensive understanding of how project dynamics influence the architectural decision-making process in Android application development.

Conclusion

As we draw the curtains on our exploration of Android project architecture, we arrive at a crucial juncture where the interplay of numerous contextual factors underscores the nuanced and multifaceted nature of architectural decision-making. Our journey has led us through a comprehensive examination of diverse perspectives, encompassing team dynamics, contract durations, screen counts, role-based functionalities, communication dynamics, and project stability.

In this intricate tapestry of considerations, we have emphasized the absence of a one-size-fits-all solution, advocating instead for a holistic approach that takes into account the specificities of each project’s context and requirements. The dynamic nature of the Android development landscape demands a nuanced understanding of the diverse factors that influence the architectural fabric of contemporary applications.

Moving forward, we encourage developers to embrace an adaptive mindset, one that remains receptive to the evolving needs and dynamics of the project environment. By fostering a culture of continuous learning and exploration, developers can navigate the complexities of Android project architecture with confidence and insight, ensuring the development of robust, scalable, and user-centric applications that resonate with the ever-changing demands of the digital realm.

Join us as we continue to explore the evolving trends and best practices in the Android development landscape, aiming to equip developers with the necessary insights and tools to craft innovative, future-ready applications that redefine the digital experience.

Are you looking for mobile application services? Have a look at Services.