тратит тот разработчик, что контрибьютит

а спринт кто закрывать будет?

yep

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

да Федор вас тролит :) не ведитесь

да, но с достойными продуктами это скорее редкость. Вообще это нормально, т.к. это бесплатно

а спринт кто закрывать будет?

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

ну если так делать - то ок )

вот в саппорт лайбрари баги годами живут

не, не в конце концов если тебе сильно надо, можешь законтрибьютить и сам починить

вот и код весь на костыльках

да Федор вас тролит :) не ведитесь

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

вот выше советовали хронос

а он не поддерживается считай

ну так нужно же продолжать фишечку https://d-a.d-cd.net/3ede12s-960.jpg

самому что ли его до поддержки дозмода пилить?

там ни одного issue нет, что ты там фиксить собрался?)

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

вот в эвернотовском аналоге - все есть

ишью нет, потому что пользователей нет )

юзай решение от yigit boyar

https://github.com/yigit/android-priority-jobqueue

не успел еще поковырять

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

у него ЦА другая, не для doze mode

вот этот забавный турок отжигал на google io

ишью нет, потому что пользователей нет )

мб

но ты начал с retrofit, с которым всё иначе. Продолжи уже с ним тогда уже

ну ретрофит я щупал когда он только вышел

не успел еще поковырять

ну это просто некая такая абстракция, которая при апи 21 и выше юзает JobScheduler, а ниже юзает gcm network manager для того чтобы с doze всё хорошо было.

и когда окхттп не по рфц был написан

так вот, либы square вскоре после релиза использовать - так еще боль

я на протяжении полугода юзал собственноручно патченные okhttp и не заметил боли

фломастеры

ну вот - целых полгода страдал

так ты после того как потрогал к чему пришёл? Написал свой okhttp?

ну да

так ты после того как потрогал к чему пришёл? Написал свой okhttp?

лучше не трогать, не влезай - убьет. Я как-то боялся лезть в таких монстров)))

а может и зря

#whois > Какой у вас проект или где работаете? Фрилансер. > В чём вы специалист? Не знаю. > Чем можете быть интересны или полезны сообществу? Ничем. > Чем интересно сообщество вам? Следить за модной движухой в мире разработки под android. > Откуда вы? Не скажу. > Как узнали про группу? От друзей.

? а какую проблему сейчас решаете ? читать а то дофига ))

#whois > Какой у вас проект или где работаете? Фрилансер. > В чём вы специалист? Не знаю. > Чем можете быть интересны или полезны сообществу? Ничем. > Чем интересно сообщество вам? Следить за модной движухой в мире разработки под android. > Откуда вы? Не скажу. > Как узнали про группу? От друзей.

Знал я Андрюху Панченко из МСК, мб это не ты, но просто уточнить так-то можно

? а какую проблему сейчас решаете ? читать а то дофига ))

не, just флуд

привет, начал изучать разработку на андроид, текущая специализация php, js и тд. Для пробы решил написать приложение которое будет читать данные из гугл фит и показывать места на карте

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

кстати, на clojure никто не работает?

Интересно вот а в яве нормально если подходить к асинхронным задачам как в js , вызывая таковую передавать объект Runnable обратного вызова и просто ждать обработки без горождения интерфейсов и без создания одной функции слушателя?

А еще лучше не Runnable а MyRunnable { public void run(Object… o) {} } в который и результат передать можно и сапкастить до того, что надо )

сдаункастить точнее )

сдаункастить точнее )

касты плохая штука, избегай их по возможности. Если можно обойтись без каста - обойдись!

касты плохая штука, избегай их по возможности. Если можно обойтись без каста - обойдись!

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

А еще вот мне кажется сомнительным, если не лень посмотрите кто-нить )

так вообще можно в фрагменте поступать? ))

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

лучше всё это в презентер вынести если делать по mvp

и зачем вообще всю эту лабудень сохраняешь в бандл?

кстати, интересно а как в гугл фит смотреть на карте где ты бегал, твой путь7

Мвп, рх дагерром нагрузите

кстати, интересно а как в гугл фит смотреть на карте где ты бегал, твой путь7

в фите не помню, есть или нет. https://www.google.ru/maps/timeline вот ту должно быть

А то лесопеды с аргументами в интерфейсах потока какие-то

лучше всё это в презентер вынести если делать по mvp

И зачем в презентере состояние вьюхи?

И зачем в презентере состояние вьюхи?

я имел в виду про ServiceConnection и FitHistory

Это ты следующим сообщением имел

в фите не помню, есть или нет. https://www.google.ru/maps/timeline вот ту должно быть

хотя в картах тоже, похоже, этого нет

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

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

Ненавижу такие проблемы в андроиде

переведите, кто-нибудь

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

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

палехче. Можно предложения короче и с пунктуацией поадекватнее?

палехче. Можно предложения короче и с пунктуацией поадекватнее?

Ну вроде все логично ))

ага, у тебя в голове - может быть

ку да ты собрался фрагменты сохранять готовые?

В бандл активити говорит

С жс перейти в андроид сложнее чем с нуля

С жс перейти в андроид сложнее чем с нуля

Правда )

ку да ты собрался фрагменты сохранять готовые?

К примеру в статик поля класса сохранить можно.

Не, у нас же есть сохранялка данных при повороте например

К примеру в статик поля класса сохранить можно.

Нах такие советы давать

onSaveInstanceState

которая

К примеру в статик поля класса сохранить можно.

нихрена оно не работает так. Статика тоже удаляется, если активность удаляется из -за нехватки памяти

onSaveInstanceState

всё, что туда пишешь - навеки с тобой

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

зачем тебе писать "onSaveInstanceState" активности фрагмент?

или я не понял чего-то?

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

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

типа onSaveInstanceState() { put(key, fragment)? }

И вместо того чтоб строить что-то в шальной активити, взаимодействовать с фрагментом

типа onSaveInstanceState() { put(key, fragment)? }

Ннну дэ )