What is rom in android mobile

Understanding migrations with Room

Performing database migrations with the SQLite API always made me feel like I was defusing a bomb — as if I was one wrong move away from making the app explode in my users’ hands. If you’re using Room to handle your database operations, migrations are as easy as flipping a switch.

With Room, if you change the database schema but don’t upgrade the version, your app will crash. If you upgrade the version but don’t provide any migrations your app will crash or, the database tables are dropped and your users will lose their data. Don’t risk your (app’s) life by guessing w̶h̶i̶c̶h̶ ̶s̶w̶i̶t̶c̶h̶ ̶t̶o̶ ̶f̶l̶i̶p̶ how to implement migrations. Rather, understand how Room works internally, to migrate your database with confidence.

Database migrations under the hood

What SQLite API does

SQLite databases handle schema changes with the help of database versioning. More precisely, every time you alter your schema by adding, removing or modifying tables, you have to increase the database version number and update your implementation of SQLiteOpenHelper.onUpgrade method. This is how you tell SQLite what it needs to do when going from an old version to a new version.

This is also the first call that gets triggered when your app starts working with the database. SQLite will first try to handle the version upgrades and only then it will open the database.

What Room does

Room provides an abstraction layer to ease SQLite migrations in the form of the Migration class. A Migration class defines the actions that should be performed when migrating from one specific version to another. Room uses its own implementation of SQLiteOpenHelper and, in the onUpgrade method, will trigger the migrations you defined.

Here’s what happens when you access the database for the first time:

1. The Room database is built
2. SQLiteOpenHelper.onUpgrade method is called and Room triggers the migrations
3. The database is opened

If you don’t provide migrations but you increase the database version, your app might crash or your data may be lost, depending on some circumstances that we will consider below.

An important part in the migration internals is played by an identity hash String that is used by Room to uniquely identify every database version. This identity hash for the current version is kept in a configuration table managed by Room in your database. So, don’t be surprised if you peek into your database to see the room_master_table table in there.

Let’s take a simple example where we have a users table, with two columns:

• an ID, int , that is also the primary key
• a user name, String

The users table is part of a database whose version is 1, implemented using the SQLiteDatabase API.

Let’s consider that your users are already using this version and you want to start using Room. Let’s see how Room handles a few scenarios.

Migrate SQLite API code to Room

In another post we looked at migrating your app to Room, let’s build on this and go into more detail about the data migration. Let’s assume that the User entity class and UserDao , the data access object class, are created, and focus only on the UsersDatabase class, that extends RoomDatabase .

Scenario 1: keep the database version unchanged — app crashes

Here’s what Room is doing behind the scenes if we keep the database version unchanged and we run our app.

Step 1: Try to open the database

• Check the identity of the database by comparing the identity hash of the current version with the one saved in the room_master_table. But, since there’s no identity hash saved, the app will crash with an IllegalStateException ❌

Room will always throw an IllegalStateException if you modify the database schema but do not update the version number.

Let’s listen to the error and increment the database version.

Scenario 2: version increased, but no migration provided — app crashes

Now, when to run the app again Room is doing the following:

Step 1: Try to upgrade from version 1 (installed on device) to version 2

• Since there are no migrations, the application crashes with IllegalStateException . ❌

Room will throw an IllegalStateException if you don’t provide a Migration.

Scenario 3: version increased, fallback to destructive migration enabled — database is cleared

If you don’t want to provide migrations and you specifically want your database to be cleared when you upgrade the version, call fallbackToDestructiveMigration in the database builder:

Now, when to run the app again Room is doing the following:

Step 1: Try to upgrade from version 1 (installed on device) to version 2

• Since there are no migrations and we fallback to destructive migration, the tables are dropped and the identity_hash is inserted. 🤷

Step 2: Try to open the database

• Identity hash of the current version and the one saved in the room_master_table are the same. ✅

So now, our app doesn’t crash, but we lose all the data. So be sure that this is how you specifically want to handle migrations.

Scenario 4: version increased, migration provided — data is kept

To keep the user’s data, we need to implement a migration. Since the schema doesn’t change, we just need to provide an empty migration implementation and tell Room to use it.

When running the app, Room does the following:

