DS
Всем привет, хочу поинтересоваться о гуд практике в данном кейсе. Если я получаю сообщение от сервера, то будет ли хорошим решение - запихнуть модель в сервис и из самого приложения получать данные через broadcastreciver
Size: a a a
2018 November 07
DS
Пытаюсь избежать дублирования информации и при этом батарейку сохранить
QH
Всем привет, хочу поинтересоваться о гуд практике в данном кейсе. Если я получаю сообщение от сервера, то будет ли хорошим решение - запихнуть модель в сервис и из самого приложения получать данные через broadcastreciver
Речь о передаче данных из сервиса в активити? Мне понравился bindService.
DS
Спасибо за ответ, Михаил. Да именно о нем. Bindservice - это нечто на подобии databinding от Гугла? Или из другой оперы?
QH
Спасибо за ответ, Михаил. Да именно о нем. Bindservice - это нечто на подобии databinding от Гугла? Или из другой оперы?
Нет. Это возможность связать активити и сервис непосредственно.
DS
Нет. Это возможность связать активити и сервис непосредственно.
То есть можно весь подкапот уложить в сервис и ссылаться на его данные во viewmodel?
DS
Звучит лаконично, спасибо за совет.
QH
То есть можно весь подкапот уложить в сервис и ссылаться на его данные во viewmodel?
Да, можно из сервиса выставить какие-нибудь ливдаты или ещё что нужно.
DS
Нет. Это возможность связать активити и сервис непосредственно.
Михаил, ответьте пожалуйста ещё на один вопрос. Если мне необходимо параллельно получать данные от какого- нибудь API и бд Realm к примеру. То какой метод решения тут будет уместным? Создать очередь для пула? Или довериться магии rx'а?
DS
Как пользоваться rx я осознал, но пришел к выводу, что такое не легко тестировать и контроля за происходящим недостаточно. По моим ощущениям
QH
Михаил, ответьте пожалуйста ещё на один вопрос. Если мне необходимо параллельно получать данные от какого- нибудь API и бд Realm к примеру. То какой метод решения тут будет уместным? Создать очередь для пула? Или довериться магии rx'а?
Вообще, Realm достаточно быстр чтобы гонять запросы в UI-потоке.
А в бэкграунд-потоке, где делается запрос к серверу — тем более без разницы.
Например, запрос к серверу произойдёт за 100 мс, в реалм — за 1 мс, потом нужно будет скопировать данные из реалмовых managed-объектов чтобы передать их в другой поток, выигрыш от такого распараллеливания — околонулевой.
А в бэкграунд-потоке, где делается запрос к серверу — тем более без разницы.
Например, запрос к серверу произойдёт за 100 мс, в реалм — за 1 мс, потом нужно будет скопировать данные из реалмовых managed-объектов чтобы передать их в другой поток, выигрыш от такого распараллеливания — околонулевой.
DS
Вообще, Realm достаточно быстр чтобы гонять запросы в UI-потоке.
А в бэкграунд-потоке, где делается запрос к серверу — тем более без разницы.
Например, запрос к серверу произойдёт за 100 мс, в реалм — за 1 мс, потом нужно будет скопировать данные из реалмовых managed-объектов чтобы передать их в другой поток, выигрыш от такого распараллеливания — околонулевой.
А в бэкграунд-потоке, где делается запрос к серверу — тем более без разницы.
Например, запрос к серверу произойдёт за 100 мс, в реалм — за 1 мс, потом нужно будет скопировать данные из реалмовых managed-объектов чтобы передать их в другой поток, выигрыш от такого распараллеливания — околонулевой.
Понял, микроскопом гвоздь не закалачивать.
AV
Я реалмом не пользовался но слышал что реальные чтение данных происходит во время обращения (чтения) поля DTO которую возвращает реалм и в связи с этим есть подход когда в не ui потоке делают запрос к realm и перекладывают данные из realm dto в pojo
AV
Всем привет, хочу поинтересоваться о гуд практике в данном кейсе. Если я получаю сообщение от сервера, то будет ли хорошим решение - запихнуть модель в сервис и из самого приложения получать данные через broadcastreciver
Вы имеете в виду компонент приложения service или логическую сущность
DS
Вы имеете в виду компонент приложения service или логическую сущность
Компонент приложения, конечно
DS
Ухх... Небольшая сводка с Android studio
DS
Возможно кто-то помнит мой рассказ с багом текствью с переносом строки
DS
Всплыл ещё один косяк. Невозможно без танцев с бубном в папке с ресурсами верстки создать подпапку
DS
Мой стул сейчас повторит судьбу хирасимы
DS
Если быть точнее, то папка создаётся в проекте, но самим сборщиком не индексируется, и даже при явном написании пути в файле сборщика, он напрочь отказывается производить индексацию