Pull to refresh

Comments 33

Хорошая подборка, спасибо за перевод.
Автогенерация стилей и drawables под ActionBar/ActionBarSherlock — http://jgilfelt.github.io/android-actionbarstylegenerator/
Автогенерация стилей и deawables под контролы — http://android-holo-colors.com/
AndroidAnnotations — потрясающая либа + annotation препроцессор. Внедряет в приложение IoC, simple threading, preference management и многое другое.
http://marakana.com/s/post/1250/android_fragments_tutorial — хороший справочник по Fragments.
Добавлю свои 5 копеек: вот уже более двух лет я пишу под Андроид и за это время накопилось куча «библиотечного кода». Всё это выродилось в библиотеку (исходники — github.com/serso/android-common, maven зависимости — org.solovyev.android.*).
В библиотеку входят такие вещи как billing, lists (удобная работа с ListView), views (DragButton, SideBar, диалоги настроек), fragments, database, preferences и т.д.
К сожалению, мануала нет, но, надеюсь, что когда-нибудь появится. Примеры использования можно посмотреть в модуле samples и, например, здесь github.com/serso/android-calculatorpp.
Под постом есть плашка со статистикой. Там же есть ссылка на оригинал.
Также рекомендую взглянуть на мою библиотеку DroidParts: https://github.com/yanchenko/droidparts, значительно упрощающую рутинные операции. С недавних пор доступна в Maven Central.
Вы же знаете, что AsyncTask не рекомендуется использовать для тяжёлых задач (link)? Зачем тогда нужен progress для него? (У вас, кстати, как минимум утечка контекста + проблема с восстановлением таска при умирании активити (поворот экрана))
Правильное решение — используйте thread executor и future task, при рестарте активити — проверяйте выполняется ли таск. У меня уже есть готовое решение, но я его пока не залил в свой репозитарий, скоро будет.

PS Я на ваш репозитарий натыкался не раз — в целом мне понравилось, так что продолжайте.
У каждого свой подход.
Утечки контекста нет, т.к. там getApplicationContext().
Для регулярных фоновых тасков я использую IntentService. ExecutorServices — это уровень AsyncTask или org.droidparts.net.image.ImageFetcher workers.
Тогда каким образом вы view обновляете? Есть два способа: либо вы передаёте views (или Activity) внутрь AsyncTask, либо вы делаете внутренний анонимный класс (и захватываете Acitivity и views неявно). При повороте экрана activity убивается, это значит, что вы должны либо убить таск либо подменить activity в работающем таске. Первый способ плох тем, что вам придётся стартовать новый таск, второй — тем что он сложнее реализуем (нужно где-то хранить ссылку на task и т.д. — в это случае проще и правильнее написать, вообще, своё решение на зависящее от AsyncTask).

PS Не поймите меня не правильно — я полностью поддерживаю open source в общем и вашу библиотеку в частности. Просто указал на проблему, с которой сам недавно столкнулся и которая может проявиться при использовании вашего расширения андроидного AsyncTask'а.
Результат передаётся через AsyncTaskProgressListener, AsyncTaskResultListener, в которых Views можно подменять при повороте.
В чём преимущество самописного перед IntentService?
1. Для того чтобы что-то подменять при повороте нужно это что-то сначала сохранить в область не связаную с Activity, так? Вопрос такой: где у вас хранится AsyncTask?
2. Про IntentService — зачем усложнять жизнь? При использовании сервиса вы столкнётесь с такими проблемами — как передать не serializable объекты (тут имеются ввиду и parcelable и aidl compatible)? Как синхронно «привязать» (bind) локальный сервис? И что самое интересное — вам всё равно придётся использовать ExecutorService (потому что сервисы работают на main потоке).
1. В статической переменной, если Activity убивается.
2. Я обычно реализую общение через базу, так что передаётся только id. Если нужно передавать несереализуемое, то стоит задуматься о дизайне. Привязывать синхронно не приходилось. Не-а, IntentService работает в отдельном потоке по умолчанию.
Я решил закончить дискуссию в этом треде и написал статью о ненужности сервисов для решения бекграунд задач в Андроиде (за исключением двух случаев). Линк (к сожалению, пока только на английском языке).
это у многих андроид программистов болезнь такая — каждый пишет свой велосипед для многопоточности. ну и соотвественно, каждый утверждает, что сервисы и асинк таски — говно, а его решение все проблемы хэндлит.

