А разве телеги не было на гитхабе ?

только фронты, и те под GPL, да и никто не захочет иметь у себя ТАКОЕ количество костылей

Каких костылей

Каких костылей

привет! Если ли возможность кастануть класс на Any в котлин ?

Разве тот код который доступен всем для ознакомления является текущим рабочим кодом тг?

Интересует наличие у wifi поддержки mimo

привет! Если ли возможность кастануть класс на Any в котлин ?

Тебе в чат котлин

в случае с андроидным клиентом — нет, на гитхабе старый код

Вот и все

кто «все»?

что?

Интересует наличие у wifi поддержки mimo

Напомните, пожалуйста, список чатов в ТГ для программистов!🙏

в случае с андроидным клиентом — нет, на гитхабе старый код

Напомните, пожалуйста, список чатов в ТГ для программистов!🙏

github.com/goq/telegram-list

А ответьте пж вот на што. У меня SingleActivity аппликация. При запуске приложения в container посредством replace сеттится фрагмент со сплешом. Сплеш забирает данные с апи, кеширует их и даёт команду на отображение фрагмента с контентом, который сеттится аналогично через replace. Есть такой кейс, что если запустить апку и сразу её свернуть, а затем развернуть через какое - то время (т.е дождаться пока сплеш прогрузит данные и даст команду на переход), то я упаду с: java.lang.IllegalStateException: FragmentManager is already executing transactions Я это пофиксил. Я пользуюсь своим на коленке написанным навигатором, который который сеттит фрагменты используя commitNow(). Апка перестала падать, когда я заменил commitNow() на commitAllowingStateLoss(). Однако я нихрена не понял что произошло, объясните пж. Как ни странно, мой кейс нифига не гуглится. Поэтому приходится думать головой, а эт чёт сложно. Я знаю, что commitNow() - синхронный, а commitAllowingStateLoss() - ассинхронный. Но мне это не говорит ни о чём. В теории, мб есть какая - то связь с тем что приложение свёрнуто и тем что вызов был именно синхронный, но чёт сомнения одолевают. В доках ничего явно не сказано на этот счёт. Я залез чуть глубже, и увидел что этот эксепшн бросает FragmentManager ручками. Вот блок кода: private void ensureExecReady(boolean allowStateLoss) { if (mExecutingActions) { throw new IllegalStateException("FragmentManager is already executing transactions"); } Логика там вроде как примерно такая: запускается транзакция, флаг сеттится в true, транзакция завершается, флаг сеттится в false. Это предположение, т.к отдебажить это я не могу - дебаггер слетает когда я апку сворачиваю, а то что я успеваю отдебажить - это ад, там этот флаг 100500 раз дёргается, нифига не понятно. Собственно, догадок покамест нет. Моя транзакция по установке сплеша завершается успешно(скорее всего), т.к я его вижу прежде чем апку свернуть. Шо происходет? В моём коде нет ничего интересного, но пущай будет. fun replaceNewFragment(screen: Screen, animationType: AnimationType? = null) { fragmentManager .beginTransaction() .setCustomAnimations(R.anim.anim1,R.anim.anim2) .replace(container, screen.getFragment(), screen.getTag()) .commitNow() }

Друзья, как пофиксить такую багу, ресурсы с тегами типа "<b>test</b> выводит tv.setText(getText(R.string.test1)) норм.. а так tv.setText(getText(R.string.test1)+"@@@@@@@@@") перестают работать теги((

> Как ни странно, мой кейс нифига не гуглится. Поэтому приходится думать головой, а эт чёт сложно. Все гуглится, это распространенная проблема > Я знаю, что commitNow() - синхронный, а commitAllowingStateLoss() - ассинхронный. commit/commitAllowingStateLoss - асинхронные, тоже самое с приставкой Now - синхронные. Гугли, куча инфы по этому кейсу

что?

Друзья, как пофиксить такую багу, ресурсы с тегами типа "<b>test</b> выводит tv.setText(getText(R.string.test1)) норм.. а так tv.setText(getText(R.string.test1)+"@@@@@@@@@") перестают работать теги((

Длинное слово))

