En los últimos años vimos grandes cambios en Android. Empezando por Android Studio, dejando de lado Eclipse e incorporando Gradle. Luego el lanzamiento de Android 5 Lollipop, presentando el concepto de Material Design y por último, la incorporación de Android Wear, Auto y TV. Son muchos cambios en poco tiempo, es por eso que necesitamos mejorar el proceso de desarrollo, incorporando las últimas tecnologías pero sin descuidar la calidad del producto. En esta charla veremos algunas buenas prácticas para asegurar una aplicación de gran calidad.

2. 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

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
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