Привет! Кто хорошо разбирается в Gson, подскажите, пожалуйста, как распарсить вот такую структуру, когда в массиве данные разных типов: { "data":[ { "type":"type1", "data":[1,2,3] }, { "type":"type2", "data":"hello" } ] }

я разобрался В исходнихах фрагмент менеджер удаляет из этого массива элементы как arrayList.set(position, null)

ну так не трогай getFragments() этот метод там не для тебя)

Привет! Кто хорошо разбирается в Gson, подскажите, пожалуйста, как распарсить вот такую структуру, когда в массиве данные разных типов: { "data":[ { "type":"type1", "data":[1,2,3] }, { "type":"type2", "data":"hello" } ] }

Object не?

я разобрался В исходнихах фрагмент менеджер удаляет из этого массива элементы как arrayList.set(position, null)

УХТЫЖБЛЯ!

я просто могу его кидать в конструкторы и в методы как параметр

Не всегда удобно и красиво и возможно. А статик контекст App разререшно делать и он не вредит в отличии от статик контекста активити

Прервать рабочие асинктаски, начать новые после поворота. Твои варианты?

тот же вопрос - а если в асинктаске операция, которую нельзя повторить не зная результата предыдущей попытки? Варианты - сервисы, потоки, mvp и т.д. - всё что не зависит от жизненого цикла активити

а если в асинктаске операция, которую нельзя повторить не зная результата предыдущей попытки?

кароче) надо смотреть от проблемы)

Object не?

Это как?

Привет! Кто хорошо разбирается в Gson, подскажите, пожалуйста, как распарсить вот такую структуру, когда в массиве данные разных типов: { "data":[ { "type":"type1", "data":[1,2,3] }, { "type":"type2", "data":"hello" } ] }

Зарегистрировать TypeAdapter, который парсит всё в обычные Map / List, а потом сам мутит полиморфизм.

object не прокатит

Прервать рабочие асинктаски, начать новые после поворота. Твои варианты?

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

нужно свой адаптер в гсон пихать

кстати статик там возможно для поворота ))

интересно, но тут один режим, без поворотов

да я напоролся на такое гавно

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

тот же вопрос - а если в асинктаске операция, которую нельзя повторить не зная результата предыдущей попытки? Варианты - сервисы, потоки, mvp и т.д. - всё что не зависит от жизненого цикла активити

Загружать картинки / записи из БД через сервис? Использовать сырые потоки — не надо так.

Привет! Кто хорошо разбирается в Gson, подскажите, пожалуйста, как распарсить вот такую структуру, когда в массиве данные разных типов: { "data":[ { "type":"type1", "data":[1,2,3] }, { "type":"type2", "data":"hello" } ] }

чтото на подобие этого protected static boolean isContainsPrimitive(JsonObject object, String key) { return object.get(key) != null && object.get(key).isJsonPrimitive(); } protected static boolean isContainsObject(JsonObject object, String key) { return object.get(key) != null && object.get(key).isJsonObject(); } protected static boolean isContainsArray(JsonObject object, String key) { return object.get(key) != null && object.get(key).isJsonArray();

> @Andre1024 интересно, но тут один режим, без поворотов на будущее ))

ок)

чтото на подобие этого protected static boolean isContainsPrimitive(JsonObject object, String key) { return object.get(key) != null && object.get(key).isJsonPrimitive(); } protected static boolean isContainsObject(JsonObject object, String key) { return object.get(key) != null && object.get(key).isJsonObject(); } protected static boolean isContainsArray(JsonObject object, String key) { return object.get(key) != null && object.get(key).isJsonArray();

contains*

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

да знаю, возможно так сделано чтобы не перевыделять память под новые элементы ArrayList, а просто в убранные нулл вставляется. Это внутренняя реализация и поэжтому лучше не лезть туда. А зачем тебе понадобился getFragments() ?

Понял, спасибо большое всем!

contains*

точно)

Привет! Кто хорошо разбирается в Gson, подскажите, пожалуйста, как распарсить вот такую структуру, когда в массиве данные разных типов: { "data":[ { "type":"type1", "data":[1,2,3] }, { "type":"type2", "data":"hello" } ] }

Думаю что в полноцннные POJO такое ты распарсить не сможешь, но, ЕМНИП, по-умолчанию, GSON создает древовидную структуру из List-ов, и Map-ок, так что, если уверен в данных, то кастуешь и получаешь значение по индексу/имени.

...хотя API-шка возвращающая /такое/ неок по-определению, имхо.

да знаю, возможно так сделано чтобы не перевыделять память под новые элементы ArrayList, а просто в убранные нулл вставляется. Это внутренняя реализация и поэжтому лучше не лезть туда. А зачем тебе понадобился getFragments() ?

не понадобился. просто есть у меня контейнер, в нем два фрагмента. один выше другого добавлен через fragmentManager.add(...) после поворота экрана они меняются местами(тот который был над первым выше оказывался под первым) то, какой фрагмент выводить в контейнер первым, определяется положением в списке getFragments()

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

ну и фрагменты начинают рисоваться неправильно

