Comments 15
У Вас одна конфигурация для всех объектов (кроме логов). Каждая конфигурация — это отдельный файл. Получается, что все объекты, хранящиеся в LocalStorage, размещаются в одном файле. Это не увеличит время получения выборки (особенно, если поля, по которым производится выборка, не проиндексированы), которую, как я понял, вы получаете в UI потоке?
Также меня смущает отсутствие закрытия инстанса в UI потоке. Вроде (по крайней мере раньше) Realm даже предупреждения в логах кидает по поводу незакрытого инстанса.
Возможно, он кидал предупреждения, если поток, на котором он был открыт, перестал работать. Смысла закрывать инстанс на UI потоке мы не увидели. После первого запроса за данными инстанс прогревается и следующие выборки уже в разы быстрее, поэтому мы вообще ушли от асинхронных выборок и все делаем синхронно блокирующим вызовом. А время запроса в другом потоке для нас чуть менее приоритетно, так как это не повлияет на пользователя и графический интерфейс. У нас нет блокирующих пользовательских операций, при любом изменении данных мы сразу же изменяем данные локально и асинхронно создаем джобу в очередь на изменение данных на сервере. Время выполнения этой работы никак не будет влиять на пользователя и заставлять его ждать.
В своих примерах они закрывают его на Activity.onDestroy(), предполагая, что в рамках этого активити показываются специфичные данные, в меньшей степени используемые в других компонентах. У нас же два активити и пара сервисов, все используют одни и те же наборы данных.
Насчет разделения на конфигурации. Это оправданно только если обьекты в этих конфигурациях будут независимыми, нам показалось это усложнением и мы отделили в отдельные конфигурации только логирование, статистику и прочую информацию не относящуюся непосредственно к пользователю.
Если пользоваться Kotlin то есть прикольная библиотека с extentions для Realm. Проблема закрытия инстанса отпадает сама собой.
Оффтоп. Можно узнать, почему на ваших скриншотах в гуглплее вы обрезали их снизу? Неужели только для того, чтобы вставить немного текста в пустом пространстве вверху? Не в первых раз встречаю подобное представление скриншотов и никак не могу понять, для чего это делается. Многие компании показывают скриншоты как есть, без обрезания и, на мой взгляд, они выигрывают. Тем не менее многие обрезают.
1) Вся работа с реалмом у меня ведется изолированно через репозиторий. Ни каких active records у меня нет, так как я предпочитаю работать с иммутабельными объектами, с ними меньше непредсказуемых поведений. Кстати, это же и устраняет проблему с RealmList
2) Работа с реалмом всегда ведется в фоновом потоке, на каждый запрос создается инстанс и закрывается после выполнения. Никаких проблем с производительностью я не заметил. Тут очень поможет reactive подход. Написал один раз и радуешься потом.
3) Касательно множетственного наследования: в java его как бы вообще нет. Я понял о чем речь идет, что в цепочке наследования не может быть ничего, кроме RealmObject, но это немного другое.
4) На счет тестов, да, тут проблема, но надо мокать не реалм, а репозиторий в принципе, потому что логики в репозитории должно быть минимум. Если тестировать его — то это уже интеграционные тесты. Последние с реалимом надо запускать сразу на дейвасе.
1) Как происходит изменение обьекта у вас? Например, есть таблица Parent и вам нужно добавить на него связь с новым Kid (внутри Parent список из Kid). И, если не трудно, расскажите, как вы делаете поиск по спискам. Например нужно достать Kid из Parent по имени.
2) Закрывать Realm после каждой транзакции довольно расточительно. В вашем случае стоит сделать пулл потоков для работы с Realm'ом и закрывать инстанс после работы потока, а не после транзакции. Да и если делать все операции в фоновом потоке, то это либо callback hell, либо, как вы и сделали, использовать rx. Мы же специально перешли на Realm, чтобы перенести все операции на UI поток.
3) Да, речь была про цепочку наследования. Но это мелочь.
4) Тесты ломаются если в ваших модельках есть выборки рилмовские (например для работы со списками), то есть все это приходится уносить из моделей и, в придачу к репозиторию, мокать все классы, которые содержат логику этих выборок. Но да и это тоже решаемо. Только у вас полностью пропадает возможность протестировать вполне важную бизнес логику. В этом случае интеграционные тесты, поднимающие аппликейшен, не очень подходят.
val kid = parent.kidlist.firstOrNull { kid -> kid.name == "Piter"}
2) возможно так и есть, но городить пул потоков — это преждевременная оптимизация, вот когда начнутся тормоза в текущем вариант — я задумаюсь, сейчас все работает достаточно быстро. Никакого callback-hell у меня нет, везде rxjava. Делать операции с БД в UI — сомнительное занятие, на мой взгляд, но тут дело каждого.
4) тестирование реалма — это вообще отдельная тема, к тому же холиварная.
1) При работе с отвязанными объектами теряется их свойство "живых обьектов", теряется возможность выборок удобных из Realm'а и нам показалось, что это дополнительные движения. Но вообще да, мы тоже думали о том, чтобы за пределами репозитория взаимодействовать с отвязанными объектами.
2) Да там ведь и не БД уже, там прогретый кеш. А пулл потоков это не городить, это группировка по типу операции, вы ведь все равно там на каком-то Sheduler'е их запускаете.
Что на счет выборок — то тут не могу сказать, на мобилке не должны храниться такие объемы данных, чтобы разница производительности при выборке небольшой части и всей таблицы была огромной.
2) Не важно, бд или кэш. Да, там шедулеры, но делать еще одну ненужную вещь, ради того, что это будет работать на 100мс быстрей как-то сомнительно в данном случае.
Как подружиться с Realm