Savoir-faire Linux’s Web & Mobile Development Team was at the DroidCon (@droidconNYC) in New  York on September 25th and 26th. DroidCon NYC is basically one of the biggest events on the planet fully dedicated to Android developers. During this two-day conference, more than 900 participants have been attending nearly 70 sessions on Android and its vibrant ecosystem. In this article, our team gives you an update on the presentations they have attended.

Sessions on Architecture

Model View Intent (MVI), Embracing Reactive UI’s

Our Web & Mobile Team! From the left to the right: Alexandre Lision, Hadrien De Sousa, and Thibault Wittemberg.

MVI is an application design pattern from the Cycle.js javascript library. It is based primarily on the concept of “Intents”, which represent the flow of user actions and the notion of “State”, which represents the immutable state of the application at a time T.

Intent streams are connected to the “State Reducers“. These reducers are simple functions whose purpose is to modify the state of the application step by step. The state is then displayed by the shape view of a “View State” (a pre-formatted state specifically for the view to display it).

This design pattern is therefore very much about functional reactive programming (or asynchronous dataflow programming). This is very close to Redux and highlights the interest of the immutability of the state (the mutability allows the sharing of reference on objects in memory, it is thus source of effects of uncontrolled edges) .

It also makes it possible to address the recurrent problem of managing the life cycle of the Activity / Fragment by introducing a cache of “State” on which the view will connect to each of its instantiations (in the case of a rotation for example) .

• Discover the implementation of this model by consulting the article: Reactive Apps with Model-View-Intent – Part1 – Model by Hannes Dorfmann

Reactive Clean Architecture

In this talk, the idea of “Clean Architecture” is based on a division of the application into 3 layers:

• Presentation
• Domain
• Data

Reactive programming can help us in the communication between these layers that we present below.

Data layer

This layer exposes a “Repository” that provides public access to our data model and manages a “Reactive Store” that maintains the state of the application. Internally, this repository will rely on technical sub-layers such as network access, persistence and access to the file system.

Domain layer

This layer is based on a “Reactive Interactor” whose purpose is to manage user input. This Interactor subscribes to the “Reactive Store” in order to expose (by possibly filtering) the states intended for the upper layers (in particular the Presentation layer).

Presentation layer

This layer manages “ViewEntities” which represent the states of the application pre-formatted for the view. A “View Model” will be responsible for the mapping between the states from the “Reactive Store” (made available by the “Reactive Interactor”) and these “ViewEntities”.

In order to read more on this subject, you can consult the following article: Reactive Clean Architecture with Android Architecture Components

Opening Talk at .droidconNYC 2017

Advanced Networking with RX Java + Retrofit

While there are many useful example on how to use the “Retrofit” library, there is still need to better understand how it plays out in the context of complex cases such as the following:

• Failure recovery,
• The management of specific error codes,
• Progress indicator display.

Here we provide you with some helpful tricks to address each of these cases.

The failure to recovery

• Using the RxJava retryWhen operator.

Http errors

It may be interesting to apply the “share” operator on the observable Rx managing the requests (this makes it possible not to re-execute the request with each subscription). It is then possible to create as many subscriptions as there are error codes to manage, applying to each of its subscriptions a “filter” operator that will only pass the results with the error code to manage.

Progress indicator

The Rx stream managing the network request may someday set a “progress state” in the form of a “BehaviorSubject”. The Presenter (or ViewModel) can thus subscribe to the Observable resulting from this Subject and give rise to an update of the view.

An extra tip

It might be interesting to use RxLifeCycle combined with the MVP pattern to make it easier to manage rotations.

Kotlin

Full stack Kotlin

Kotlin is a well-known language to replace Java, especially as it proposes a more efficient syntax. Although associated with Android, it is also possible to use it in many other contexts such as: server application, native application, and Web application.

Back-end

