« Rev
@android_ru   1367
Fwd »


Ontoshgo
так они и будут разглашать инфу как и что должно быть устроено
Roman
Подскажите пожалуйста такой момент: Нужно сделать какой-то сервис, который будет тянуться через все приложение (не привязан к определенной активити) где нужно с определнной переодичность получать джейсночики с сервера (переписывая старые респонзы) и хранить ответ пока опреденная активити его не запросит Как это всё лучше всего реализовать?
Roman
JobScheduler/WorkManager А хранить данные в бд - например используя Room
я так понимаю нужен PeriodicWorkRequest…но у него ограничение на повторное выполнение минимум 15 минут - это очень много у меня период измеряется в секундах…
Глеб
А ведь он прав)) мож не прям в такой извращённой форме))
Глеб
смымсл ежесекундные апдейты держать за пределами ЛЦ UI
Roman
да не..жуть какая-то..не?
Roman
Каждые несколько секунд? На корыте можно будет тосты делать А как же батарея?
какие тосты? нужно получать актуально состояние заказа
Глеб
если их периодичность прям актуальная то запускаем цикличный чеккер, где он жив пока жива активность и в реальном времени наблюдаем
Roman
Зачем когда приложение закрыто?
я не говорил ничего про закрытое приложение
Глеб
Зачем когда приложение закрыто?
++ либо периоды измеряемые часами или условиями Wifi available, Charger, etc.... тогда без-ui-но
Himars
Тогда просто биндинг сервиса
Глеб
тогда и сервисы не нужны, и .... тадам!!! встречаем его величество ХАНДЛЕР!!!
Глеб
WorkerThread Looper + Handler с delayMessage и quitSafe в onDestroy-е
Roman
тогда и сервисы не нужны, и .... тадам!!! встречаем его величество ХАНДЛЕР!!!
эм…а как я его могу запустить при запуске программы и получать данные на любой активити? т.е. протянуть через все приложение запущенным
Глеб
эм…а как я его могу запустить при запуске программы и получать данные на любой активити? т.е. протянуть через все приложение запущенным
ну я исхожу из single-activity подхода, в ином случае - надо думать... ... но общей концепции в итоге не меняет
Alexander
Всем привет! можно как-то в shape сделать corner radius больше чем width конечной вью?
Глеб
эм…а как я его могу запустить при запуске программы и получать данные на любой активити? т.е. протянуть через все приложение запущенным
если разные активити - чисто формально, один процесс, одно приложение, то и синглтоном можно если это прям разные активити, разных юайев, процессов и приложений, то тогда уже bind сервис наверное
Himars
эм…а как я его могу запустить при запуске программы и получать данные на любой активити? т.е. протянуть через все приложение запущенным
Если хотите немного садомазо - регистрируете Application.ActivityLifecycleCallbacks который будет следить за состоянием всех активити в приложении и в нем же реализируете связку Handler И WorkerThread...
Глеб
Если хотите немного садомазо - регистрируете Application.ActivityLifecycleCallbacks который будет следить за состоянием всех активити в приложении и в нем же реализируете связку Handler И WorkerThread...
ну да 👍, пошаманить там с "счётчиком открытых/закрытых" и тд и ... работать будет.... как вариант.... хоть и ломом с топором - но будет
Himars
эм…а как я его могу запустить при запуске программы и получать данные на любой активити? т.е. протянуть через все приложение запущенным
Вот пример как можно реализовать счетчик открытых активити https://gist.github.com/freaksgit/e41c588abd0c97244d9b20ca101f4c5d
Глеб
Если хотите немного садомазо - регистрируете Application.ActivityLifecycleCallbacks который будет следить за состоянием всех активити в приложении и в нем же реализируете связку Handler И WorkerThread...
Ну вот поэтому, все таки все ж лучше иметь single-activity подход, есть чёткий однозначный "контейнер видимости UI".... если говороить о новом проекте
Roman
Вот пример как можно реализовать счетчик открытых активити https://gist.github.com/freaksgit/e41c588abd0c97244d9b20ca101f4c5d
я уже посмотрел как, спасибо но вариант костыльный, не? Может есть какое-то более красивое решение?
Глеб
я уже посмотрел как, спасибо но вариант костыльный, не? Может есть какое-то более красивое решение?
красивое - не иметь несколько активностей, без необходимости. а я так понимаю вы эти активности не экпортите как ACTION_VIEW, ACTION_SEND ит д другим апам
Himars
Ну вот поэтому, все таки все ж лучше иметь single-activity подход, есть чёткий однозначный "контейнер видимости UI".... если говороить о новом проекте
Single-Activity которая реализует 25 интерфейсов слушателей событий фрагментов. + какая-то своя логика + менюшки, тулбары ... Не будет сильно раздутой?
Глеб
Single-Activity которая реализует 25 интерфейсов слушателей событий фрагментов. + какая-то своя логика + менюшки, тулбары ... Не будет сильно раздутой?
это точка входа, а там уж ваша - архитектура - ваша ответственность это ж не значит, что если у большого приложения точка входа main(String... args) то весь код в этом методе и записан)
Глеб
тут фокус в том что активность - это "шов с осью", а там уж организуй код/состояния как хочешь аналогично ContentProvder - можно завести на каждую таблицу по провайдеру, но всё же рекомендуют "управляться внутри" резолвя uri's то же самое с активностью - резолвя входящие интенты
Глеб
И сервисы - то же можно по сервису на-команду... но зачем? бить код по классам - никто же не мешает, всё равно это и будет с multi-activity
Глеб
"25 интерфейсов слушателей событий фрагментов. + какая-то своя логика + менюшки, тулбары" - это всё сложность (комплексность) вашего апа оно всё равно будет в итоге размазано по активностям. Либо "всё-в-одной" и размазано по фрагментам. Не знаю.... по мне - вынести код в отд активность, это псевдо-упрощение, самообман и самоуспокоение, которое потом и вылазиит в вопросы ЖЦ, счётчиков и ComponentCallbacks... синглтоны
Ontoshgo
хоть у кого-то асистент заработал на рашкинском?
Martynenko
--
Jamal
есть возможность что бы ретрофит при парсинге не видел опр поле
Jamal
simplexml
No
simplexml
если поле не нужно убери просто из своего поджо
Jamal
если поле не нужно убери просто из своего поджо
поле нужно для Room, но не нужна для парсинга
Mike
о, проблема annotation-driven-разработки
Nikita
:D
No
поле нужно для Room, но не нужна для парсинга
https://stackoverflow.com/questions/10263429/using-simplexml-how-to-ignore-xml-elements-i-dont-have-in-my-object-class-when
Nikita
@Attribute(required=false)
Nikita
@Element(required=false)
Nikita
http://simple.sourceforge.net/download/stream/doc/tutorial/tutorial.php#start
Himars
поле нужно для Room, но не нужна для парсинга
Data mapping - хорошая практика когда вы разделяете сущности по слоям... Если используете Gson - можно поле сделать transient
Himars
мэпперы — тупые процедуры, однообразные, не переиспользуемые
по другому никак если хотите что-бы не было зависимости от сущностей базы данных в View слое..
Mike
по другому никак если хотите что-бы не было зависимости от сущностей базы данных в View слое..
если сущность умеет храниться в БД, view-слою это никак не мешает
Sviat
мэпперы — тупые процедуры, однообразные, не переиспользуемые
если проект построен на абстракции и независмых модулях. то мапить придется. у меня на каждую сущность 3 класса. один для вьюхи, второй для ретрофита, третий для рума.
Sviat
да, немного оверхед. но зато всё независимо друг от друга
Mike
да, немного оверхед. но зато всё независимо друг от друга
какой профит от этого? Стоит оно того?
Himars
просто оставлю это здесь https://overflow.buffer.com/2017/12/21/even-map-though-data-model-mapping-android-apps/
Sviat
какой профит от этого? Стоит оно того?
ну кроме разделения на независимые модули и всякое такое, это например - с сервера нам дата приходит в строке. а в базу мы пишем инт. когда достаем маппим в строку обратно. но это скорее плюшечка.
Himars
связь слоев может быть сломана только на их стыках.. В сущностях бд можеть быть больше полей чем в сущностях например ретрофита...
Himars
сменив БД на другую вы ничего не сломаете... Не придется лезть во все сущности приложения и вырезать от туда аннотации Room например и впиливать туда логику работы с Realm...
Sviat
плюшечка звучит как костылик, который можно реализовать тайпАдаптером
у нас маппинг лежит выше. в репозитории. локал сорс по умолчанию принимает лонг.
Himars
придётся лезть во все сущности БД, от этого ничего не меняется
но менее вероятность что вы что-то сломаете в других слоях
Mike
но менее вероятность что вы что-то сломаете в других слоях
для этого есть сильная система типов и тесты
Mike
тесты не всегда пишуться
так и стопицот сущностей не всегда пишутся)
Vitaly
Есть какой-нибудь спсоб запустить Service из Presenter без передачи контекста? Использую MVP с Moxy
Dug
Не юзать мвп
Himars
Не тот что выпустил гогль
Himars
а что с ним?
а там можно сервисы запускать?
Kanstantsin
гоголь же романы писал ? какие сервисы
Himars
Но Navigator (интерфейс) с набором методов по запуску Service-ов с AppContext не решает проблему если нужен сервис в фореграунде например...Или же нужно произвести биндинг...
Himars
а как вы абстрагируете в MVP навигацию между активити?
Himars
mvpView.navigateToSomeNewsActivity()?
« Rev
@android_ru   1367
Fwd »