Android Best Practices

Transcription

1

2 Android Best Practices

3 Agenda Introduction The clean architecture Testing Support library Libraries we can depend on What's next

4 Introduction

5 Introduction Android Studio Gradle Material Design Lollipop Android Wear / Auto / TV

6 The clean architecture

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 Picasso allows for hassle-free image loading in your application often in one line of code! Image transformation

37 ButterKnife View injection library Annotate fields 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.

41

42 How? Adding this libraries to our project it's really easy. On our build.gradle file, we add: This libraries are located in two main repositories: Maven Central JCenter - Default on Android Studio

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