не понадобился. просто есть у меня контейнер, в нем два фрагмента. один выше другого добавлен через fragmentManager.add(...) после поворота экрана они меняются местами(тот который был над первым выше оказывался под первым) то, какой фрагмент выводить в контейнер первым, определяется положением в списке getFragments()

плохой вариант сразу 2 фрагмента в 1 контейнер мне кажется

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

Загружать картинки / записи из БД через сервис? Использовать сырые потоки — не надо так.

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

плохой вариант сразу 2 фрагмента в 1 контейнер мне кажется

согласен но тут от заказчика было требование сделать одну активность на всё приложение

согласен но тут от заказчика было требование сделать одну активность на всё приложение

ну 2 фраемлаяута положи рядом

который должен поверх - тот ниже

их на самом деле уже четыре штуки)

их на самом деле уже четыре штуки)

заказчик диктует как делать?

в разных местах, правда вобщем, это усложнило бы реализацию контроллера фрагментов здоровски, потому что в одном контейнере, по правде говоря(на одном месте экрана), может открываться 5+ фрагментов

не диктует прям как сделать, но диктует как должно выглядеть и кроме как одной активностью это не сделать

не диктует прям как сделать, но диктует как должно выглядеть и кроме как одной активностью это не сделать

почему так решил?

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

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

анимация "бургер-стрелочка" я имею ввиду

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

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

сделать чтобы стрелка крутилась, а у активити не было такой дефолтной анимации будто она откуда-то вылезла

анимация "бургер-стрелочка" я имею ввиду

В смысле их должно быть 5+, почему не replace?

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

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

Выбирать данные и сохранять их — задача для презентера или контроллера (сервиса). Если данные соответствуют представлению и не требуют большой и сложной или длительной обработки или отправки на бэк, то можно это сделать в презентере. По длительности и размеру кода такая задача занимает промежуточное положение между "безболезненно дёрнуть что-нибудь в UI-потоке" и "долго думать в сервисе". Как мне кажется, такой задаче самое место в AsyncTask: она имеет смысл в контексте одной активити (после пересоздания результат можно проигнорировать) и длится не долго (не вызовет утечку старой активити). Поэтому я не вижу табу на выборку данных в AsyncTask. Над сохранением нужно думать внимательнее, потому что после пересоздания активити может понадобится уведомить активити об обновлении (если ORM этого не делает сама, как это делает Realm), придётся делать развязку (Local Broadcast), как с сервисом.

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

Вопрос, что там происходит что ты говоришь "фрагмент по верх фрагмента"?

Звучит так, как буд-то ты их накладываешь один поверх другого

Почему add?

Почему не replace?

Выбирать данные и сохранять их — задача для презентера или контроллера (сервиса). Если данные соответствуют представлению и не требуют большой и сложной или длительной обработки или отправки на бэк, то можно это сделать в презентере. По длительности и размеру кода такая задача занимает промежуточное положение между "безболезненно дёрнуть что-нибудь в UI-потоке" и "долго думать в сервисе". Как мне кажется, такой задаче самое место в AsyncTask: она имеет смысл в контексте одной активити (после пересоздания результат можно проигнорировать) и длится не долго (не вызовет утечку старой активити). Поэтому я не вижу табу на выборку данных в AsyncTask. Над сохранением нужно думать внимательнее, потому что после пересоздания активити может понадобится уведомить активити об обновлении (если ORM этого не делает сама, как это делает Realm), придётся делать развязку (Local Broadcast), как с сервисом.

в целом то всё правильно, но если я один фиг делаю презентор для 100% надёжной работы с данными, использующий потоки/интеракторы/сервисы/чтомнепридётвголову/... , зачем мне ещё асинктаск, больтающийся во "вью", который надо отдельно синхронизировать с этим презентором?

в целом то всё правильно, но если я один фиг делаю презентор для 100% надёжной работы с данными, использующий потоки/интеракторы/сервисы/чтомнепридётвголову/... , зачем мне ещё асинктаск, больтающийся во "вью", который надо отдельно синхронизировать с этим презентором?

Асинктаску место в презентере.

Асинктаску место в презентере.

в интеракторе

Почему не replace?

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

в интеракторе

Что за паттерн, где почитать?

Что за паттерн, где почитать?

VIPER в гугле поищи)

Асинктаску место в презентере.

ему место на помойке

вот, чуваки, скажите мне, нафига вы используете async task ?

дайте мне хоть 1 достойный аргумент

Выбирать данные и сохранять их — задача для презентера или контроллера (сервиса). Если данные соответствуют представлению и не требуют большой и сложной или длительной обработки или отправки на бэк, то можно это сделать в презентере. По длительности и размеру кода такая задача занимает промежуточное положение между "безболезненно дёрнуть что-нибудь в UI-потоке" и "долго думать в сервисе". Как мне кажется, такой задаче самое место в AsyncTask: она имеет смысл в контексте одной активити (после пересоздания результат можно проигнорировать) и длится не долго (не вызовет утечку старой активити). Поэтому я не вижу табу на выборку данных в AsyncTask. Над сохранением нужно думать внимательнее, потому что после пересоздания активити может понадобится уведомить активити об обновлении (если ORM этого не делает сама, как это делает Realm), придётся делать развязку (Local Broadcast), как с сервисом.