Ktor is a library offered by Jetbrains (http://ktor.io). It allows to manage the Http layer and the WebSockets. It is therefore quite possible to develop a Rest API in Kotlin for example. Its operation is simple and passes by the instantiation of an embedded server (Jetty, Netty or Tomcat) then by the definition of routes. It is also quite possible to make him manage the static part of a website. Its main fault lies in its lack of documentation.

The following alternatives exist: Spring Boot / Javalin / Spark / Kara.

Front-end

It is also possible to write the front-end part (HTML and javascript) of a website in Kotlin with the help of the following APIs: kotlin.browser, kotlin.js, kotlinx.html. Please make sure to use the plugin “kotlin2js” instead of the plugin “kotlin”.

Native

Kotlin also allows you to write native code while having access to all the features of Kotlin 1.1.

We will be able, at the price of a compilation by type of platform, to run the same program on Mac OS, Linux, Android arm32/64, iOS and Windows. Of course, this does not concern user interfaces since each system has its particularities. In addition, one shall pay attention to correctly managing the memory in the manner of a C code. Furthermore, it is recommended to use the plugin “konan” instead of the plugin “kotlin”.

Build

Kobalt is a build system inspired by Gradle and Maven. It is written entirely in Kotlin and its compilation files are also valid Kotlin files, so it is possible to benefit from the code auto-completion features offered by IDEs. For more information, you can also access and read the Kobalt’s documentation –Kobalt: A modern, versatile build system.

Data Binding in a Kotlin World

Data binding as proposed by Google goes well with:

• Dagger
• RxJava
• Kotlin
• Architecture Components
• Butterknife

It is, however, incompatible with:

• Anko
• Litho

It is possible to use an expression language directly in the XML layout (to do conditional processing, mathematical operators, etc.). This practice is not widespread since it breaks the principles of responsibility, namely write business code in the view part.

Sessions on the UI / UX Experience

View Performance Deep Dive

The Facebook teams have been trying to solve potential performance problems in rendering views, especially at the List view (ListViews, RecyclerViews …).

To do this, they made a 3-step comparison, measuring the rendering performance of the views with Google’s “Systrace” tool on a Nexus 5.

Step 1 : RecyclerView with ConstraintLayout

Each cell in the list is based on a layout type: “Constraint Layout“. The cells are relatively simple and contain only a text field, a button and an image. The performance analysis shows that the system omits some frames and therefore does not offer an optimal rendering.

Our feedback on the Constraint Layout in a recyclerView is brief; in fact, the wrap_content is sometimes misinterpreted on the height of ViewHolders which forces to use a fixed height.

Step 2: RecyclerView with Drawable

The idea here is not to build a view tree within a cell, but to draw it as a single Drawable.

The root view of the cell thus exposes its Canvas, on which we will come to draw our components. This technique requires a lot of code re-writing and does not take into account accessibility APIs or Touch events.

The measurement with Systrace shows us an obvious gain in rendering.

Step 3 : Litho

Litho is a library made available by Facebook. It relies on the declarative aspect of graphic components directly in the code, and not in XML layouts. Its primary goal is to reduce the rendering time of the view. For this, it is based on:

• A finer division of the view tree (redraws only what is displayed),
• An overall rendering of the view as a Drawable,
• The rendering calculation in a “background thread”.

It also manages accessibility APIs and of course Touch events. Facebook is currently working on the integration of customs animations.

Facebook clearly shows us its intention to converge the concepts put forward in React.js with programming by Component and the use of Props and State. The internal Litho engine is responsible for mimicking the behavior of a virtual DOM. It is a competing vision of MVVM, MVP or MVI type modeling, where it will tend to use in addition to XML layouts a data binding (standard Binding of Android or RxBinding).

To obtain more information, you can read the Litho’s documentation — Litho: A declarative UI framework for Android.

Doze

Included from Android Marshmallow (API 26), Doze and App Standby are two components of energy saving. Doze is a system mode that restricts access to services, applications that use the CPU and the network extensively.

Since Android Oreo (API 26), these restrictions are even more severe and disable even implicit broadcasts (see, e.g. Implicit Broadcast Exceptions) and it is no longer possible to start a service in an application in the background.

To make it easier to migrate applications to include these new restrictions, Evernote has implemented the android-job library for creating deferred and background jobs.

The Resurgence of SQL

After a transition from mode and while many libraries of ORM can be abstracted, the SQL returns today with SQLDelight and Room.

Properly used, SQL allows you to execute the business directly in the database rather than in the code in order to gain performance.

SQLDelight

This library developed by Square generates Java models from SQL that allow to read and write in the database. SQL tables and declarations are written directly into .sq files interpreted by the library.

SQLDelight supports AutoValue but does not support Kotlin data class in its current version

• SQLDelight is available on GitHub, Click here: square/sqldelight

Room

Room is a SQLite abstraction layer developed by Google for Android and is part of the Architecture Components such as LiveData and ViewModel.

This library generates SQL from Java using pre-processor annotation.

There are many examples of implementation of this library including Kotlin and there is more complete documentation for SQLDelight.

To obtain more information, you can consult the Documentation of Room here: Room Persistence Library

GraphQL on Android is here!

GraphQL

GraphQL is a query language for API development that aims to provide a complete description of the data that allows clients to query only what they need. GraphQL is developed by Facebook and is an answer to the problems encountered during the development of API Rest.

• For more information, you can visit the GraphQL Query Language Web site

Apollo

Apollo-Android is a GraphQL client that generates Java templates from GraphQL queries written in a .graphql file. Generated classes are used to create network queries to the GraphQL API.

Apollo was written for the purpose of being fully compatible with the RxJava2 responsive programming library.

• Apollo-Android is available on GitHub.

Upgrading to Moshi

Moshi is a parsing library of JSON to Java developed by Square who wants to be the successor of Gson considered inactive and heavy (1345 methods for Gson against 759 for Moshi).

The implementation of Moshi is relatively similar to that of Gson to facilitate the migration from one to the other. Some differences however:

• Moshi has less default adapter for Java and Android platform types, forcing developers to write their own adapters,
• For the sake of simplification, Moshi is less configurable (no naming strategy, versioning, etc.)
• No JsonElement
• Moshi uses the Okio bookseller for I/O and integrates perfectly with OKHttp

Moshi also supports Kotlin (moshi-kotlin) but is dependent in his current version of kotlin-reflect so size is very important for Android standards (11,500 methods).

• Moshi is available on GitHub