Innovation Generation - The Mobile Meetup: Android Best Practices
1 like639 views
The document outlines best practices for Android development, focusing on clean architecture principles, which emphasize the separation of concerns through distinct layers: presentation, domain, and data. It discusses the roles of each layer, testing methodologies, and relevant support libraries such as Retrofit for networking and Espresso for UI testing. Additionally, it highlights communication strategies between layers and suggests various libraries and tools to enhance development efficiency.
More Related Content
![[Android] DI in multimodule application](https://cdn.slidesharecdn.com/ss_thumbnails/androiddiinmultimoduleapplication-201008125609-thumbnail.jpg?width=560&fit=bounds)
Similar to Innovation Generation - The Mobile Meetup: Android Best Practices (20)
![[PBO] Pertemuan 12 - Pemrograman Android](https://cdn.slidesharecdn.com/ss_thumbnails/pbopertemuan12-pemrogramanandroid-181217234438-thumbnail.jpg?width=560&fit=bounds)
Innovation Generation - The Mobile Meetup: Android Best Practices
- 3. Agenda ● Introduction ● The clean architecture ● Testing ● Support library ● Libraries we can depend on ● What's next
- 4. Introduction
- 5. Android Studio Gradle Material Design Lollipop Android Wear / Auto / TV Introduction
- 7. The clean architecture The key concept is based on: ● Independence of frameworks ● Testeable ● Independent of UI ● Independent of DB ● Independent of any external agency
- 8. The clean architecture Definitions ● Entities: These are the business objects of the application ● Use Cases: These use cases orchestrate the flow of data to and from the entities. ● Interface Adapters: This set of adapters convert data from the format most convenient for the use cases and entities. ● Frameworks and Drivers: This is where all the details go: UI, tools, frameworks, etc.
- 9. Android architecture The objective is the separation of concerns by keeping the business rules not knowing anything at all about the outside world, thus, they can can be tested without any dependency to any external element. To achieve this, the proposal is about breaking up the project into 3 different layers, in which each one has its own purpose and works separately from the others.
- 10. Presentation layer Is here, where the logic related with views and animations happens. It uses no more than a Model View Presenter (MVP), but you can use any other pattern like MVC or MVVM. For example, fragments and activities are only views, there is no logic inside them other than UI logic, and this is where all the rendering stuff takes place. Presenters in this layer are composed with interactors (use cases) that perform the job in a new thread outside the android UI thread, and come back using a callback with the data that will be rendered in the view.
- 11. Domain layer Business rules here: all the logic happens in this layer. Regarding the android project, you will see all the interactors (use cases) implementations here as well. This layer is a pure java module without any android dependencies. All the external components use interfaces when connecting to the business objects.
- 12. Data layer All data needed for the application comes from this layer through a Repository implementation (the interface is in the domain layer) that uses a Repository Pattern with a strategy that, through a factory, picks different data sources depending on certain conditions. The idea behind all this is that the data origin is transparent for the client, which does not care if the data is coming from memory, disk or the cloud, the only truth is that the data will arrive and will be got.
- 13. Project structure Presentation module Is the Android application itself, with its resources, assets, logic, etc.
- 14. Project structure Domain module This module hosts use-cases and their implementations, it is the business logic of the application.
- 15. Project structure Model module This module is responsible for managing the information, select, save, delete, etc.
- 16. Communication Now, how we communicate these layers? One approach is communication over an Message Bus system. This system is very useful for Broadcast events, or to establish a communication between components. Basically, events are sent through a Bus and the classes interested to consume that event have to subscribe to that Bus. To implement the system bus, we used the library Otto by Square, but we can use EventBus by GreenRobot too. Both libraries implements the publish/subscribe pattern.
- 17. Communication
- 18. Testing
- 19. Testing We have different solutions for each layer: ● Presentation Layer: Android instrumentation and Espresso for integration and functional testing ● Domain Layer: JUnit plus Mockito for unit tests ● Data Layer: Robolectric (since this layer has android dependencies) plus JUnit plus Mockito for integration and unit tests.
- 20. Espresso Espresso is a testing framework that exposes a simple API to perform UI testing of Android apps. With the latest 2.0 release, Espresso is now part of the Android Support Repository which makes it more easier to add automated testing support for your project. Key features: ● Its code looks a lot like English, which makes it predictable and easy to learn. ● The API is relatively small, and yet open for customization. ● Espresso tests run optimally fast (no waits, sleeps) ● Gradle + Android Studio support
- 21. Espresso Is built up from 3 major components: These components are: ● ViewMatchers – allows you to locate a view in the current view hierarchy ● ViewActions – allows you to interact with views ● ViewAssertions – allows you to assert the state of a view. For simplicity, you may use these shortcuts to refer to them: ● ViewMatchers – “find something“ ● ViewActions – “do something“ ● ViewAssertions – “check something“
- 22. Espresso Here is an example for this:
- 23. Espresso Here is an example for this:
- 24. JUnit JUnit in version 4.x is a test framework which uses annotations to identify methods that specify a test.
- 25. JUnit From Android Studio 1.1, we have fully integration with JUnit.
- 26. Support Library
- 27. Support Library Design Support Library This library implements some custom views from Material Design such as: NEW
- 28. Support Library Design Support Library
- 29. Support Library V7 Appcompat Library - IMPORTANT!!! This library adds support from API V7 (Android 2.1) for basic elements: ● Toolbar ● CardView ● GridLayout ● PaletteLibrary ● RecyclerView ● … and more
- 30. Support Library V4 Support Library This library adds support from API V4 (Android 1.6) for basic elements: ● Fragment ● NotificationCompat ● ViewPager ● PagerTitle ● DrawerLayout ● ... and a lot more
- 31. Support Library Testing Support Library This library provides an extensive framework for testing Android apps. You can run tests created using these APIs from the Android Studio IDE or from the command line. Includes the following test automation tools: ● AndroidJUnitRunner: JUnit 4-compatible test runner for Android ● Espresso: UI testing framework; suitable for functional UI testing within an app ● UI Automator: UI testing framework; suitable for cross-app functional UI testing across system and installed apps
- 32. Libraries we can depend on
- 33. Why libraries? ● Maintained by the community ● Easy to use ● Well documented ● It just works!!! ● Don't reinvent the wheel!!!
- 34. Retrofit Type-safe REST client for Android and Java by Square, Inc. Retrofit turns your REST API into a Java interface. The RestAdapter class generates an implementation of the GitHubService interface.
- 35. Retrofit Each call on the generated GitHubService makes an HTTP request to the remote webserver. More examples:
- 36. Picasso Image transformation Picasso allows for hassle-free image loading in your application — often in one line of code!
- 37. ButterKnife View injection library Annotate fields with @InjectView and a view ID for Butter Knife to find and automatically cast the corresponding view in your layout.
- 38. Gson Gson is a Java library that can be used to convert Java Objects into their JSON representation. It can also be used to convert a JSON string to an equivalent Java object.
- 39. Gson We can customize named fields, this improves code readability:
- 40. Stetho Stetho is a sophisticated debug bridge for Android applications. When enabled, developers have access to the Chrome Developer Tools feature natively part of the Chrome desktop browser.
- 42. How? Adding this libraries to our project it's really easy. This libraries are located in two main repositories: ● Maven Central ● JCenter - Default on Android Studio On our build.gradle file, we add:
- 43. Finding libraries Android Arsenal Gradle, please
- 44. What’s next?
- 45. Finding libraries ● RXJava - Reactive Programming ● Dagger2 - Dependency Injection ● Kotlin - New scripting language
- 46. References ● Robert Martin - The Clean Architecture ● Fernando Cejas - The Clean Architecture ● Gradle - Android Tools ● Android Developers - Support Libraries ● Design Support Library Examples - Repository ● Retrofit - REST Adapter ● Picasso - Image loader ● Gson - JSON parser ● Stetho - View inspector ● Espresso - Samples ● Android Arsenal - For libraries / Gradle Please - Gradle dependencies
- 47. Thanks