"On the down-side, it does not support any annotation processors, for example, so if you’re using Dagger, Dagger 2 or Butter Knife in your project, it’s fairly useless. And since any annotations need to be processed every time a change the to code is made (not even to the annotations themselves), the compile time for the project piles up and takes quite a chunk of the total build time."

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

Butter Knife Parceler Icepick Dagger Dagger2 AutoValue Greenrobot EventBus Dart Henson Deeplink Epoxy

Но это уже совсем несерьезно. Как минимум тут нет Logan Square. Да и вообще, учитывая, что annotation processing становится все более популярным (как попытка замены reflection), они заебутся пополнять этот список :)

и не смотря на все это, если бы их инкрементальная компиляция входила бы в те же 49 USD, то норм

а 349 USD - no way

Какой смысл писать сюда об этом? Тут люди либо покупают, либо подходят мимо. Думаю лучше Архипову(соррян, спутал) написать свои мысли. Он не кусается. )

А что надо писать сюда? Я думал здесь не является оффтопом обсуждение фреймворков, касающихся android-разработки, ровно как и ценовой политики их разработчиков. Опять же, зарплаты, вот, обсуждают и норм.

А что надо писать сюда? Я думал здесь не является оффтопом обсуждение фреймворков, касающихся android-разработки, ровно как и ценовой политики их разработчиков. Опять же, зарплаты, вот, обсуждают и норм.

В твоем поссыле это звучит как "они а###ли столько просить", а не обсуждение.))

Ну хз, даже в моем мухосранске 150-200к можно получать не будучи специалистом топового уровня. собственно, я не тимлид и занимаюсь вполне обычной хуйней - мониторингом упоминаний, у меня зп в 130, у начальства - выше. Подружечка-сммщица получает 170, хотя опять же не тимлид и не сотрудник топового уровня.

Название мухосранска можно узнать? Чтобы со своим сравнить?

Название мухосранска можно узнать? Чтобы со своим сравнить?

краснодар

Это не отменяет возможности дискуссии на эту тему, так что норм.

Ну при зарплате в 200К(а это около 1КК в год), то 30К в год не так уж и много. Ведь все мы специалисты. Правда же?)))

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

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

Кто это сказал?

Что не может стоить - мое личное мнение. Из всех щелей уже про этот джейребел орут, заколебали. Еще один эпл, блин. Ничего личного, мысли вслух.

Что не может стоить - мое личное мнение. Из всех щелей уже про этот джейребел орут, заколебали. Еще один эпл, блин. Ничего личного, мысли вслух.

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

Мне кажется тут должны понимать насколько тяжело написать такую софтину. И от этой софтины зависит твоя производительность. Так что считать её второстепенной это неправильно.

Не вижу смысла обсуждать второстепенную ерундовину. Меня то заколебало, что на каждом углу про эту хрень слышно. Что-то никто не обсуждает необходимость dexguard, хотя он явно лучше proguard и большенство тут не против безопасности. И написать его не просто.

Не читайте и не слушайте. В чем проблема?

Производительность, если ui писать по TDD. Мы в обоих проектах это не практикуем. Те, кто практикуют, давно решили это проблему ИМХО.

Не смотреть профильную литературу? Спасибо за совет. Как я сам не догадался...

Не смотреть профильную литературу? Спасибо за совет. Как я сам не догадался...

Не за что.))

Лично мне JRebel даёт просто дичайший выигрыш. Билд собирается где-то полторы минуты, а JRebel изменения на горячую вкидывает за 10 секунд максимум

У Instant Run очень много ограничений и очень многое он не умеет

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

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

У тебя с ssd так?

У тебя с ssd так?

Без

Без

А не лучше взять ssd?

А не лучше взять ssd?

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

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

А если их вместе использовать?

)

А если их вместе использовать?

Даже тогда ссд не научится hot swap'у)

При чём тут вообще ссд?

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

На сборку больше всего влияет проц и оператива. У меня под гредл выделено 4гб памяти. Он всё нужное в оперативной памяти хранит и оттуда же берёт

Попробуй собрать с хипом 1гб и 4гб

Будешь приятно удивлен

А, ну и демон ещё

Ссд ускорит, но это будет капля в море

Ссд ускорит, но это будет капля в море

Т. е. стоит оставить JRebel? Ну, хоть одна более менее хорошая новость

Не придется с возвратом возиться

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

Не стоит. Это однозначно маст хэв тулза

Надо будет ещё sqlscout прикупить

И будет полный фарш

И будет полный фарш

А это еще что?

Позволяет прямо из студии смотреть чё там сейчас в бдшке приложения

Позволяет прямо из студии смотреть чё там сейчас в бдшке приложения

Интересно. А сколько стоит?

50$ за год

А есть же бесплатный stetho http://facebook.github.io/stetho/

А есть же бесплатный stetho http://facebook.github.io/stetho/

Есть не спорю, но у меня аллергия на Facebook

https://twitter.com/romainguy/status/787076787524153344

А есть же бесплатный stetho http://facebook.github.io/stetho/

У него есть большой недостаток, его каждый раз нужно перезапускать. Плюс нужен хром.

