Android + статический Sqlite

Ну если не хочешь рум. Пиши без него, в курсорах и скл запросах в виде строковых констант есть свой шарм. Курсор можно не закрывать, памяти нынче много, натечь за время работы приложения не успеет)

Поставь в манифесте запрет на пересоздание активности при повороте и выкинь лайфдату.

Запросы к базе можно из основного треда. Дроп пары кадров не сильно заметен. Сеть нельзя.

https://github.com/lisawray/groupie простой TreeView

И напиши название приложения, чтоб я его случайно не скачал.

И напиши название приложения, чтоб я его случайно не скачал.

не скачаешь,не переживай

ты просто скажи, для статики оно все вообще желательно или без него норм? В плане если нет изменения данных вообще - зачем LiveData? Я серьезно пытаюсь разобраться,когда бэк пишешь о ui-треде не думаешь

скл запросах в виде строковых констант

кстати в руме ж тоже так? ну, в плане ничего нормального типа жука я для ведроида не нашел, везде так или иначе стругаешь sql строчками

запрет на пересоздание активности при повороте

uh.

Видимо совет не айс?

Ну в руме работает автодополние и валидация - ошибки на этапе компиляции. Без него - на этапе выполнения. Ну и то что есть изначально для работы с голым склайтом не очень удобное.

типа жука

Не знаю про что это.
Всяких ормов под ведро как собак нерезанных. Просто рум вышел довольно удачным для мобильных нужд и остальные редко кто вспоминает.

Пересоздание активити происходит не только при смене ориентации экрана. Это как убрать «крестик» у окна приложения и надеяться, что оно никогда не закроется.

Лайф дата она, как следует из названия, про то что приложение имеет жизненный цикл, который внешний по отношению к своему коду и управлять ты им не можешь. И оно помогает не попадать в не те фазы этого цикла. И удобно прокидывает данные в основной поток. Изменяемые или нет там данные - перпендикулярно.

Ты из рума с тем же успехом можешь вместо LiveData<Items> возвращать Items. Оно просто выполнит запрос в основном потоке синхронно.

Если ты мегабайтами не ворочаешь, то как я писал, потерю пары кадров никто не заметит. Все так делали на более слабых мобилках и ведро доминирующая ос)

Пересоздание активности при изменении конфигурации не нужно в 99% приложений. Это не очень удачный дефолт. Отключив эту хрень можно меньше заморачиваться, не ловя креши слишком часто. Это типа не очень правильно. Но большинство приложений вообще лочит портретный режим ибо другого дизайна нет и никто не умер

Не знаю про что это

JOOq, имхо самая божественная ява-либа для работы с базой, прозрачная и без черной магии как в Hibernate

Просто рум вышел довольно удачным для мобильных нужд и остальные редко кто вспоминает

после жука писать чистый sql даже в аннотахе вызывает боль и слёзы. А отсутствие кодогенератора для entity это прям жара.

Ну в руме работает автодополние и валидация - ошибки на этапе компиляции

это плюс, да. просто оно сразу накладывает пачку абстракций, которые для меня как для бэкендера нифига не понятны. Ну, вернее понятны, но хз насколько они для мобилки и что важнее а на что можно забить.

Вот например Embedded+Relation - хз, но мне прям ппц стремно когда код начинает сам сколько-то там раз ходить в базу без явной на то инструкции. Или LiveData - аналогично. На бэке каждый такой поход ты считаешь ибо round-trip дорогой, а здесь база вроде как локальная, приоритеты скорее всего другие. Или зачем нужен ViewModel, это типа контроллер из MVC, или что это за зверь и почему нужна еще одна прослойка между логикой и репозиторием?

Вообще под ведроид последний раз писал кажется в 2012, когда 2.3 был, все очень сильно поменялось. Фрагменты, ресайклер-вью... Собственно сходу не могу понять - если есть иерархия, условно классы->типы->окно типа, то первый переход от одного списка к другому это новая Activity или что это? Раньше была Activity, но теперь походу фрагмент.

Лайф дата она, как следует из названия, про то что приложение имеет жизненный цикл

а,блин, тогда ясно. Они б написали это прямым текстом в примерах… А то по мне LiveData - это Observer, фигня типа websocket и вот это все.

Ты из рума с тем же успехом можешь вместо LiveData возвращать Items. Оно просто выполнит запрос в основном потоке синхронно

не даст же, говорит в ui-треде в базу только негодяи ходят. Видимо правду говорит.

Если ты мегабайтами не ворочаешь, то как я писал, потерю пары кадров никто не заметит

хз, база на 15 метров. По мне все что меньше 50 гиг это мелочь. Но опять же - телефон, хз.

