Can't find reason for this exception to occur. Only inner Android calls without calls being made from project source code. Can someone provide a suggestion? Android 7 affected only

Creating new loopers for Handler?

Creating new loopers for Handler?

No calls to looper at all in project

Otherwise – other devices would be affected too. That's why I'm asking.

No calls to looper at all in project

And no handlers?

And no handlers?

handler threads, you mean? No, none

handler threads, you mean? No, none

also simple Handler

handler threads, you mean? No, none

Show the code

RxAndroidPlugins for async main thread only. May this be the case?

No calls to looper at all in project

check library calls

до чего лень раскладку переключать ужас )

also simple Handler

None of them too. Will check libraries and write back in several minutes.

если строить переиспользуемые, многоразовые компоненты, то надо. Ну гугл об этом, понятное дело, не думает.

IMediaItem, например

А что не так?

гугл нельзя считать за одну целостную компанию, которая может «париться» или «не париться» по какому-либо поводу.

А что не так?

дебильный префикс, который означает только одно: неспособность к именованию сущностей

когда разрастется за неймингом сильно следить придется

Как раз таки, твой подход ужасен тем, что через месяц вернувшись к такому проекту, ты не поймешь. Какой класс за какой экран отвечает. Чем то напоминает проекты, когда тупо все в одном пакете юзали

Как раз таки, твой подход ужасен тем, что через месяц вернувшись к такому проекту, ты не поймешь. Какой класс за какой экран отвечает. Чем то напоминает проекты, когда тупо все в одном пакете юзали

Не убедительно

May the following two calls be the problem in my case? Just found out that only one needed. val asyncMainScheduler = AndroidSchedulers.from(Looper.getMainLooper(), true) RxAndroidPlugins.setInitMainThreadSchedulerHandler { asyncMainScheduler } RxAndroidPlugins.setMainThreadSchedulerHandler { asyncMainScheduler }

Как раз таки, твой подход ужасен тем, что через месяц вернувшись к такому проекту, ты не поймешь. Какой класс за какой экран отвечает. Чем то напоминает проекты, когда тупо все в одном пакете юзали

ты сейчас про проект, в котором, судя по скрину, все разбито на независимые фичи?

кек

Эх, почему почти все андроид разработчики такие ворчливые?

Как раз таки, твой подход ужасен тем, что через месяц вернувшись к такому проекту, ты не поймешь. Какой класс за какой экран отвечает. Чем то напоминает проекты, когда тупо все в одном пакете юзали

да, в 3 файлах куда сложнее запутаться внутри модуля чем в 33 в ui-модуле )

дебильный префикс, который означает только одно: неспособность к именованию сущностей

Покажи свой проект, профессор

щяс мы там найдем дебильные префиксы

Как раз таки, твой подход ужасен тем, что через месяц вернувшись к такому проекту, ты не поймешь. Какой класс за какой экран отвечает. Чем то напоминает проекты, когда тупо все в одном пакете юзали

есть internal модификатор для классов в хмл есть public параметр который закрывает ресурсы

у него NDA))

инкапсуляция такая что в апп-модуле даже не увидишь их

Эх, почему почти все андроид разработчики такие ворчливые?

ты так говоришь будто бы сам не андроид разработчик

Не убедительно

Но это факт, сложно орентироваться в таком проекте

ты так говоришь будто бы сам не андроид разработчик

Ну окей, почти все андроид разработчики.😂

Но это факт, сложно орентироваться в таком проекте

Для кого именно? Мне кажется многим здесь по нраву такой подоход

Покажи свой проект, профессор

Я тебе конструктив, а ты огрызаешься. За 6 лет опыта мог бы и научиться общаться.

Эх, почему почти все андроид разработчики такие ворчливые?

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

Но это факт, сложно орентироваться в таком проекте

компас дать? )

Я тебе конструктив, а ты огрызаешься. За 6 лет опыта мог бы и научиться общаться.

Мне факты нужны. Без фактов никакого спора не может быть

Мне факты нужны. Без фактов никакого спора не может быть

Какие тут могут быть факты? То, что мы обсуждаем, предельно субъективно.

Но это факт, сложно орентироваться в таком проекте

Это шутка? Я когда увидел как у человека все удобно разбито прямо позавидовал что ему несложно найти нужные файлы...

компас дать? )

вообще чётенько всё

компас дать? )

еще четче было бы помодульно разбить все

еще четче было бы помодульно разбить все

выше листай там помодульно скрин уже есть

вообще чётенько всё

Ага, когда over9000 файлов

Да у меня обычный способ иерархии

Норм, только презентеры должны быть отделены. А так норм. И про adapters не понял, что там?