А ответьте пж вот на што. У меня SingleActivity аппликация. При запуске приложения в container посредством replace сеттится фрагмент со сплешом. Сплеш забирает данные с апи, кеширует их и даёт команду на отображение фрагмента с контентом, который сеттится аналогично через replace. Есть такой кейс, что если запустить апку и сразу её свернуть, а затем развернуть через какое - то время (т.е дождаться пока сплеш прогрузит данные и даст команду на переход), то я упаду с: java.lang.IllegalStateException: FragmentManager is already executing transactions Я это пофиксил. Я пользуюсь своим на коленке написанным навигатором, который который сеттит фрагменты используя commitNow(). Апка перестала падать, когда я заменил commitNow() на commitAllowingStateLoss(). Однако я нихрена не понял что произошло, объясните пж. Как ни странно, мой кейс нифига не гуглится. Поэтому приходится думать головой, а эт чёт сложно. Я знаю, что commitNow() - синхронный, а commitAllowingStateLoss() - ассинхронный. Но мне это не говорит ни о чём. В теории, мб есть какая - то связь с тем что приложение свёрнуто и тем что вызов был именно синхронный, но чёт сомнения одолевают. В доках ничего явно не сказано на этот счёт. Я залез чуть глубже, и увидел что этот эксепшн бросает FragmentManager ручками. Вот блок кода: private void ensureExecReady(boolean allowStateLoss) { if (mExecutingActions) { throw new IllegalStateException("FragmentManager is already executing transactions"); } Логика там вроде как примерно такая: запускается транзакция, флаг сеттится в true, транзакция завершается, флаг сеттится в false. Это предположение, т.к отдебажить это я не могу - дебаггер слетает когда я апку сворачиваю, а то что я успеваю отдебажить - это ад, там этот флаг 100500 раз дёргается, нифига не понятно. Собственно, догадок покамест нет. Моя транзакция по установке сплеша завершается успешно(скорее всего), т.к я его вижу прежде чем апку свернуть. Шо происходет? В моём коде нет ничего интересного, но пущай будет. fun replaceNewFragment(screen: Screen, animationType: AnimationType? = null) { fragmentManager .beginTransaction() .setCustomAnimations(R.anim.anim1,R.anim.anim2) .replace(container, screen.getFragment(), screen.getTag()) .commitNow() }

хз как его конектить, в отдельной переменной и в спане и в спанбилдере и чарсиквенсе, чет теги срабатывают только getString(R.string.test) я даже хз че там за конструктор срабатывает

приложение сворачивалось кнопкой back? если да, то вызвался onDestroy, активити умерла. ФрагментМенеджеру стало некуда втыкать фрагмент. Именно для этих целей и используется асинхронный коммит.

Почитай, статья старая, но там причины таких эксепшенов описаны

практически полный ответ на твой вопрос можешь найти здесь: https://medium.com/inloopx/demystifying-androids-commitallowingstateloss-cb9011a544cc

Я знаю про кейс, когда мы совершаем транзакцию после того, как активити сохранила стейт, из - за чего FragmentManager бросает IllegalStateException. Мне кажется, что это не он.

А ты отписываешься от результата запроса в сплеше?

Случайно тимлида в этой группе нет?

Оч надеюсь что нет, ибо если он спалит что я тут спрашиваю, мне пiзда)

Ой да не пох?

практически полный ответ на твой вопрос можешь найти здесь: https://medium.com/inloopx/demystifying-androids-commitallowingstateloss-cb9011a544cc

Кстати, в конце этой статьи есть хороший такой инсайт: Always first analyse why the transaction is being executed after onStop(). Я так понимаю, транзакция после onStop() - это по дефолту плохо?

Да че ты переживаешь Всегда есть @mobile_jobs

После онресторинстанс

Свет клином на ИТ не сошёлся

Ты про архитектуру?

Ну блин, а ежели юзер свернул апку, а у него там через какое - то время случился какой - то ивент, который тригернул commit()? Типо, правильнее будет передумать подход, и сделать так, чтобы транзакция не вызывалась, а вью просто была в курсе, что по возвращению к приложению надо бы где - нибудь в onResume() совершить транзакцию?

После онрезюм делай свои транзакции

Ну да, logic. Это шо мне со сплешом то делать. Получается, после того как фрагмент завершит тянуть данные с сервера, нужно проверить в каком состоянии фрагмент, и если будет что - то типо paused/stopped(хз, я тупой и не знаю состояния фрагмента), бахнуть какой - нибудь флаг, чтобы в onResume() был совершен переход. Да?

Ливдата

Ну блин, а ежели юзер свернул апку, а у него там через какое - то время случился какой - то ивент, который тригернул commit()? Типо, правильнее будет передумать подход, и сделать так, чтобы транзакция не вызывалась, а вью просто была в курсе, что по возвращению к приложению надо бы где - нибудь в onResume() совершить транзакцию?

А что ливдата? Она не заэмиттит ничего из paused/stopped?

А что ливдата? Она не заэмиттит ничего из paused/stopped?