Но большинство приложений вообще лочит портретный режим ибо другого дизайна нет и никто не умер

кстати вот тут как владелец хромбука хотел бы сделать возможность переключения ориентации, по типу того что в доке про фрагменты в самом начале

Остальные случаи становятся видны в статистике крешей от 1000 установок приложения. Тут хотят абы работало.

Это как убрать «крестик» у окна приложения и надеяться, что оно никогда не закроется

в андроиде ж вроде нельзя этим управлять?

Тут хотят абы работало.

не, погоди, я хочу понять как сделать хорошо, а не чтоб работало. Чтоб работало наверно можно просто пол-гитхаба слить либами и молиться чтоб все было круто

Всё ещё можно писать в стиле 2012) обратную совместимость не ломали.

Есть https://cashapp.github.io/sqldelight/ с подобной идеологией кто-то прям JOOq https://m.habr.com/ru/post/422303/

ViewModel не смотря на название просто класс переживающий измение конфигурации. Использовать его можно как угодно. Канонически там всякие запросы в сеть или бд, которые не должны помереть вместе с фрагментами/активностями.

Раньше была Activity, но теперь походу фрагмент.

Ещё не запрещено писать по активности на экран, хотя и мода на одну активность и экраны в виде фрагментов. И того и другого есть свои преимущества.

большинство приложений вообще лочит портретный режим ибо другого дизайна нет

4.2 немношк

Просто кривая аналогия.

Пользователь изменит размер шрифта в системных настройках - и у тебя на открытых экранах всё поедет. Или язык изменит. Или подключит док с клавиатурой, а у тебя экранная не исчезнет. Кейсы редкие, но их весьма много.

Вообще, согласен с предыдущим пони - обновление конфигурации в андроиде сделано весьма по-дурацки и является скорее неприятным артефактом старого апи, чем реально необходимой вещью. Но лучше этот контракт исполнять, чтобы не отлавливать 100500 мелких косяков на 100500 устройствах.

Всё ещё можно писать в стиле 2012

Ну так и правда можно и до курсора, и до копирования байт-потока уйти. Не, оно хорошо на больших объёмах, но кажется за 8 лет должны были появиться более логичные вещи.

мода на одну активность и экраны в виде фрагментов. 

А есть где-нибудь пример без видео на ютубе, текстовый?

ViewModel не смотря на название просто класс переживающий измение конфигурации. 

Ок, стало на 20% понятнее, спасибо. Буду читать про жизненный цикл

https://m.habr.com/ru/post/422303/

Там очень много ограничений. Я пытаюсь юзать минимальный API 16, а жук имеет внутри кучу фич из java 8, которую андроид до 24 версии не может. Сначала пытался привычно взять жук, но оно просто отказывается собираться к сожалению. Плюс работа с кодогенерацией довольно странная, словно её для андроидных дефолтных тасок никто не ожидает.

Но лучше этот контракт исполнять, чтобы не отлавливать 100500 мелких косяков на 100500 устройствах

Учту, спасибо. Особенно в свете того что для отладки у меня всего 2 девайса, а в эмулятор мой комп процом не вышел

хотел бы сделать возможность переключения ориентации,

И вот ты попадаешь в тот самый 1%. как говориться многие желания, многие печали) начинай тогда курить жизненный цикл компонентов

не даст же, говорит в ui-треде в базу только негодяи ходят.

Странно, когда я раньше рум тыкал то давало. Возможно добавили проверку в библиотеку. Ибо я не помню чтоб был системный запрет как на операции с сетью

А то по мне LiveData - это Observer, фигня типа websocket и вот это все.

Он и есть обсервер, только более замороченный. Только он мониторит не только изменение данных, а и в каком состоянии подпищик находиться. Оно гарантирует что ты не обратишься со своими данными в активность убитую системой.

хз, база на 15 метров

Возможно стоит и заморочиться потоком на ио. А то не отвечающие приложения нынче просто умирают.

Возможно стоит и заморочиться потоком на ио.

Чтение из базы быстрое, индексы расставить не проблема, фулскана там нет нигде. По int-ключу достать 20 строк из 30 тыс не должно вызывать сильной нагрузки.

Оно гарантирует что ты не обратишься со своими данными в активность убитую системой.

А, понял, то есть оно в обе стороны смотрит, спасибо.

И вот ты попадаешь в тот самый 1%. как говориться многие желания, многие печали

Чёт звучит как боль

Это смотря что понимать под большинством. У большинства установленных типичным пользователем все ок, там куча ресурсов у владельцев приложения и они заморачиваются, а у всякого среднего сегмента, где экономят на всем(установок у них не много, но самих приложений в маркете вагон) лочат, чтоб не думать как оно будет выглядеть. Причем прям в ТЗ сие прописывают.

