Как ни странно, я не нашел ответа по этому поводу.
Некоторое время я пытался использовать библиотеку постоянства комнат Android для хранения постоянных данных между завершениями приложений, и одна из главных проблем для меня - это их асинхронность (результаты не готовы в тот момент, когда вызов базы данных возвращается ) природа, требующая, чтобы работа для доступа к базам данных выполнялась в отдельных потоках, что делается для того, чтобы максимизировать производительность.
И это, похоже, не проблема сейчас, за исключением одной вещи: мне кажется, что, по крайней мере, в одной большой, важной области трудно понять, как это сделать, по крайней мере, когда принимаются во внимание другие проблемы. account, и это один из , инициализирующих элемент пользовательского интерфейса, такой как Activity или Fragment, где информация, отображаемая в нем для пользователя и / или его состояния, должна быть загружена из базы данных. «Дополнительные проблемы» относятся к тем, которые здесь затрагиваются:
Является ли эффективной практикой реализация Parcelable для объекта базы данных Room?
в частности, я использую настройку проекта, которая в целом следует принципам, упомянутым в ответе: а именно, у меня есть набор «модельных» объектов, которые разработаны, чтобы быть независимыми от базовой системы базы данных, которую мы используем .
Проблема , однако, конечно, пытается выяснить, что делать при первой инициализации, когда мы впервые запускаем приложение и / или функцию пользовательского интерфейса. Здесь должен быть создан объект модели, и в идеале он должен быть заполнен данными из существующей базы данных. А это значит, что мы должны сделать загрузку из базы данных , которая также асинхронна . Тем не менее, мы не можем сделать функцию пользовательского интерфейса, пока у нас не появятся те данные, которые должны ее заполнить, и, таким образом, придется ждать.
И это сталкивается с проблемами хороших методов проектирования: это мой основной вопрос. В частности, я хочу убедиться, что код пользовательского интерфейса знает - в соответствии с тем, что упомянуто в связанном ответе - как можно меньше о базовой реализации базы данных, и это означает, что не может быть «информированным», поэтому Говоря о причудах, подобных тому, что некоторые базы данных требуют асинхронного доступа, а другие - нет. А текущая реализация имеет "синхронную" семантику - ожидается, что вызов LOAD для абстрактной базы данных (в приведенном выше вопросе называется "хранилище") должен предоставлять данные немедленно, а после вызова "SAVE" - немедленно следует ожидать, что последующий вызов «LOAD» вернет данные просто «SAVE» d. Если мы используем обратный вызов, то это означает, что мы должны сделать это в коде пользовательского интерфейса, что означает, что мы преодолеваем барьер абстракции, что явно является плохой практикой проектирования / кодирования и базовым ООП «нет-нет».
Так что это заставляет меня задаться вопросом: "нормально" ли для этого конкретного экземпляра "обманывать", запуская AsyncTask или аналогичный, а затем ожидая с его методом "get ()" под объектом модели ложный синхронный доступ, или Это, как мне кажется, мой тест на запах (говорит о том, что, как правило, если вы пытаетесь сломать или работать с хорошо продуманным конструктивным решением, вы, вероятно, делаете что-то не так), нет-нет и если да, то каков «правильный» способ справиться с этим?
Более того, ни один из найденных мной справочных материалов, по-видимому, не решает эту проблему, хотя кажется, что это такой основной и важный вариант использования, который крайне обостряет и вызывает головокружение.