Соглашусь с одним из комментаторов, не хватает в этой иерархии контроллеров и хранилищ данных. Книги и опросы - это просто сущности с данными, отвечающими за какой-то один опрос или книгу. Хранилище имеет CRUD-методы, а контроллер отвечает за то, чтобы получить команду доступа, может быть проверить права доступа, обратиться к хранилищу и вернуть результат. Можно 6азывать это даже не контроллером, а пользовательским сценарием (так называемый UseCase).
Модератора и пользователя в такой схеме сложно будет разграничивать на уровне доступов. Я бы тоже свёл их в одну сущность с полем, определяющим доступ. И на уровне его уже на разных этапах решать какие действия можно выполнять.
Полностью поддерживаю. Fragment стоит рассматривать как отдельную витрину какого-то функционала. Тогда код будет простым и его легко будет поддерживать.
В большинстве случаев, вакансия будет подразумевать знание Java. А также Kotlin. Изучать придется оба языка. Я бы рекомендовал начать с Java, а потом сразу Kotlin. Как уже сказали, большинство библиотек на Java. Также большинство проектов, куда требуются разработчики, тоже ещё содержат много кода на Java.
Kotlin после Java изучается достаточно легко и быстро. Хотя, конечно, в нём есть свои особенности.
В то же время, классы бизнес-логики работают в однопоточном режиме и их легко тестировать. Многопоточность реализуется уже на уровне презентера или на позорный случай в активити.
Поясню немного код, который вставил: если мы находимся в состоянии SHOWING_WELCOME, то при поступлении события cardPresent надо перейти в состояние WAITING_FOR_PIN, если пришло событие cancel, то переходим в состояние RETURNING_CARD. Если мы в состоянии WAITING_FOR_PIN, то при поступлении события pinProvided переходим к .... . Если мы в состоянии RETURNING_CARD и пришло событие cardExtracted, то возвращаемся к SHOWING_WELCOME.
Стейт-машина - это другой термин для конечных автоматов: есть состояние как вершины графа, и есть события как пути между графами. В данной библиотеке ViewState похож на стейт-машину, но реализован на очень низком уровне: для каждого вью придется создавать отдельный класс со своим списком состояний и переходов, которые обрабатываются методом с кучей if-ов.
Это не идёт ни в какое сравнение с ООП реализацией из той библиотеки, про которую писал я. Самый огромный плюс этой библиотеки в том, что переходы описываются очень наглядно и в одном месте:
Если в результате изменений в проекте надо изменить порядок экранов, добавить экран, то достаточно в вышеприведенном описании подправить несколько строк. Ну, и если нужен новый экран, то просто отнаследоваться от базового класса, который имеет слушатели к стейт-машине.
Но данный ViewState может быть уместным в рамках данного вопроса, как обработчик состояния одной единственной активити или фрагмента. Но опять же отсутствие ООП в описании состояний может породить ужасный список условий, если мы будем иметь более-менее сложное поведение.
И вообще, не советую вам сливать условие в одну строку. Через месяц-два вернувшись к коду будет сложно понять, что делает это условие. А первый вариант прост для понимания.
Мне нравится именно в этой библиотеке то, что одно и то же событие может приводить в разные состояния в зависимости от того, в каком состоянии сейчас находится машина. Я сталкивался с библиотеками в которых событие всегда приводит к одному состоянию. И мне это не очень понравилось, так как теряется гибкость. Ну и очень удобно в этой библиотеке описать Flow, иметь несколько Flow и переключаться между ними. И не менее удобно то, что можно стартануть машину в любое промежуточное состояние. Т.е. отработать проверку какого-то условия и решить на старте в какое состояние нам нужно перевести машину. Это как раз из вопроса о том, как сохранять/восстанавливать состояния.
А чему радоваться то? Столько лет потеряно зря. Но сейчас возможностей больше и есть дефицит в разработчиках, так что шанс трудоустроиться намного выше.
Программно управлять отображение шторки можно, а вот выезд до середины можете дописать самостоятельно, ведь код открыт. Можете на GitHub поискать проекты по словосочетанию SlidingUpPanel. Там много таких проектов с разным функционалом.
RussleKelly: мне кажется ваш друг сильно преувеличивает. Но я на зарплату не жаловался. Сами же курсы так себе. Без постоянного самообразования расти не получится. И учить надо не сколько саму 1С, а сколько базу: как красиво и эффективно писать код, UI дизайн и т.п. В 1С этому никто не учит и последствия от этого плачевные.
Модератора и пользователя в такой схеме сложно будет разграничивать на уровне доступов. Я бы тоже свёл их в одну сущность с полем, определяющим доступ. И на уровне его уже на разных этапах решать какие действия можно выполнять.