Step 1: Try to upgrade from version 1 (installed on device) to version 2

• Trigger the empty migration ✅
• Update the identity hash in the room_master_table ✅

Step 2: Try to open the database

• Identity hash of the current version and the one saved in the room_master_table are the same. ✅

So now, our app opens, and the user’s data is migrated! 🎉

Migration with simple schema changes

Let’s add another column: last_update , to our users table, by modifying the User class. In the UsersDatabase class we need to do the following changes:

1. Increase the version to 3

2. Add a Migration from version 2 to version 3

3. Add the migration to the Room database builder:

When running the app, the following steps are done:

Step 1: Try to upgrade from version 2 (installed on device) to version 3

• Trigger the migration and alter the table, keeping user’s data ✅
• Update the identity hash in the room_master_table ✅

Step 2: Try to open the database

• Identity hash of the current version and the one saved in the room_master_table are the same. ✅

Migrations with complex schema changes

SQLite’s ALTER TABLE… command is quite limited. For example, changing the id of the user from an int to a String takes several steps:

• create a new temporary table with the new schema,
• copy the data from the users table to the temporary table,
• drop the users table
• rename the temporary table to users

Using Room, the Migration implementation looks like this:

Multiple database version increments

What if your users have an old version of your app, running database version 1, and want to upgrade to version 4? So far, we have defined the following migrations: version 1 to 2, version 2 to 3, version 3 to 4, so Room will trigger all migrations, one after another.

Room can handle more than one version increment: we can define a migration that goes from version 1 to 4 in a single step, making the migration process faster.

Next, we just add it to the list of migrations:

Note that the queries you write in the Migration.migrate implementation are not compiled at run time, unlike the queries from your DAOs. Make sure that you’re implementing tests for your migrations.

Show me the code

You can check out the implementation in this sample app. To ease the comparison every database version was implemented in its own flavor:

1. sqlite — Uses SQLiteOpenHelper and traditional SQLite interfaces.
2. room — Replaces implementation with Room and provides migration to version 2
3. room2 — Updates the DB to a new schema, version 3
4. room3 — Updates the DB to a new, version 4. Provides migration paths to go from version 2 to 3, version 3 to 4 and version 1 to 4.

Conclusion

Has your schema changed? Just increase the database version and write a new Migration implementation. You’ll ensure that your app won’t crash and your user’s data won’t be lost. It’s as easy as flipping a switch!

But, how do you know if you flipped the right switch? How do you test that you migrated from your SQLiteDatabase implementation to Room correctly, that you implemented the correct migration between different database versions, or that your database is indeed starting as it should in a specific version? We talked about testing migrations in detail, covering several different scenarios here:

Источник

Room: Хранение данных на Android для всех и каждого

Room — это новый способ сохранить данные приложений в Android-приложении, представленный в этом году на Google I/O. Это часть новойAndroid Architecture, группа библиотек от Google, которые поддерживают уместную архитектуру приложений. Room предлагается в качестве альтернативы Realm, ORMLite, GreenDao и многим другим.

Room — это высокоуровневый интерфейс для низкоуровневых привязок SQLite, встроенных в Android, о которых вы можете узнать больше в документации. Он выполняет большую часть своей работы во время компиляции, создавая API-интерфейс поверх встроенного SQLite API, поэтому вам не нужно работать с Cursor или ContentResolver.

Использование Room

Во-первых, добавьте Room в свой проект. После этого вам нужно будет передать в Room, как выглядят ваши данные. Предположим, имеется простой класс модели, который выглядит следующим образом:

Чтобы рассказать Room о классе Person, добавляем аннотицию Entity к классу и @PrimaryKey к ключу:

Благодаря этим двум аннотациям Room теперь знает, как создать таблицу для хранения экземпляров Person.

Важная вещь, которую следует учитывать при настройке ваших моделей: каждое поле, которое хранится в базе данных, должно быть общедоступным или иметь геттер и сеттер в стандартном стиле Java Beans (например, getName () и setName (имя строки)).

В классе Person теперь есть вся информация, которая требуется Room для создания таблиц, но у вас нет способа фактически добавлять, запрашивать или удалять данные из базы данных. Вот почему вам нужно будет сделать объект доступа к данным (DAO). DAO предоставляет интерфейс в самой базе данных и занимается манипулированием хранимыми данными Person.

