Dans cette partie, nous allons nous concentrer sur la manière de sauvegarder des données structurées sur le téléphone de nos utilisateurs.
Facile, on l'a fait dans la partie précédente ! On ouvre un fichier et on stocke nos données structurées à l'intérieur ?
Alors non, pas vraiment ! Quand je parle de données structurées, je parle de données qui possèdent de fortes relations entre elles. Généralement, ce type de données est stocké dans une base de données relationnelle. Sur Android, nous avons la possibilité de stocker ces données dans une base de données dite "SQLite".
Revenons-en à SQLite. Ce dernier est un moteur de base de données relationnelle entièrement manipulable grâce au langage SQL. Contrairement aux serveurs de base de données traditionnels comme MySQL, PostgreSQL ou encore Microsoft SQL Server, l'intégralité de la base de données est stockée dans un fichier (et non sur un serveur distant).
Du fait de sa légèreté (le code source de SQLite pèse moins de 2 Mo), on retrouve SQLite dans énormément de logiciels, comme les navigateurs internet, les systèmes embarqués, ainsi que les systèmes d'exploitation comme Android.
Historiquement, sur Android, la manipulation de la base de données SQLite se faisait d'une manière... comment dire... assez compliquée !
Premièrement, car les requêtes SQL étaient écrites "en dur" dans des variables String statiques...
private static final String SQL_CREATE_ENTRIES =
"CREATE TABLE " + FeedEntry.TABLE_NAME + " (" +
FeedEntry._ID + " INTEGER PRIMARY KEY," +
FeedEntry.COLUMN_NAME_TITLE + " TEXT," +
FeedEntry.COLUMN_NAME_SUBTITLE + " TEXT)";
L'inconvénient de cette méthode c'est qu'il n'y a aucune vérification possible de la part de votre IDE (Android Studio) au moment de la compilation. Cela veut dire que, si une erreur s'est glissée, vous ne la verrez QUE lorsque votre application plantera.
Deuxièmement, car vous aviez besoin nativement de beaucoup de code pour transformer le résultat d'une requête en un objet Java. Du coup, des ORM ont commencé à apparaître pour pallier ces différents problèmes !
Euh, c'est quoi un ORM ?
Alors en fait, un Object-Relation mapping (ou mapping objet-relationnel) est une technique de programmation qui permet de créer volontairement l'illusion que l'on manipule une base de données orientée objet, alors qu'en réalité nous manipulons une base de données relationnelle. En fait, l'ORM va permettre de créer une couche d'abstraction supplémentaire, afin que nous puissions manipuler une base de données relationnelle (comme SQLite !) avec des objets.
Il existe beaucoup de projets Open Source d'ORM sur Android – comme, par exemple, greenDAO ou OrmLite – dans le but de manipuler plus facilement une base de données SQLite.
Du coup, face à tout ce remue-ménage, Android a décidé de prendre les choses en main... en sortant son propre ORM, Room !
Cette sortie est apparue en même temps que la sortie de l'Architecture Components, une sorte de guide de bonnes pratiques et de librairies destinées aux développeurs Android afin d'améliorer la qualité de leurs applications. J'en parlerai en détail dans la prochaine partie de ce cours.
Dans cette partie, nous allons donc nous servir de Room, afin de faciliter le stockage de nos données structurées dans la base de données SQLite d'Android.
Pour cela, nous allons installer Room dans notre projet Android SaveMyTrip, en modifiant comme d'habitude notre fichier build.gradle.
Extrait de build.gradle :
dependencies {
//ROOM
implementation "androidx.room:room-runtime:2.3.0"
annotationProcessor "androidx.room:room-compiler:2.3.0"
//VIEW MODEL & LIVE DATA
implementation 'androidx.lifecycle:lifecycle-extensions:2.2.0'
}
Synchronisez votre projet. Et c'est tout ! 🚀
En résumé
Les bases de données sur Android sont gérées avec SQLite.
Les ORM permettent de gérer une base de données facilement sans s’éloigner de la programmation orientée objet.
Android nous fournit son ORM appelé Room.
Maintenant que le projet est prêt à accueillir une base de données, rentrons un peu plus dans le détail de Room et créons nos premières entités.