Android realm vs room

Humble Bits

Which one to use- Realm or Room?

We have lots of options for storing data. There are plenty of libraries available in the market and some of them look very promising and come out of the box. Today I will highlight some points between two big celebrity names of Android Development in terms of storing data. We will see the difference between the shiny, new library “Room” and the old but famous “Realm”. We will see some of the pros and cons of both libraries but the choice is up to you, which one you will use in your next project. I promise you that at the end of this blog, you’ll have a clear mindset about making a choice between Realm or Room if ever you find yourself at crossroads with them.

Let’s talk about what they are and what they do-

REALM

Realm has become favorite among many developers and they are using it without any hesitation. The reason why it is being used so much is that it-
1. Uses standard Java objects
2. Written mostly in C++
3. Simple to create database

The library is well documented and you can use it easily in your project without any prior knowledge of Realm Database. It will guide you at every step like your parents ;).

Here are some points regarding Realm-

1. Realm works well with Query Builder API.
2. Realm lets you copy objects so that they can be accessible outside of the Realm instance.
3. You can only access “Realm” objects when you have Realm instance open, so it means that logic is bound to activity/fragment.
4. One of the major difference is that Realm was born before Room, so it’s more mature. 🙂
5. We have also seen that people are facing multi-threading issue in case of Realm.
6. In case of Realm, all relationships are established using B+ tree. You just need to create your POJO class and declare relationship, Realm abstracts and handles the schema.
7. Realm can be encrypted.
8. Realm supports a link between the objects, you can easily access pet.getOwner() if the owner is set as a property of pet.
9. Each result in case of Realm is lazy-loaded.
10. Realm doesn’t work with ContentProvider.
11. There is no support for type adapters, you have to use getter/setter for the data.
12. Realm is also available for iOS, so if you are planning to build a cross-platform app, Realm will not disappoint you.
13. Size of the library is 3-4 MB.
14. As an Android Developer, we can’t ignore the pesky method count limit. Realm has 2k methods in it.

Room! Shiniest, newest (a small but famous kid :)) library introduced in the Google IO, 2017 with the Android Architecture Component. Room provides an abstraction layer over SQLite that allows us to use the full power of SQLite. There are three main components in Room-
1. Database
2. Entity
3. DAO

Here are some points regarding Room-

1. Retrofits like interfaces to SQL queries.
2. There is no multi-threading issue in case of Room.
3. You have to establish the relationship if you are using Room, but the reason given by the Room developers doesn’t make it count as a drawback-

However, on the client side, lazy loading is not feasible because it’s likely to happen on the UI thread, and querying information on disk in the UI thread creates significant performance problems. The UI thread has about 16 ms to calculate and draw an activity’s updated layout, so even if a query takes only 5 ms, it’s still likely that your app will run out of time to draw the frame, causing noticeable jank. Worse still, the query could take more time to complete if there’s a separate transaction running in parallel, or if the device is busy with other disk-heavy tasks.

4. Since Room works on SQL, you can write your query easily.
5. Room can be encrypted too.
6. You can use LiveData with Room in a few steps.
7. The library takes up only 50KB.
8. If we consider the pesky method count in case of Room, Room again leads in the race because it only uses 300 methods.
9. Room also provides easy migration mechanism which is fully tested.

So, more or less every storage library does the same thing. Now we have to decide which path we should follow that will suit a particular requirement. If you want to get rid of that large amount of pesky method which is closer to the limit of 64K and also want to play with SQL then you can go with Room. But on the other hand, Realm is not the quickest.

But, oh! it provides you the most suitable version that has 7 years of testing experience. As per my experience if your project has some heavy database work, go for Realm else for small task/project you can opt Room.
I hope now you have some idea of which library fits in which conditions. Happy Coding. 🙂

Источник

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-запросы для поддержки базы данных самостоятельно.

Источник

Realm VS Room в Android

Я создаю приложение, и мне нужно использовать базу данных в нем. Я подумываю об использовании Room, так как сейчас он новый и горячий. Но я слышал много хорошего о Realm. Может кто-то указать на возможные преимущества использования каждого из них?

Я сделал свое исследование и прочитал документы, но у меня нет опыта, чтобы понять это сам

Прошло некоторое время, и я могу указать еще одну причину использования Room. Хотя вы можете использовать Realm и Transformations, чтобы связать вещи с LiveData, но с Room вы можете напрямую вернуть LiveData (а также типы RXJava с помощью плагина) для БД, что избавит вас от стандартного кода и головной боли.

РЕДАКТИРОВАТЬ 2:

