Size: a a a

Android Architecture

2017 January 30

PS

Pavel Sukhoterin in Android Architecture
в Java можно указать так SimpleSubExpandableItem expandableItem = new SimpleSubExpandableItem();
в Kotlin приходится указывать вот так SimpleSubExpandableItem<Parent extends IItem & IExpandable, SubItem extends IItem & ISubItem>(), у меня так и не удалось нормально сделать так, чтобы работало
источник

PS

Pavel Sukhoterin in Android Architecture
если у кого-то получается, скиньте в личку, спасибо
источник

ИО

Игорь Озеркин in Android Architecture
А что тебе мешает реализовать под конкретные классы итемы?
источник

ИО

Игорь Озеркин in Android Architecture
Самому
источник

EM

Eugene Matsyuk in Android Architecture
Dmitry Berdnikov
Получается что при смене чек-свойства, мы меняем сразу два списка? просто не совсем понимаю зачем второй тогда если модель одинаковая? мы же может просто передать в банд список из адаптера
Поясню.
Я такой подход применял в Чате. Там была возможность выйти с экрана, то есть вьюшка убивалась, но принимать дальше входящие сообщения было неоходимо. В таком случае я оставлял весь стэк (презентер-интерактор-репозиторий). Когда пользователь подсоединялся обратно, я ему предоставлял актуальный список. Гонять список туда-сюда между слоями мне как-то не хотелось, да и чревато это. Поэтому был список в презентере и был в адаптере во вьюшке.
Если у вас просто пассивный список, то можно держать список в адаптере. Другой вопрос, как тогда обрабатывать переориентацию. Класть все в Бандл?
источник

DB

Dmitry Berdnikov in Android Architecture
Eugene Matsyuk
Поясню.
Я такой подход применял в Чате. Там была возможность выйти с экрана, то есть вьюшка убивалась, но принимать дальше входящие сообщения было неоходимо. В таком случае я оставлял весь стэк (презентер-интерактор-репозиторий). Когда пользователь подсоединялся обратно, я ему предоставлял актуальный список. Гонять список туда-сюда между слоями мне как-то не хотелось, да и чревато это. Поэтому был список в презентере и был в адаптере во вьюшке.
Если у вас просто пассивный список, то можно держать список в адаптере. Другой вопрос, как тогда обрабатывать переориентацию. Класть все в Бандл?
Вот и я пришел к этому, что вариантов не остается, может тогда в бд хранить уже юай модель?)
источник

DB

Dmitry Berdnikov in Android Architecture
И обновлять бд когда чек меняем
источник

A

Abripuit in Android Architecture
Eugene Matsyuk
Поясню.
Я такой подход применял в Чате. Там была возможность выйти с экрана, то есть вьюшка убивалась, но принимать дальше входящие сообщения было неоходимо. В таком случае я оставлял весь стэк (презентер-интерактор-репозиторий). Когда пользователь подсоединялся обратно, я ему предоставлял актуальный список. Гонять список туда-сюда между слоями мне как-то не хотелось, да и чревато это. Поэтому был список в презентере и был в адаптере во вьюшке.
Если у вас просто пассивный список, то можно держать список в адаптере. Другой вопрос, как тогда обрабатывать переориентацию. Класть все в Бандл?
А почему не хватило бы оставить в живых модел (имею ввиду интерактор)? Что стало причиной оставлять и презентер в живых?
источник

AB

Alexander Bilchuk in Android Architecture
Dmitry Berdnikov
Такой вопрос, допустим у нас есть список элементов, который потом отображается как список который может быть checkable. Состояние check/uncheck вы просто добавляете в сущность или делаете обертку, где сама сущность и ее состояние? И потом как обрабатываете при повороте? в ДБ вроде как сохраняется оригинальный список. или создаете два списка первый самих сущностей, второй состояний?
тут главный вопрос:  check/unchek чему служит: изменению модели, хранящейся в репозитории, или это больше UI-ная вещь (например, вы делаете игру-викторину с выбором вариантов ответа)?
источник

AB

Alexander Bilchuk in Android Architecture
где ответы - это какой-то список из репозитория, к которому чек/анчек по сути никак не относится
источник

DB

Dmitry Berdnikov in Android Architecture
Alexander Bilchuk
где ответы - это какой-то список из репозитория, к которому чек/анчек по сути никак не относится
Выбранный фильтр в каталоге, который потом собирается в запрос
источник

AB

Alexander Bilchuk in Android Architecture
я бы сделал FilterManager, который внутри себя бы хранил плоский список значений (или идентификаторов)
источник

AB

Alexander Bilchuk in Android Architecture
пускай хранит в SharedPreference - для поддержки переворота, я не вижу в этом ничего страшного)
источник

AB

Alexander Bilchuk in Android Architecture
или в bundle, если не сложно прокидывать в вашем конкретном случае
источник

AB

Alexander Bilchuk in Android Architecture
список то все-равно будет из примитивов
источник

DB

Dmitry Berdnikov in Android Architecture
Alexander Bilchuk
я бы сделал FilterManager, который внутри себя бы хранил плоский список значений (или идентификаторов)
Грубо говоря второй список состояния, где моделька из двух полей
источник

AB

Alexander Bilchuk in Android Architecture
Название фильтра и check/uncheck?
источник

DB

Dmitry Berdnikov in Android Architecture
Alexander Bilchuk
Название фильтра и check/uncheck?
Ага
источник

AB

Alexander Bilchuk in Android Architecture
а получится просто хранить название фильтра?)
источник

AB

Alexander Bilchuk in Android Architecture
типа если он есть - то чек
источник