Ага, когда over9000 файлов

так в этом и суть ООП - выделять отдельные сущности по максимуму, нет?)

Норм, только презентеры должны быть отделены. А так норм. И про adapters не понял, что там?

а зачем их отделять?)

если строить переиспользуемые, многоразовые компоненты, то надо. Ну гугл об этом, понятное дело, не думает.

Переиспользовать ливдату? Где, зачем?

а зачем их отделять?)

Для читаемости.

Переиспользовать ливдату? Где, зачем?

Переиспользовать куски логики.

Для читаемости.

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

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

+1. Вот согласен

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

+, так и делаю у себя

Норм, только презентеры должны быть отделены. А так норм. И про adapters не понял, что там?

Это мешает навигации.

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

+

Ребят, извиняюсь, но повторю вопрос, мб кто пропустил. Как сохранять данные во фрагменте при переходе по стеку (точнее, возврат на фрагмент назад)

а разводить по пакету на класс - оверкилл, ИМХО

а зачем?

Ребят, извиняюсь, но повторю вопрос, мб кто пропустил. Как сохранять данные во фрагменте при переходе по стеку (точнее, возврат на фрагмент назад)

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

Норм, только презентеры должны быть отделены. А так норм. И про adapters не понял, что там?

Я делю каждый экран со всему его вытекающими. Так как когда в одном пакете лежат 100 презенторов то теряешься

+

Ладно-ладно.) Я понял.)

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

не странно. Пользователь что-то ввёл, нельзя это выбрасывать.

ну я, например, открываю фрагмент редактирования профиля, там моя текущая информация, я ее меняю, потом ухожу назад, открываю снова

Переиспользовать куски логики.

Хз, пока слабо представляю зачем. Во всех проектах у меня не было переиспользования и при этом не было повторений, везде логика была одноразовой

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

Мне надо сохранить данные в первом фрагменте, перейти во второй, а если возвращаюсь обратно в первый - показывать данные, что были в первом фрагменте, а не грузить их заново

логично, что там снова должна быть текущая инфа, а не изменнная, но несохраненная

Мне надо сохранить данные в первом фрагменте, перейти во второй, а если возвращаюсь обратно в первый - показывать данные, что были в первом фрагменте, а не грузить их заново

а, такой кейс, я не так понял значит начальное сообщение

Мне надо сохранить данные в первом фрагменте, перейти во второй, а если возвращаюсь обратно в первый - показывать данные, что были в первом фрагменте, а не грузить их заново

запиши данные в проперти фрагмента и проверяй когда вернешься назад. система будет пересоздавать фрагмент не забывай onsave/restore юзать. а в месте где должна быть загрузка данных проверь эту пропертю на предмет наличия данных

запиши данные в проперти фрагмента и проверяй когда вернешься назад. система будет пересоздавать фрагмент не забывай onsave/restore юзать. а в месте где должна быть загрузка данных проверь эту пропертю на предмет наличия данных

onsave/onrestore вызывается же только когда вызывается у активити, разве нет?

у фрагмента тоже есть

у фрагмента тоже есть

ну вот я и говорю, что у фрагмента вызывается только тогда, когда вызывается у активити

ну вот я и говорю, что у фрагмента вызывается только тогда, когда вызывается у активити

это необязательно связано друг с другом. фрагменты могут жить внутри других фрагментов и там жизненный цикл необязательно будет связан с активити

это необязательно связано друг с другом. фрагменты могут жить внутри других фрагментов и там жизненный цикл необязательно будет связан с активити

ну у меня не вызывается, уже пробовал туда сохранять. А про проперти подробнее можно? Что это?)

да просто поле внутри фрагмента сделай, private var myData:List<Something> = emptyList() (ну или что ты там загружаешь)

да просто поле внутри фрагмента сделай, private var myData:List<Something> = emptyList() (ну или что ты там загружаешь)

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

ну ты когда двигаешься вглубь иерархии - предыдущие фрагменты кладутся в стек. их поля остаются т.к. инстанс класса не умирает

да, я это понимаю, проблема в том, что у меня это не работает

когда возвращаешься они достаются из стека, теже инстансы. вью у них пересоздается

кладу фрагмент в стек, возвращаюсь - пусто

попробуй сделать сначала так

Такая ситуация, в гп опубликовано приложение, но мне очень надо поменять имя пакета(что бы ссылка в гп тоже поменялась), но не менять приложение(код).Могу ли я деактивировать старое приложение и на этот же аккаунт залить приложение под видом нового? Не будет ли ругаться гугл что это дубликат?

попробуй сделать сначала так

у меня сейчас так

@polopolopo где ты загружаешь данные?