index0h, спасибо)
Пока пришел к использованию STI AbstractUser <= {Admin, Customer, Employee}. Правда, уникальность, скажем, username'ов и email'ов у Admin приходится обрабатывать на уровне кода, а не БД.
Авторизация через разные endpoint'ы, Уровни доступа через роли + привилегии.
index0h, итак. ко мне ломится Customer через приложение для Employee. Да, я знаю, его номер, но не знаю откуда он и думаю, что он ломится через приложение для Customer. Тут как поступить?
index0h, сложность в том, как это все вместе соединить. Возможно, надуманная. Не могу в голове уложить, как соединить все это.
Admin - авторизация через username + password
Employee, Customer - авторизация через phone + sms-code
Как определить, когда логиниться Employee, а когда Customer, если они имеют общую модель User(id, phone. name)?
Если все три авторизации происходят через один метод, то админа можно определить по параметрам username + password, а вот с Employee и Customer - хз, как быть. На ум приходят варианты:
1. Разные методы
2. Прикладывать API key с определенными правами - один для Employee, другой для Customer, третий для Admin.
index0h, а дальше появляется куча других осложнений:
1. У Employee и Customer есть история заказов. И у каждого она своя.
2. Вход админа происходит через веб, Employee через одно приложение, Customer - через другое.
Moxy - кул, но он делает очень много работы под капотом. Не смотря на то, что авторы на всех конференциях рассказывают про то, что там под капотом, не хотелось бы, чтобы подобные задачи решала библиотека.
Денис Загаевский: столкнулся с другой забавной проблемой:
переопределил `GridLayoutManager#getDecoratedMeasuredHeight(View)`, чтобы тот устанавливал отношение 16:9 для всех вьюх
результат: меняется граница, а внутренние вьюхи выпадают за пределы и обрезаются
Суть такая была: в LinearLayout пихнуть LinearLayout и какой-то ещё блок, который всегда будет снизу, и при необходимости пихнуть вьюху - пихать во внутренний LinearLayout
а говорить сейчас, как изменится жизнь разработчика под эти платформы через N лет - ошибка, я считаю
потому что все оч быстро меняется, стэк может и за пару месяцев устареть
Sergey Vashchenko:
Realm - отличная вещь для работы с БД, и на Android, и на iOS есть
Rx - в целом парадигма идентична везде, разные лишь языки. если Kotlin использовать будешь, то почти не заметишь разницы
Главная сложность будет в архитектурных паттернах (MVP (иногда Reactive MVP), CleanArchitcture для Android и MVVM, VIPER для iOS) и в особенностях самих ОС (лайфсайкл там и прочий шлак)
Сейчас участвую в достаточно проблемном с точки зрения реализации проекте, пишу под Android, параллельно этот проект пишется под iOS, и могу сказать, что проблемы мы решаем разного рода
goodtimes922:
во-первых, очень странно передаешь аргументы во фрагмент
во-вторых, не очень понятна логика приложения
по-хорошему, нажатие на пункт NavDrawer'a должно чистить backstack и класть новый фрагмент
а где живет код, который добавляет `FragmentUser` - я вообще не понял =(
Пока пришел к использованию STI AbstractUser <= {Admin, Customer, Employee}. Правда, уникальность, скажем, username'ов и email'ов у Admin приходится обрабатывать на уровне кода, а не БД.
Авторизация через разные endpoint'ы, Уровни доступа через роли + привилегии.