Чёт звучит как боль

Разработка под ведро вообще боль)

Одна из немногих существующих ос с множеством точек входа в приложение. Зоопарк по багам, что по версиям(ибо не обновляют устройства), что по производителем(у каждого свои причуды). Куча плохих решений в дизайне сдк, Как прошлых так и текущих (многие правда следуют из прошлых, но жизнь не облегчает)

Одно из таких решений - замороченный жизненный цикл компонентов и отсутствие изкоробочных решений/хороших практик как удобно решать типичные задачи с привязкой в этом окружении. Что порождает дополнительную сложность.

решение что 2012 года, что сегодня, что отписка от различных обсерверов или отмена операций когда компонет дохнет. С потерей результата или сохранием его в чем-то, что живет дольше чем компонент андроида. В 2012 это были пролетарские сингтоны, асинк таски и самописные обсерверы. Нынче есть модные ViewModel, LiveData и всякие корутины с рх джавой. Но суть осталось тойже.

Если ты хочешь корректно жить с пересоздаением компонент при изменение конфигурации, надо заморачиватся чтоб код корректно обрабатывал жизненный цикл. А подмена layout экрана в портретном режиме просто реализуется именно пересозданием активности.

мода на одну активность и экраны в виде фрагментов.

А есть где-нибудь пример без видео на ютубе, текстовый?

Ну тут есть несколько проблемок. Гугл под это дело написала либу навигации, а с ней тоже надо разбираться. Там используются фрагменты. Фрагменты создабт столько же проблем сколько и решают. И разработка сильно адаптировала котлин.

https://github.com/abbas-oveissi/SingleAcitvityPattern из быстро найденного что использует фрагменты напрямую. Можешь что-то похожее на джаве поискать. я бы не заморачивался и писал несколько активностей.

И почему нельзя запрос в UI треде

если вы задаете такие вопросы, то значит вы не знаете как работает андроид, поэтому для начала надо прочитать как он работает, документация хорошая, там все подробно описано.

Приложение работает со статической sqlite, не слишком большой, read-only В плане ну на кой мне LiveData, она ж иммутабельная?

если у вас ридонли что есть по сути синоним иммутабельности +-, то в чем ваше противоречие?

Ну, я из F-Droid'a приложухи таскаю, и злонамеренно фиксирует ориентацию только всратый DroidCam.

если вы задаете такие вопросы, то значит вы не знаете как работает андроид

Все так, оттого и вопрос. Мобилки для меня тёмный лес

если у вас ридонли что есть по сути синоним иммутабельности +-, то в чем ваше противоречие?

Выше объяснили что live - это про life cycle в том числе

это про life cycle в том числе

а это еще раз говорит о том что вы не знаете как работает нашлепка на минимальное линукс окружение которая и есть этот андроид. Опять в документации и про жизненный цикл приложения доходчиво написано, из чего он состоит и как работает, как происходит переход между активностями что происходит с теми что уходят в фон и т.д. и т.п. Просто почитайте документацию и все станет ясно.

а это еще раз говорит о том что вы не знаете как работает андроид

Кажется это уже обсудили, но спасибо за напоминание

Ну как бы переписывать документацию на лор просто потому что вам ее лень читать это такое себе. Вообще вы можете в принципе просто писать на С под линукс с минимальным вкраплением джава кода чтобы создать активность и тогда можно будет вообще не разбираться в системе, но и пользоваться тем что предоставляет нашлепка в виде андроида тоже скорее всего не выйдет. Тут либо так либо эдак.

ViewModel не смотря на название просто класс переживающий измение конфигурации

А если я например знаю что моя activity конечная (в плане из неё уйти только назад, данные не переиспользуются, проще заново получить), её лучше все равно через ViewModel заполнять или напрямую из репа?

Вообще стало сильно понятнее, спасибо

ViewModel нужна если хочется чтобы запрос к бд завершился и пересозданный компонент просто получил готовый результат прошлого запроса сохраненный во вью модели.

Если как бы такой задачи не стоит, то можно ViewModel и не использовать. Не забыть только грохть запрос/отписаться от обсервера при дестрое экрана, если что самодельное используется. Ну или лайф дата сама это обработает есть используется она.

ViewModel и ей подобное для тех кому было обидно, что надо заново например по сети данные тянуть, если вдруг в процессе пользователь экран перевернул и надо грохать запрос и запускать его заново в новом экземпляре экрана. Кого не парило, они по сей день запрос заново запускают)

если вдруг в процессе пользователь экран перевернул и надо грохать запрос

а, ну, тогда в целом в рамках локального sqlite с выборкой по int-ключу на вид не очень страшно