Android Architecture & Problems Facing in Architecture (By: Hamza Khalid) - Google I/O Extended Lahore 2023

Talk by Hamza Khalid (https://www.linkedin.com/in/the-hamzakhalid/) at Google I/O Extended Lahore 2023 by GDG Lahore.

Transcript

1. INTRODUCTION TO ANDROID CLEAN ARCHITECTURE Inspired From Robert C. Martin and Rim Gazzah
2. When developers work on a real mobile application whose nature is dynamic and will expand its features according to the user’s need, then it is not possible to write core logic in activities or fragments. To structure the project’s code and to give it a modular design(separated code parts), architecture patterns are applied to separate the concerns. The most popular android architectures used by developers are the following: • MVC (Model —View — Controller) • MVP (Model —View — Presenter) • MVVM (Model —View —ViewModel) • MVI (Model —View — Intent) The main idea of all these patterns is to organize the project in a proper way so that all the codes get covered in the Unit Testing. Moreover, it is very helpful in the maintenance of the software, to add and remove features and developers can keep a track of various crucial logic parts. Why are we using Android Architecture Patterns ?
3. MVC pattern is the oldest android app architecture which simply suggests separating the code into 3 different layers: • Model: Layer for storing data. It is responsible for handling the domain logic(real-world business rules) and communication with the database and network layers. • View:UI(User Interface) layer. It provides the visualization of the data stored in the Model. • Controller: Layer which contains core logic. It gets informed of the user’s behavior and updates the Model as per the need. The Model—View—Controller (MVC) Pattern
4. Pros: • MVC pattern increases the code testability and makes it easier to implement new features as it highly supports the separation of concerns. • Unit testing of the Model and Controller is possible as they do not extend or use any Android class. • Functionalities of the View can be checked through UI tests if the View respect the single responsibility principle (update controller and display data from the model without implementing domain logic) Cons: • Code layers depend on each other even if MVC is applied correctly. • No parameter to handle UI logic i.e., how to display the data. The Model—View—Controller (MVC) Pattern In MVC schema, View and Controller both depend upon the Model. Application data is updated by the controller and View gets the data. In this pattern, the Model could be tested independently of the UI as it is separated.
5. MVP pattern is the second iteration of Android app architecture. This pattern is widely accepted and is still recommended for upcoming developers. The purpose of each component is easy to learn: • Model: Layer for storing data. It is responsible for handling the domain logic(real-world business rules) and communication with the database and network layers.. • View: UI(User Interface) layer. It provides the visualization of the data stored in the Model. • Presenter. Fetch the data from the model and applies the UI logic to decide what to display. It manages the state of the View and takes actions according to the user’s input notification from the View The Model—View—Presenter (MVP) Pattern
6. Pros: • No conceptual relationship in android components. • Easy code maintenance and testing as the application’s model, view, and presenter layer are separated. Cons: • If the developer does not follow the single responsibility principle to break the code then the Presenter layer tends to expand to a huge all-knowing class. The Model—View—Presenter (MVP) Pattern In the MVP schema, View and Presenter are closely related and have a reference to each other. To make the code readable and easier to understand, a Contract interface class is used to define the Presenter and View relationship. The View is abstracted and has an interface in order to enable the Presenter for Unit Testing.
7. The third iteration of android architecture is the MVVV pattern. While releasing the Android Architecture Components, the Android team recommended this architecture pattern. Below are the separate code layers: • Model: This layer is responsible for the abstraction of the data sources. Model and ViewModel work together to get and save the data. • View: The purpose of this layer is to inform the ViewModel about the user’s action. • ViewModel. It exposes those data streams which are relevant to the View. The Model—View—ViewModel (MVVM) Pattern
8. Pros: • Enhance the reusability of code. • All modules are independent which improves the testability of each layer. • Makes project files maintainable and easy to make changes. Cons: • This design pattern is not ideal for small projects. • If the data binding logic is too complex, the application debug will be a little harder. The Model—View—ViewModel (MVVM) Pattern In MVVM schema the View informs the ViewModel about various actions. The View has a reference to the ViewModel while ViewModel has no information about the View. The many-to-one relationship that exists between View and ViewModel and MVVM supports two-way data binding between both.
9. The fourth iteration of android architecture is the MVI pattern. It is basically your favorite architecture (MVVM or MVP) with state management where there is only one state for all the app layers, a single-source of truth and focuses on unidirectional data flow and immutability: • Model: Instead of having a separate state for the View, ViewModel, and the Data layer, the Model will be the single source of truth of the overall state, and it’s immutable to ensure that it will be updated from only one place. • View: It represent the UI layer, the activity, or the fragment, it defines the user actions and renders the state emitted by the model. • Intent. Do not confuse it with the Android Intent, it’s the intention to perform an action either by the user or the app itself. The Model—View—Intent (MVI) Pattern
10. Pros: • State management using immutability to have a single source of truth. • Unidirectional data flow • Better separation of concern -> maintainability Cons: • It leads to lots of boilerplate code, as we have to maintain a state for each user action. This can make it too costly for app memory management, as we have to create lots of objects for all the states. • It is also very complex and can be difficult to learn and implement The Model—View—Intent (MVI) Pattern MVI is a very powerful architecture that allows for a great deal of flexibility and customizability. Overall, MVI is a great choice for those looking for a high-powered architecture that can be customized to fit their needs.
11. LET’S EXTEND ANDROID ARCHITECTURE WITH CLEAN CODE
12. Hexagonal Architecture (a.k.a. Ports and Adapters) by Alistair Cockburn • Create your application to work without either a UI or a database so you can run automated regression-tests against the application, work when the database becomes unavailable, and link applications together without any user involvement. • This application having two active ports and several adapters for each port. The two ports are the application-controlling side and the data-retrieval side. Architecture of Systems
13. Onion Architecture by Jeffrey Palermo • This architecture is not appropriate for small application. It is appropriate for long-lived business applications as well as applications with complex behavior. Each subsequent layer depends on the layers beneath it, and then every layer normally will depend on some common infrastructure and utility services. Architecture of Systems Screaming Architecture from a blog of mine last year Lean Architecturefrom James Coplien, and Trygve Reenskaug from his book . Object Oriented Software Engineering:A Use-Case Driven Approach by Ivar Jacobson
14. The Clean Architecture by Robert C. Martin (Uncle Bob) This is an attempt at integrating all these architectures into a single actionable idea.
15. The Dependency Rule • The concentric circles represent different areas of software. In general, the further in you go, the higher level the software becomes. The outer circles are mechanisms. The inner circles are policies. • The overriding rule that makes this architecture work is The Dependency Rule. This rule says that source code dependencies can only point inwards. Nothing in an inner circle can know anything at all about something in an outer circle. Entities – Enterprise Business Rule • Entities encapsulate Enterprise wide business rules. An entity can be an object with methods, or it can be a set of data structures and functions. It doesn’t matter so long as the entities could be used by many different applications in the enterprise. The Clean Architecture by Robert C. Martin (Uncle Bob)
16. Pros • Separation of Concerns: Separation of code in different modules or sections with specific responsibilities making it easier for maintenance and further modification. • Loose coupling: Flexible code anything can be easily be changed without changing the system so the developers can design applications that can accept changes in the future. • Easily Testable: You will create a system that is intrinsically testable, and it gives a modular design to the application which assures good quality testing and maintenance of code. Cons • Time Taking: Writing the whole project code in an architecture pattern is a time taking process. • Strict Discipline: Strict discipline is required from the developer team side as one misplaced change can ruin the integrity of the architecture. The Clean Architecture by Robert C. Martin (Uncle Bob)
17. Demo – Multi Layers Architecture By Hamza Khalid • App Layer : It is main module of the app and contains UI related info w.r.t. to use cases and this module includes all other module. • BuildSrc : It contain build info. It enable kotlin-dsl and write logic related to custom configuration and share them across the project. • Core Layer: It contains further three sub module. • Common Layer : All common code which is include by all other module of the app i.e. Utils, extensions and custom classes etc. • Db Layer : It contains all info of database i.e. Datastore ,Room ,Firebase and Newtork API e.t.c. • GMS Layer : It contains all info relating ads and payment gateway i.e. Google Admob and Billing and Paypal, Stripe etc.
18. WELCOME TO THE ANDROID 14 PREVIEW • This program includes everything you need to test your existing apps on a variety of screen sizes, network technologies, CPU/GPU chipsets, and hardware architectures • It gives you everything you need to make your apps compatible with and build for the next version of Android
19. Core Functionality • Foreground service types are required • Enforcement of BLUETOOTH_CONNECT permission in BluetoothAdapter • OpenJDK 17 updates • JobScheduler reinforces callback and network behavior Security • Restrictions to implicit and pending intents • Runtime-registered broadcasts receivers must specify export behavior • Additional restrictions on starting activities from the background Updated non-SDK restrictions What are the Behaviour changes in Android 14 ?
20. “LEARNING IS AN INTEGRAL PART OF GROWING, ONCE YOU STOP LEARNING YOU STOP THINKING” Thank You Everyone