Вот простой интерфейс DAO для класса Person:

Первое, что нужно заметить, это то, что PersonDao — это интерфейс, а не класс. Другая интересная деталь — это инструкции SQL в аннотациях Query (). Операторы SQL говорят Room, какую информацию вы хотите получить из базы данных. Они также проверяются во время компиляции. Поэтому, если вы измените подпись метода List getAllPeopleWithFavoriteColor ( название цвета ) на List getAllPeopleWithFavoriteColor ( int color ), Room выдаст ошибку во время компиляции:

И если вы сделаете опечатку в выражении SQL, например, напишите favoriteColors ( множественное число ) вместо favoriteColor ( единственное число ), Room также выдаст ошибку компиляции:

Вы не можете получить экземпляр PersonDao, потому что это интерфейс. Чтобы иметь возможность использовать классы DAO, вам необходимо создать класс базы данных. За кулисами этот класс будет отвечать за ведение самой базы данных и предоставление экземпляров DAO.

Вы можете создать свой класс базы данных всего за пару строк:

Это лишь описание структуры базы данных, но сама база данных будет жить в одном файле. Чтобы получить экземпляр AppDatabase, сохраненный в файле с именем populus-database, вы должны написать:

Если вы хотите получить все данные обо всех Person, которые находятся в базе данных, вы могли бы написать:

Преимущества использования Room

В отличие от большинства ORM, Room использует обработчик аннотации для выполнения всей своей манеры сохранения данных. Это означает, что ни ваши классы приложений, ни классы моделей не должны ничего расширять в Room, в отличие от многих других ORM, включая Realm и SugarORM. Как вы видели при ошибках с аннотациями Query () выше, вы также получаете возможность проверки корректности SQL-запросов во время компиляции, что может сэкономить вам много хлопот.

Room также позволяет вам наблюдать за изменениями данных, интегрируя их как с API LiveData Архитектурных Компонентов, так и с RxJava 2. Это означает, что если у вас сложная схема, где изменения в базе данных должны появляться в нескольких местах вашего приложения, Room делает уведомления об изменениях. Это мощное дополнение может быть включено одной строкой. Все, что вам нужно сделать, это изменить тип возвращаемых значений.

Например, этот метод:

Самое большое ограничение в Room: взаимосвязи

Самым большим ограничением в Room является то, что он не будет обрабатывать отношения с другими типами сущностей для вас автоматически, как и другие ORM. Это означает, что если вы хотите отслеживать домашних животных:

То Room выдаст ошибку компиляци, так как не знает, как сохранить отношения между Person и Pet:

Ошибка при компиляции предлагает конвертер типов, который преобразует объекты в примитивы, которые могут быть непосредственно сохранены в SQL. Поскольку List нельзя свести к примитиву, вам нужно сделать что-то другое. Это отношения «один ко многим», где у одного Person может быть много Pet. Room не может моделировать такие отношения, но она может справиться с обратными отношениями — у каждого Pet есть один Person. Чтобы смоделировать это, удалите поле для Pet в Person и добавьте поле ownerId в класс Pet:

Это приведет к тому, что Room обеспечит ограничение внешнего ключа между объектами. Room не будет вызывать отношения «один-ко-многим» и «много-к-одному», но она дает вам инструменты для выражения этих отношений.

Чтобы получить всех домашних животных, принадлежащих конкретному человеку, вы можете использовать запрос, который находит всех домашних животных с данным идентификатором владельца. Например, вы можете добавить в свой DAO следующий метод:

Стоит ли использовать Room?

Если вы уже настроили сохранение данных в своем приложении и довольны им, то ничего не изменяйте. Каждая ORM и встроенная реализация SQLite будут продолжать работать так же, как и раньше. Room — это всего лишь еще один вариант сохранения данных.

Если вы используете SQLite или собираетесь использовать его, вы должны попробовать Room. Он обладает всеми возможностями, необходимыми для выполнения расширенных запросов, одновременно устраняя необходимость писать SQL-запросы для поддержки базы данных самостоятельно.

Источник