Pull to refresh

Comments 33

Кстати почему вы решили использовать именно AQuery? почему бы не использовать Retrofit + OkHttp + Picasso?
Учитывая ещё то, что последний релиз AQuery был год назад. А тот же Retrofit обновляется по сей день.
Не в частоте релизов счастье) Aquery, обладает бОльшим набором функционала, при меньшем размере и бОльшем удобстве. Я уже устал её рекламировать.
Да, мы немного наколхозили с ней, в ближайшем релизе поменяем на стандартную. Спасибо что заметили.
Не используйте RelativeLayout, вместо него старайтесь писать CustomView.
Слишком тяжелый вычисления, Chris Banes(или Roman Nurik) в одной из своих презентация просил крайне осторожно и редко их использовать, а лучше вообще создавать свои View.
Я так полагаю Озик хотел сказать что RelativeLayout штука коварная и можете наткнуться на проблемы с производительностью с ней. Как говорится: лучше уж пару вложенных LinearLayout, чем один RelativeLayout.
в официальной документации как раз есть разобранный контраргумент на ваш совет
developer.android.com/training/improving-layouts/optimizing-layout.html

тут же главное ко всему подходить с умом и понимать, что потом будет внутри происходить. и тогда можно написать RelativeLayout оптимальнее, чем получилось бы с другими стандартными ViewGroup.

для каждой конкретной ситуации можно написать CustomView, который будет работать оптимальнее, чем тот же вариант на RelativeLayout. если посмотреть на элементы списков в приложении Gmail в режиме отображения границ лэйаутов, то можно увидеть, что это как раз один CustomView. но этот вариант не всегда выиграет по соотношению производительность/затраченное время программиста.
Поймали меня за слово: )
Эта статья что вы привели слишком поверхностная. Там написано что, производительность может быть улучшена из-за выравнивания (flatten) иерархии и как предложение использовать RelativeLayout. Но это далеко не всегда так, из-за того, что RelativeLayout меряет (measure) своих детей в несколько проходов, применяя различные ограничения.

Понятное дело, что нужно сначала мерить, убедиться что есть проблема и затем уже оптимизировать.
Я не собирался ни на чем ловить)
LinearLayout тоже сначала меряет (measure) своих детей, чтобы узнать сколько они бы «хотели» занять, а потом с уже примененной логикой весов. Именно из-за этого в приведенной статье Relative и выиграл, потому что был один источник сложных вычислений RelativeLayout вместо двух LinearLayout.

Ну и с помощью RelativeLayout можно избавиться от проблемы излишних вложенностей (nested views) из-за которой на андроидах 2.x можно было наткнутся и на StackOverflow при отрисовке на довольно сложном экране
Рано леденец выпустили. Проблем достаточно много. Один расход аккумулятора и калькутор чего стоит.
Зато сейчас, благодаря фидбеку комьюнити, они всё это исправят и выпустят обновление.
Не знаю, но мой телефон стал жить на 1-1.5 часа меньше, чем жил на 4.4.4
На xda довольно активно обсуждают не только тему аккумуляторов, но и систему в целом.
Подождите, сейчас то уже поздно — 5.0 ушел в прод. Было бы здорово если они это исправили во время L Developer Preview.
Обновление для nexus 7 приостановили, видимо, правят что-то.
А что не так с аккумулятором? На моем нексусе 9 нет проблем, держится как второй айпад. Только заряжается от штатной зарядки вдвое дольше айпада.
Сейчас мой нексус держит заряд на 1-1,2 часа меньше чем на 4.4.4 и это не только у меня.
При это большая проблема с вейклоками.
Тот же Mark Murphy (автор The Busy Coder's Guide to Android Development) сказал, что лучше на 4.0+ версиях оставить Holo. А material design только для новых версий делать.

Но вы, как я понимаю, используете material design для всех версий Android?
Да, всё верно. Нам очень понравилось как приложение смотрится на версиях 4.x и мы решили подарить всем нашим пользователям немного нового юзер экспириенса.
Если бы в гугле не хотели видеть материальный дизайн на 4.х устройствах, зачем было делать бэкпорт стилей и новых вьюх?
По-моему, наоборот хорошо, что не надо менять устройство, которое застряло на 4.х, чтобы наслаждаться новым дизайном в приложениях.
Я не согласен с Марком в этом плане.
Стоит хотя бы учесть то, что большинство трендмейкеров, таких как Google, Facebook и иже с ними уже переходят на Material во все поля. Таким образом на андроиде вы практически всегда будете инконсистенты с экосистемой, вопрос с какой стороны.
Так же, стоит учесть AppCompat, которая по умолчанию подкрашивает вашу аппу в Material.

Мне кажется Марк своим мнением просто разделил людей на два лагеря.
А я с ним согласен. На своём Android 2.3 хочу видеть все приложения в одном стиле. На своих 4.0-4.4 Android'ах я хочу видеть Holo. Если пара приложений сделают Material, то на фоне всех остальных приложений они будут выделяться, ибо многие приложения не обновились до Material.

Так что, не всё так однозначно, всё же.

Это все справедливо, как Вы говорите. Но проблема в том, что Google с Вами не согласен и первым начинает вводить свой Material и говорить что это хорошо. Когда эти «остальные приложения» — это вся линейка Google апп, то с этим уже труднее спорить, не так ли?
Предлагаю на будущее некоторые термины оставлять на английском :)
А вообще статья хорошая. Но я пока бы воздержался от перехода, ибо в саппорте очень много багов еще, да и Build Tools новый на студии тоже порой ведет себя странновато.
А что за ViewPagerIndicator Вы используете? Или это стандартный?
Надо запасаться достаточно старыми телефонами, чтобы на них не обновились приложения до такого дизайна. Что за повсеместная мода(
Sign up to leave a comment.