AT
а с multidex были краши на самсунгах, см. http://stackoverflow.com/questions/29007309/class-cast-exception-to-same-class-on-android
Size: a a a
2017 January 30
AT
вообщем тут нужно нивелировать, либо multidex, либо исследовать и убирать проблемные девайсы
AB
предлагаю устроить профессионально-картельный сговор: перейти всем на минСдк 21, а если вас будут спрашивать знакомые PM/Начальники из других фирм - отвечать, что их специалисты все правильно сделали и по-другому никак)
AB
или объявить профсоюз))
А
и появятся кустари (умельцы-фрилансеры), которые скажут что они сумеют просапортить приложение и для старых девайсов.
AK
ну так большинство и так скажет что правильно сделали
AB
и появятся кустари (умельцы-фрилансеры), которые скажут что они сумеют просапортить приложение и для старых девайсов.
тогда нам еще инквизиция понадобится)
AK
провинившихся отправлять кодить под ios?
sm
провинившихся отправлять кодить под ios?
Ну это не наказание, наказание на foxpro, под msdos, поддерживать старый легаси код)
EM
так а модель как выглядить будет? или в презентере хранить отдельынй список чек/анчек?
можно хранить отдельный список
тут как вам удобнее будет
тут как вам удобнее будет
DB
можно хранить отдельный список
тут как вам удобнее будет
тут как вам удобнее будет
Просто вопрос имено в том как более Clean))
EM
если про Clean, то я бы использовал другую модель, в которой и учитывались эти чеки.
список этих моделей был бы и в адаптере, и в презентере
список этих моделей был бы и в адаптере, и в презентере
EM
к примеру работает с контактами, то была бы модель UIContactModel
EM
конечно же да, лучше не создавать отдельных списков
но тут от ситуации зависит
но тут от ситуации зависит
A
если про Clean, то я бы использовал другую модель, в которой и учитывались эти чеки.
список этих моделей был бы и в адаптере, и в презентере
список этих моделей был бы и в адаптере, и в презентере
Ссылку на один и тот же список?
EM
у меня к примеру для одной сущности существовало несколько моделей
например, сущность Контакт
с сервера получаем ContactModelNW, c БД - ContactEntity, Репозиторий выдает наверх уже, скажем, ContactModel, а Интерактор отдает для UI - UIContactModel
например, сущность Контакт
с сервера получаем ContactModelNW, c БД - ContactEntity, Репозиторий выдает наверх уже, скажем, ContactModel, а Интерактор отдает для UI - UIContactModel
S
получать ссылку на List в презентере через geter (в activity) это норм?
EM
да, моделей не мало, но это плата за максимальное разделение слоев
и в итоге окупается более простой поддержкой
и в итоге окупается более простой поддержкой
EM
Ссылку на один и тот же список?
нет
в адаптере и в презентере два списка, а не две ссылки на один
в адаптере и в презентере два списка, а не две ссылки на один
EM
получать ссылку на List в презентере через geter (в activity) это норм?
нет