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

Видимо я плохо сформулировал суть. Раз возникли такие вопросы))) Приложение сохраняет пароли пользователя и если он докажет, что это он(пин-код, отпечаток пальца, фэйсид) то может его посмотреть

Хм, а где приложение возьмёт ключ шифрования?

Модно дать пользователю его ввести самому)))

и где держать его?)

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

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

Храни на сервере как хэш, а у него локально алгоритмом которое расшифруется (AES, DES)

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

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

Не все же современные методы шифрования есть на старых мобилках?

Храни на сервере как хэш, а у него локально алгоритмом которое расшифруется (AES, DES)

надо смотреть список

Можно пример? Или просто пнуть меня названием, а я сам буду серчить

Напиши свой AES алгоритм, использую как ключ данные телефона и т.д. которые тебе неизвестно

А если пользователь сменит телефон?)))

Что за приложение такое 😂😂

Или ты предлагаешь при старте приложения выкинуть попап с сообщением: если вы смените телефон, то ваши пароли пойдут по ****

Забыл мастер-ключ - сорян, сиди без пасов

Ну как-то не круто)))

Вход через гугл аккаунт не работает в версии из маркета(с приложения данные не отправляются на сервер, скорее всего данные не приходят от гугл), хотя если установить апк(который заливался в маркет) - вход работает. Что может быть?

"Вам шашечки или ехать?"

и где держать его?)

Ребят, есть ресайклер в котором могут быть список двох разных типов Ентити 1 допустим и ентити 2 Нужно отображать одни либо вторые итемы в зависимости от значения выбранного toggle buttona Рассматриваю такие варианты, подскажите какой лучше 1) Два адаптера для ресайклера, менять их в зависимости от тоггл батона 2) Два ресайклера у каждого свой адаптер, менять им видимость ресайклерам в зависимости от тогл батона

Ребят, есть ресайклер в котором могут быть список двох разных типов Ентити 1 допустим и ентити 2 Нужно отображать одни либо вторые итемы в зависимости от значения выбранного toggle buttona Рассматриваю такие варианты, подскажите какой лучше 1) Два адаптера для ресайклера, менять их в зависимости от тоггл батона 2) Два ресайклера у каждого свой адаптер, менять им видимость ресайклерам в зависимости от тогл батона

2 итем Вью?

Не хочу создавать общую ентити для айтемов

Создай пустой интерфейс

Можно поподробней? Не встречал данного подхода

Создаёшь интерфейс с пустым телом от него наследуешь свои кому классы и в зависимости от типа выводишь разные итем вью

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

Создаёшь интерфейс с пустым телом от него наследуешь свои кому классы и в зависимости от типа выводишь разные итем вью

Фу-фу-фу!

главный мемес забыл

Ну понятнее не стало))

Маркер-инерфейс — всё равно, что Any. Не объявляют никакого контракта, не помогают типобезопасности.

Что-то у меня пока для реализации Adapter Delegates без кастинга в голову приходит только визитор и все то огромное кол-во кода, которое при этом придется притащить 🤔

* sealed class * держать рядом со списком элементов список делегатов

а) sealed - да, но проверять на тип нужно б) не до конца понял, можешь подробнее? не вкладывать же делегаты прямо в модельку

а) нужно, но это безопасно б) один лист с айтемами, второй — с делегатами, и все позиционно друг другу соответствуют

а) да, но все еще не идеально) помнится, ты сам это критиковал б) не тяжко ли будет для устройства?

б) неа Там есть анчекед каст, да, но по факту всё безопасно и не мешает * использовать разные делегаты с айтемами одного типа * использовать дженеричные делегаты

Примерно понял. А какие недостатки у визитора кроме кол-ва кода?

Визитор же требует заворачивания данных? Или визит() объявляется в самих «модельках»? Теряется возможность показывать данные одного типа по-разному. Добавляются классы и виртуальные вызовы.

model.visit(ModelVisitor), где ModelVisitor может быть как (Model) -> Unit, так и быть кучкой методов, которые имплементить ViewHolder, а-ля setModelTitle и т.д. Тут проблема лишь в том, что в таком случае дженерик класс RV должен иметь быть собирающим для всех типов находящихся внутри элементов (может, тут абстрактный класс, который все их имплементит, прокатит? плохо, плохо, плохо, конечно) > Теряется возможность показывать данные одного типа по-разному. А вот с этим не оч согласен 🤔

А можно пример? Если не согласен, значит, я не понял.

https://gist.github.com/adolgiy/6a26ca03be5f2b33e17b56560409b73c Накидал основные мысли. - Показывать по-разному данные можно в ModelHolder#visit(Model) (закралась, что ты имел в виду «совсем по-разному» и в разных ViewHolder’ах по типу) - Пока не получится передать параметры из адаптера в холдер (не придумалось) - Не придумал, как сделать onCreateViewHolder пока. Возможно, если совместить идею делегата от Дорфмана (где они в списке лежали и по типу доставались), то получится реализовать создание. Если же сделать delegate#visit(holder, position, items), которые прокинет visit в ModelHolder#visit, то получится комбинация и без кастинга вообще. Только дабл диспатч и куча кода.

https://gist.github.com/adolgiy/6a26ca03be5f2b33e17b56560409b73c Накидал основные мысли. - Показывать по-разному данные можно в ModelHolder#visit(Model) (закралась, что ты имел в виду «совсем по-разному» и в разных ViewHolder’ах по типу) - Пока не получится передать параметры из адаптера в холдер (не придумалось) - Не придумал, как сделать onCreateViewHolder пока. Возможно, если совместить идею делегата от Дорфмана (где они в списке лежали и по типу доставались), то получится реализовать создание. Если же сделать delegate#visit(holder, position, items), которые прокинет visit в ModelHolder#visit, то получится комбинация и без кастинга вообще. Только дабл диспатч и куча кода.

https://gist.github.com/adolgiy/6a26ca03be5f2b33e17b56560409b73c Накидал основные мысли. - Показывать по-разному данные можно в ModelHolder#visit(Model) (закралась, что ты имел в виду «совсем по-разному» и в разных ViewHolder’ах по типу) - Пока не получится передать параметры из адаптера в холдер (не придумалось) - Не придумал, как сделать onCreateViewHolder пока. Возможно, если совместить идею делегата от Дорфмана (где они в списке лежали и по типу доставались), то получится реализовать создание. Если же сделать delegate#visit(holder, position, items), которые прокинет visit в ModelHolder#visit, то получится комбинация и без кастинга вообще. Только дабл диспатч и куча кода.

Что-то кастинг уже не кажется таким злом 🤔

Что-то кастинг уже не кажется таким злом 🤔

Да, это проблема Visitor в целом. Плюс тут связано все слишком. AbsModelViewHolder знает о всех типах, которые его наследники могут отображать.