давно не слышал что бы кто-то это использовал

вот, чуваки, скажите мне, нафига вы используете async task ?

однако, здравствуйте

для таких штук достаточно в тред завернуть

для таких штук достаточно в тред завернуть

а ещё приоритет понизить и позвать runOnUiThread. Можно даже свой AsyncTask запилить.

для таких штук достаточно в тред завернуть

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

VIPER в гугле поищи)

Спасибо. Почему-то думал, что актуально только в iOS.

правда я не в теме о штуках

ERROR: S client not available

Что за паттерн, где почитать?

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

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

runOnUiThread

Выбирать данные и сохранять их — задача для презентера или контроллера (сервиса). Если данные соответствуют представлению и не требуют большой и сложной или длительной обработки или отправки на бэк, то можно это сделать в презентере. По длительности и размеру кода такая задача занимает промежуточное положение между "безболезненно дёрнуть что-нибудь в UI-потоке" и "долго думать в сервисе". Как мне кажется, такой задаче самое место в AsyncTask: она имеет смысл в контексте одной активити (после пересоздания результат можно проигнорировать) и длится не долго (не вызовет утечку старой активити). Поэтому я не вижу табу на выборку данных в AsyncTask. Над сохранением нужно думать внимательнее, потому что после пересоздания активити может понадобится уведомить активити об обновлении (если ORM этого не делает сама, как это делает Realm), придётся делать развязку (Local Broadcast), как с сервисом.

ретрофитом асинхронный запрос с колбэком, не ?

runOnUiThread

а зачем тогда вообще тред отдельный создавать?

VIPER в гугле поищи)

мне сама реализация для андроида не понравилась, делаь фрагмент для хранения данных

а зачем тогда вообще тред отдельный создавать?

Чтобы кадры не пропускать. Recycler с картинками, подгружаемыми в UI-потоке, выглядит убого и дёргано.

а зачем тогда вообще тред отдельный создавать?

в смысле? тред отработал, в конце вызвал runOnUiThread

в смысле? тред отработал, в конце вызвал runOnUiThread

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

Чтобы кадры не пропускать. Recycler с картинками, подгружаемыми в UI-потоке, выглядит убого и дёргано.

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

или что-нибудь похожее

VIPER в гугле поищи)

хех) https://play.google.com/store/apps/details?id=com.vipercn.viper4android_v2_fx

забудьте про треды и асинктаски есть же куча адекватных реализаций

хех) https://play.google.com/store/apps/details?id=com.vipercn.viper4android_v2_fx

сколько не понятных символов ?

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

Разговор об инструментах системы для асинхронности, а не о загрузке картинок как таковой. Например, с помощью Picasso не загрузишь записи из БД.

Разговор об инструментах системы для асинхронности, а не о загрузке картинок как таковой. Например, с помощью Picasso не загрузишь записи из БД.

тогда я вообще зря влазию не разобравшись в чем дело...

забудьте про треды и асинктаски есть же куча адекватных реализаций

☕️☕️

забудьте про треды и асинктаски есть же куча адекватных реализаций

Я использовал AsyncTask для парсинга Markdown, например. Было бы глупо разобранное синтаксическое дерево прокидывать из сервиса.

Я использовал AsyncTask для парсинга Markdown, например. Было бы глупо разобранное синтаксическое дерево прокидывать из сервиса.

а парсил в адаптере?

Я использовал AsyncTask для парсинга Markdown, например. Было бы глупо разобранное синтаксическое дерево прокидывать из сервиса.

ну и ок сейчас проще на рх написать чем городить таску

Я использовал AsyncTask для парсинга Markdown, например. Было бы глупо разобранное синтаксическое дерево прокидывать из сервиса.

неправильно ты делаешь, Кот Матроскин! Можно хотя бы лоадер заюзать

или вообще на rx

если он в проекте есть

а парсил в адаптере?

Парсил в AsyncTask. В адаптере байндил готовое синтаксическое дерево.

Парсил в AsyncTask. В адаптере байндил готовое синтаксическое дерево.

Xорошо. AsyncTask ведь запускался где-то?

Xорошо. AsyncTask ведь запускался где-то?

в onCreateView фрагмента

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

Это ужасное решение и создало тебе проблемы

ну и ок сейчас проще на рх написать чем городить таску

Недолюбливаю rx. :upside_down_face:

в onCreateView фрагмента

это и правда стоило бы вынести в какой-то интерактор, как уже посоветовали

Недолюбливаю rx. :upside_down_face:

может ты просто не научился его правильно готовить??

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

неправильно ты делаешь, Кот Матроскин! Можно хотя бы лоадер заюзать

Как-то я не подружился с лоадерами. Почему — не помню. Пора пересматривать своё отношение к ним. И, если я правильно помню, лоадеры основаны на асинктасках.

это и правда стоило бы вынести в какой-то интерактор, как уже посоветовали

Весь фрагмент умещается в полторы страницы кода, не вижу смысла отделять тривиальное представление от тривиальной логики.