В дополнение к первому редактированию Room теперь имеет первоклассную поддержку сопрограмм в Kotlin, поэтому, если вы планируете использовать их, это будет Nice-have -> https://medium.com/androiddevelopers/room -coroutines-422b786dc4c5

Относительно быстрая и удобная библиотека, все ссылки просто реализованы, что связано с объектной ориентацией базы данных. Отличная документация. Является, пожалуй, одним из лучших вариантов для хранения данных на мобильном устройстве на данный момент, минусом может быть только увеличение размера apk-файла на 2,5 МБ.

Интересное решение, представленное в Google I/O 2017 как оптимальное для работы с базой данных на Android ОС. Несмотря на то, что необходимо использовать явные sql-запросы, библиотека оказалась довольно удобно и мне понравилось лично. По производительности лидирует, поэтому я бы посоветовал вам выбрать именно эту библиотеку. Большим преимуществом этого является встроенная база данных SQLite. Поскольку это решение, представленное Google, оно быстро стать популярным, и, следовательно, не будет проблем с поиском решений проблем, которые возникают вместе с ним.

Realm использует больше RAM и увеличивает размер apk, время сборки. Поэтому я предпочитаю Room.

Основная причина, по которой мы подтолкнули использование библиотеки для базы данных, заключается в том, что она позволила нам моделировать наши объекты и упростила CRUD, у меня был хороший опыт с Realm , его действительно легко настроить и работать это быстро и гибко, но размер библиотеки был проблемой, можно уменьшить размер APK, разделив APK по целевой ABI сборки, но я предпочел использовать GreenDao , потому что он основан на SQLite, хотя я думаю, у него есть некоторые недостатки, как и у любых других библиотек, но это был лучший вариант для меня.

Честно говоря, я еще не пробовал Room, но после краткого ознакомления с документами вы найдете его более гибким и дружелюбным для разработчиков. Как фанат Google, я предпочитаю использовать библиотеку ребят Google! Как я уже говорил, я предпочитаю слой , а не собственный SQLite , чем целую новую библиотеку базы данных .

Я попробую Room в моем следующем проекте и поделюсь своим опытом здесь в обновлении позже, надеюсь, это поможет.

Источник

Realm VS Room в Android [закрыто]

Я создаю приложение, и мне нужно использовать в нем базу данных. Я рассматриваю возможность использования комнаты, поскольку она новая и горячая прямо сейчас. Но я слышал много великих вещей о царстве тоже. Может ли кто-нибудь указать на возможные преимущества использования каждого из них?

Я провел исследование и прочитал документы, но у меня нет опыта, чтобы понять это сам

2 ответов

относительно быстрая и удобная библиотека, Все ссылки просто реализованы, что связано с объектной ориентацией базы данных. Отличная документация. Является, пожалуй, одним из лучших вариантов хранения данных на мобильном устройстве на данный момент, минусом может быть только увеличение размера apk-файла на 2,5 МБ.

интересное решение, представленное на Google I / O 2017 как оптимальное для работы с базой данных на ОС Android. Несмотря на то, что нужно использовать явные sql-запросы, библиотека получилась довольно удобной и мне она понравилась лично. По производительности лидирует, поэтому я бы посоветовал вам выбрать именно эту библиотеку. Большое преимущество этого основано на встроенной базе данных SQLite. Так как это решение, представленное Google, быстро станет популярным, и, следовательно, не будет проблем с поиском решений проблем, которые возникают вместе с он.

Realm использует больше ОЗУ и увеличивает размер apk, время сборки. Поэтому я предпочитаю комнату.

основная причина, по которой мы подтолкнули использовать библиотеку для базы данных, заключается в том, что это позволило нам моделировать наши объекты и сделать CRUD более легким, у меня был хороший опыт с Realm, это очень легко настроить и работать, это быстро и гибко, но размер библиотеки был проблемой, можно уменьшить размер apk, разбив apks на целевой ABI сборки, но я предпочитал использовать GreenDao потому что он основан на SQLite, хотя я думаю, что он имеет некоторые disatvantages, как любой другие библиотеки, но это был лучший вариант для меня.

честно говоря, я еще не пробовал номер, но с кратким взглядом на документы вы найдете его более гибким и дружелюбным для разработчиков, как поклонник google, я предпочитаю использовать библиотеку Google guys! Как я уже сказал, Я предпочитаю слой над собственным SQLite до целая новая библиотека баз данных.

Я попробую комнату в моем следующем проекте и поделюсь своим опытом здесь в обновлении позже, надеюсь, это поможет.

Источник