Une question? Posez-la ici

Aide au développement d'applications

On parle d'injection de dépendances

On travaille avec des interfaces

C'est un framework qui utilise les injections

Heureusement, le code ennuyeux est généré automatiquement

On peut créer un binding : un type et dagger nous donne une instance de ce type

Il y a des components: dans un component, les bindings sont accessibles

On peut utiliser le design pattern @singleton

Ce composant est stand alone, il ne dépend pas d'autres.

Quand on crée cette interface de composant, on doit lui passer une instance du 1er composant.

Et Dagger sur Android? Chez Citymaper ils l'utilisent depuis quelques années.

Comment avez vous mis Dagger dans votre application Android?

Les types Android doivent être créés par des méthodes d'injection:

(application as Myapp).component.inject(this)

Pour créer un scope, on utilise un @Subcomponent

Dans le fragment, on appelle l'activity et on injecte le composant

Injector.obtain<MapActivityComponent>(this).inject(this)

On injecte des composants comme ca:

void inject(RouteActivity...)

On a une public interface implémentée au minimum

Les classes ne savent pas comment l'injection a lieu, le process est transparent

Les multi bindings

3 méthodes:

@Provides

@Intoset

méthode

Dans Dagger 2.10, on facilite l'injection

Rappel, dans une app, on a un service, puis une activity

@contrivutesAndroidInjector

On a un moule dagger qui nous retourne notre composant

On peut avoir un @Activitycode

On peut dire à Dagger de générer un autre composant sur le fragment

abstract fun restaurantsFragment()

Le plus facile c'est de faire nos classes qui étendent les classes de Dagger de base, il y en a 5.

DagerApplication

DaggerActivity

DaggerFragment

DaggerService

DaggerBroadcastReceiver

DaggerContentProvider

On peut écrire les subcomposants nous meme, pas besoin de demander à Android, ça fonctionne

Tout est déja implémenté dans Dagger pour deja commencer à travailler

AndroidInjection.inject(this);

Et voilà

Les sous composants:

@Module

LibraryModule

@Subcomponent

LibrarySubcomponent

implementation 'my.awesome.dependency:sdk:1.0.0'

Quand on expose ces classes dans le graphe Dagger et qu'on lance un build, on a une erreur. Ca plante, pourquoi?

erreur: class file not found...

@Component(dependencies =

modules=

L'équipe dagger réfléchit à compiler les sous composants dans des fichiers séparés. pour rendre la javac compilation plus rapide

Dagger recrute à Citymapper, si vous avez envie de travailler à Londres.

Liens:

Dagger:

https://github..com/google/dagger
 

Une question? Posez-la ici

Aide au développement d'applications 

Migration d'Autovalue vers Kotlin et les data classes

D'après Ricardo Lage, AutoValue est un outil fantastique fourni par Google pour créer des classes de valeur immuables en Java. Si vous effectuez une migration de votre application vers Kotlin, les data classes sont la façon de faire la plus pratique à utiliser pour conserver les mêmes uses cases. Il y a cependant des choses à prendre en compte. Voici une belle experience de migration d'un projet d'AutoValue à des data classes Kotlin, et comment les problèmes trouvés au fil du projet ont été résolus. Au niveau du build, nous pouvons parler des "pros" et des "cons"  de chaque technique au sujet de la temps pris par le build, de la taille du package apk, du nombre de méthodes, et du temps de sérialisation.

Qu'est-ce qy'Autovalue?

Imaginons une classe en java, une classe user, quand on l'instancie, on aura toujours les mêmes objets.

On peut la mettre en final pour empecher la modification

On ajoute un constructeur pour initialiser les champs et leur donner des valeurs

@Nullable

Voilà, avec la classe modiiée, on peut comparer les 2 utilisateurs. Ils auront des IDs différents

On peut implémenter Parcelable

public final class user implements parcelable

A la fin on a un grande classe qui fonctionne comme on veut pour avoir des utlisateurs uniques

On valide que les paramètres constructeurs ne sont pas nuls...

On ajjoute le ToString();

Autovalue arrive et on peut créer ces classes et les comparer plus facilement

Autovalue génère automatiquement ce qu'il faut

Pas de dépendance au runtime

l'API est indépendante , vive l'encapsulation

Il n'y a que très peu de perte de performance

On ajoute l'anotation @Autovalue et voila, c'est simple. Notre classe de 100 lignes fait maintenant 10 lignes

@Autovalue

public abstract class User {

}

Il y a des plugins

auto-value-with

auto-value-gson ...

public abstract class User implements Parcelable {

On a une classe générée par plugin

$$$AutoValue_User

$$AutoValue_User

$AutoValue_User

Pourquoi migrer en data classes?

Parce que si on migre en Kotlin on n'a pas le choix

Les data classes sont les réponses de Kotlin aux méthodes classes equals(), hashCode(), toString()

Data classes et les avantages sur AutoValue?

Build plus rapide...

Issues dans les plugins

@Parcelize plugin, c'est le support officiel de Parcelable pour Kotlin

C'est un plugin compiler. C'est complié en une passe

Gson: https://github.com/google/gson

Moshi: https://github.com/square/moshi

Une question? Posez-la ici

Aide au développement d'applications

Ce transcript reflète exclusivement l'opinion de ses auteurs et n’engage en aucune façon Consultingit

Voilà, j'espère que ça vous a plu. Vos commentaires/remarques sont les bienvenus