На самом то деле, ваша статья отчасти не правдива. IntentService — выполняет задачи в бэкграунде, его не надо биндить, он стартуется интентом. его минус — только одна задача в одно время.
Я вот регулярно использую IntentService для синхронизации данных сервер -> локальная бд. и можно удобно общаться через LocalBroadcastManager или ResultReceiver. собственно и вся необходимость передовать сложные сериализуемые объекты отпадает.

А AsyncTaskи отлично кстати подходят для выкачивания картинок, особено в списках. есть на developer.android.com даже подробный гайд, как это правильно делать.

А еще часто идеально вписываются лоадеры.

А иногда нужно на Executorах сложную многопоточность написать с параллельными запросами.

У каждого подхода свои плюсы и минусы, мне кажется стоит их комбинировать и использовать в зависимости от ситуации. А писать свою реализацию на все случаи жизни, которая будет у каждого программиста своя, по моему не клево.
1. Любой сервис либо локальный, либо удалённый. Локальный нужно байндить, удалённый — нет.
2. Возникает вопрос — зачем всё усложнять? Зачем пихать сервисы, если они не нужны? В статье я описал два случая, когда действительно нужно использовать сервис — всё остальное только усложнение кода программы.
3. IntentService как вы написали работает только на одном потоке, помимо этого:
3.1. Неизвестно если очередь потоков
3.2. Нельзя отменить работающий таск
3.3. Нельзя проверить работает ли таск
3.4. Нельзя норамыльным образом передать результат работы (LocalBroadcastManager больше похоже на костыль)
3.5. Да и вообще — зачем он нужен? Вы используете какую-нибудь функцию сервиса для работы вашего бекграунд таска?

На самом деле всё что я хотел сказать это то, что Андроидные сервисы — это НЕ решение задачи управления тасками в бекграунде как многие думают.
вы мне укажите, где написано, что IntentService нужно биндить или что он удаленный.

IntentService хорош тем, что его легко писать, он не привязан к жизненному циклу UI и в нем реализована очередь запросов.

он вполне себе подходит для многих задач, как по мне.

я не пытался сказать, что IntentService уникален, у него есть и минусы. но мне больше нравится использовать разные подходы, доступные уже в Android SDK для разных задач, чем писать очередной AsyncRequestExecutorManager
Хорошая подборка!
ps мне не хватило 1 дня что бы закончить её перевод.
Ромена Ги вы очень плохо обозвали чужим именем. Если вы опытный разработчик — обязательно должны были смотреть видео с его участием, он правильно произносит свое имя.
Слава макаронам, мою опытность оценивают не по знанию произношения имён разработчиков гугла. Но спасибо, я поправлю.
Пытаясь программировать под android основная проблема у меня, как бекэнд разработчика, была именно в создании интерфейсов, кастомизации их под себя, под то, что требуют дизайнеры. Есть ли какой-то ресурс, книга или что-то еще где бы подробно и глубоко освещался вопрос построения интерфесов, создания собственных интерфейсных виджетов и прочего? В большинстве мест просто расказывается как накидать на форму контролов и повесить на них обработчики, а что делать если они не устраивают и нет ничего готового?
Спасибо за включение Universal Image Loader в список самых полезных библиотек, только лучше вместо ссылки на мой профиль в Google+ поставить ссылку на GitHub репозиторий. А то перекруглили уже меня.
Есть ли под Android аналог эплового GameCenter?

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

С помощью чего организуете у себя ачивки/доски рекордов?
о сторонних библиотеках для android есть неплохой, но развивающийся, сайт — www.droidbase.org. Там рассказывается о нестандартных библиотеках расширяющих базовый функционал приложения + скриншоты.
Only those users with full accounts are able to leave comments. Log in, please.