У него есть большой недостаток, его каждый раз нужно перезапускать. Плюс нужен хром.

То что его нужно перезапускать раздражает.

>Chrome Да ну их, хром для свистоперделки им нужен

Народ, кто-то знает качественные опен-сорсные мессенджеры? Надеялся почерпнуть некоторые идеи для рефакторинга. Телеграм не предлагать, я спиться не хочу)

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

Вайбер декомпильнул - обфускация?

Вк мне не сообщает о половине писем, видимо, умирает конекшн к лонг-поллингу и не восстанавливается.

Да и вообще, на Xiaomi у меня упорно держат конекшн только вайбер и вотсапп

Поэтому на них и смотрел больше

Вк мне не сообщает о половине писем, видимо, умирает конекшн к лонг-поллингу и не восстанавливается.

У меня тоже часто сообщения не приходят или приходят с большой задержкой

ERROR: S client not available

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

Ахаха. Это на китайских фаблетах каждый мессенджер свой сокет держит в фоне? На них же пуши забанены

Ты так говоришь, будто это что-то плохое. GCM не гарантирует доставку и тем более, доставка не моментальная

У меня на нексусе моментальная

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

GCM/FCM - хорошая штука, чтобы попытаться дернуть девайс, если видно, что у юзера умер конекшн (у себя так и делаем), но не более.

Народ, кто-то знает качественные опен-сорсные мессенджеры? Надеялся почерпнуть некоторые идеи для рефакторинга. Телеграм не предлагать, я спиться не хочу)

https://github.com/wireapp/wire-android

Спасибо, гляну

GCM/FCM - хорошая штука, чтобы попытаться дернуть девайс, если видно, что у юзера умер конекшн (у себя так и делаем), но не более.

Что за очередной месенжер?

Это неважно) Тот, за который платят деньги

Телеграмм не держит сокет, слак тоже, а вы держите

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

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

Судя по настройкам - держит

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

Судя по настройкам - держит

Тадам

Хотелось бы кое-что спросить про реализацию Long-Polling на Android. Как известно, она предполагает подключение к серверу и ожидание данных от него. Как только сервер выдаст данные он разрывает соединение, после чего клиент инициирует новое соединение, ждет новых данных и т.п. Очевидно, в этой схеме надо подумать и о таймаутах соединения, которые, как известно случаются. Глупо будет если у соединения от клиента к серверу в качестве read-timeout будет установлено значение 0. Очевидно, надо выбрать какие-то значение, например, 60 сек. Но тогда, если вы, например, разрабатываете чат, нужно будет побеспокоиться и о работе этого long-polling и в бэкграунде, пока приложение не на экране. В этом случае, при таймауте polling-соединения в 60 сек, ваше приложение каждую минуту будет выполнять некоторую работу, будить устройство и жрать батарейку. Хотелось бы узнать, как опытные разработчики пытаются избежать этой проблемы на старых платформах, где еще не было развитого doze-mode (который, как известно, просто не дает проснуться устройству, гарантируя лишь "окна активности" с убывающей периодичностью).

Хотелось бы кое-что спросить про реализацию Long-Polling на Android. Как известно, она предполагает подключение к серверу и ожидание данных от него. Как только сервер выдаст данные он разрывает соединение, после чего клиент инициирует новое соединение, ждет новых данных и т.п. Очевидно, в этой схеме надо подумать и о таймаутах соединения, которые, как известно случаются. Глупо будет если у соединения от клиента к серверу в качестве read-timeout будет установлено значение 0. Очевидно, надо выбрать какие-то значение, например, 60 сек. Но тогда, если вы, например, разрабатываете чат, нужно будет побеспокоиться и о работе этого long-polling и в бэкграунде, пока приложение не на экране. В этом случае, при таймауте polling-соединения в 60 сек, ваше приложение каждую минуту будет выполнять некоторую работу, будить устройство и жрать батарейку. Хотелось бы узнать, как опытные разработчики пытаются избежать этой проблемы на старых платформах, где еще не было развитого doze-mode (который, как известно, просто не дает проснуться устройству, гарантируя лишь "окна активности" с убывающей периодичностью).

Пуши?

ненадежно же

Ты так говоришь, будто это что-то плохое. GCM не гарантирует доставку и тем более, доставка не моментальная

Ага, держать радио модуль постоянно активными, не давать устройству спать и выжирать батарею, очень "не плохо". Именно для таких Google придумала Doze.

https://github.com/syedowaisali/crystal-preloaders кому-то нужна была анимация эквалайзера

Ага, держать радио модуль постоянно активными, не давать устройству спать и выжирать батарею, очень "не плохо". Именно для таких Google придумала Doze.

окей, вот у тебя висит открытый TCP сокет. Как он жрет процессор/сеть?

(помимо периодических keepalive'ов)

окей, вот у тебя висит открытый TCP сокет. Как он жрет процессор/сеть?

Радио модуль не спит

Этого достаточно

Радио модуль не спит

с чего вдруг, если данные не идут?

Открытый сокет в бесконечном потоке ждет и пингует

Но периодически идет же пинг?

Heartbeat