На данный момент работаю над приложением, в котором больше 20 таблиц, некоторые из них имеют отношения many-to-many, между некоторыми — несколько many-to-many. Для того, чтобы все нормально выглядело, достаточно было написать свой QueryBuilder на 500-600 строк, который делает sql-запросы выглядеть нормально. Для того, чтобы в Вашем приложении не было каши — следует не использовать сторонние тулзы, а писать структурированный код, который позволит читающему его нормально разобраться, а не сломать глаза, мозг и прострелить себе обе ноги.
Почему в книгах и в статьях, посвященных программированию под Android, не описываются инструменты для проектирования архитектуры базы данных и какие-нибудь паттерны для работы с базами данных на этапе их создания я честно говоря не знаю
Чаще всего потому, что вычислительная мощность мобильных девайсов сильно уступает мощности компьютеров, потому, смысла в проектировании сложной БД особо не возникает, посколько это может оказать негативный эффект на перформанс.
Не совсем понятно, в какую сторону пойдет Ваш шаблон дальше, если это будет близко к command-ориентированному подходу, то он плохо приспособлен к жизни в больших проектах. Самым явным недостатком, пожалуй, является факт неявности источника данных и рецепиентов сообщений (а упоминание Intent в аббревиатуре намекает на то, что проект будет построен на основе как-раз таки Intent-общения). Единственным плюсом будет простота вынесения логики в сервисы, что позволит спокойно существовать процессам приложения после смерти Application процесса.
Жду продолжения, так как Вы меня заинтересовали :)
Могу лишь предложить Вам посмотреть не так давно появившийся доклад Yigit Boyar-а о чистой архитектуре в андроиде с современными фреймворками. Линки на запись доклада и на исходники проекта. Это конечно не совсем то, что Вы просили, но, думаю, что в плане прикладном должно Вас удовлетворить.
Спасибо за статью. На данный момент попробовал внедрить AccountManager в свой проект, в связи с чем возникли несколько вопросов: можно ли каким-либо образом прослушивать изменения токенов для конкретного аккаунта? Можно ли прослушивать изменения токенов конкретного типа для аккаунта? Заранее спасибо.
Для этого достаточно объявить два компонента, описанных с помощью AIDL. Первый — тип передаваемых данных (по факту — простая линковка на .java класс, который будет передаваться, обязательно должен расширять Parcelable), второй — описание коллбэка. Далее будет сгенерирован класс, соответствующий описанному посредством AIDL коллбэку, с которым уже просто взаимодействовать. Много сложнее вопрос, как мне кажется, с реализацией аналогичного общения с оповещением из сервиса конкретных рецепиентов, в силу сложности контролирования их жц
Очень жду Ваших статей по RxJava2, если они планируются. Плюс было бы интересно посмотреть на более продвинутые use-case-ы реактивного расширения, возможно, в отдельных статьях.
Пример — пагинация списка, здесь можно посмотреть мою реализацию с использованием RxJava, а также еще пару кейсов использования реактивного расширения в Android: https://gitlab.com/i.komarov/my-feed
И с Вами также смею не согласиться, rx далеко не простой инструмент, многие по нескольку лет осваивают его. Как минимум понимание проблемы упомянутых Ваши Subject-ов доходит не сразу до человека, начавшего свой «реактивный» путь
Смею с Вами не согласиться — RxJava ( а в особенности — вторая ветка ) является очень даже глубокой темой для обсуждения, другое дело, что таких триалов как у автора в сети, равно как и на хабре, тысячи, а вот хороших комплексных юз-кейсов в продашне как раз-таки не хватает.
Мне в свое время помогло решение кэшировать всю информацию, выставить политику обновлений по таймстампу и использовать where-условия для извлечения посредством использования orm данных с нужной локализацией. Просто и со вкусом. А, простите, если у Вас не динамические ресурсы, то проще использовать квалификаторы директорий.
> Искренне вам завидую. За пять лет так и не получил ни одного сколь-нибудь чёткого задания.
Значит Вы не смогли заинтересовать научных руководителей. По своему опыту сужу, что если дать свою тему и заинтересовать человека, то он даст волю фантазии и превратит вашу курсовую работу в мини-стартап: напишет тз, будет сам настаивать на консультациях, делиться опытом, да и просто общаться с Вами на околопрофессиональные темы.
В противном же случае, конечно для маленьких и (или) неинтересных курсовых никто Вам тз не составит.
На тот момент заказчик хотел, чтобы все было именно так. Я то конечно понимаю, но вот заказчику это объяснить не получалось. В общем, пришлось сделать так, как сделали. А так по идее я бы сделал некий механизм завязанный на первичных ключах, например, генерацию токена по device_model и user_id. Таким образом взломщику пришлось бы хотя-бы подольше ломать все это, и, возможно, ему бы просто надоело.
Был как-то опыт создания такого приложения. Грубо говоря, оно являлось интерфейсом для БД. Суть была в том, что клиент грузил шифрованную БД и в удобном виде представлял ее пользователю. Приложение было для фармакологической компании, и соответственно бдшка содержала всю инфу по препаратам. Так что да, такие приложения есть.
Чаще всего потому, что вычислительная мощность мобильных девайсов сильно уступает мощности компьютеров, потому, смысла в проектировании сложной БД особо не возникает, посколько это может оказать негативный эффект на перформанс.
Жду продолжения, так как Вы меня заинтересовали :)
Значит Вы не смогли заинтересовать научных руководителей. По своему опыту сужу, что если дать свою тему и заинтересовать человека, то он даст волю фантазии и превратит вашу курсовую работу в мини-стартап: напишет тз, будет сам настаивать на консультациях, делиться опытом, да и просто общаться с Вами на околопрофессиональные темы.
В противном же случае, конечно для маленьких и (или) неинтересных курсовых никто Вам тз не составит.