Нет, я не могу этого сделать даже на своём телефоне, не говоря уже о множестве всех остальных. Слишком много факторов влияет на это. Но для записи файла в сотню-другую килобайт аннотация @ Background вполне подойдёт.
AndroidAnnotations. Мощнейший инструмент, главное не юзать Background
Не согласен. Напротив, пару аннотаций @ Background, @ UiThread считаю очень эффективной. Да, не для каждой задачи подойдёт @ Background, т.к. высок риск мемори ликов, но для задач, которые наверняка выполнятся быстро, но которые нельзя делать в UI потоке — это отличное решение. Например, запись в файл, сохранение настроек, небольшие выборки из БД и пр. Разумеется сетевые запросы не стоит делать в @ Background, для этого нужны совершенно другие подходы. Главное, понимать, как работает это всё «под капотом» и, как выразился автор поста, " включать голову".
Спасибо за статью. Однако данный способ почему-то работает для сборки debug версии. При сборке release версии в apk не включаются нативные библиотеки. Попросту в apk нету папки lib с .so либами.
Создавать кастомный вью и бегать по иерархии вью — не лучшие способы. Я использую кастомный LayoutInflater.Factory. Полный код класса и пример использования можно посмотреть здесь
На одном из проектов стояла такая же задача. Причём необходимо было реализовать загружаемые извне скины, что не позволяло использовать механизм тем. Очевидные недостатки подхода, описываемого в статье — наследование от кастомной активити и применение механизма рефлексии. Разработанный нами подход лишён этих недостатков. Он основан на кастомной фабрике вьюшек, которую можно засетить в инфлейтер методом LayoutInflater.setFactory(). В этой фабрике в методе LayoutInflater.Factory.onCreateView() нам доступны все атрибуты создаваемого вью, а значит мы можем узнать значения background, drawableLeft/Top/Right/Bottom, textColor и другие и засетить их созданному вью из своей кастомной темы. Недостатком подхода является то, что тема автоматически применяется только если создавать вью при помощи inflater (что и делается в 95% случаев). Если вью создается программно, то требовались дополнительные телодвижения. Код, к сожалению предоставить не могу, но идея, в целом, думаю, ясна.
Взаимодействие через Intent — это действительно удобно. Но удобно скорее разработчикам. Далеко не всегда это решение удовлетворяет пользователей и заказчиков. Есть достаточно много недостатков этого подхода:
— нет контроля над списком приложений, которые могут откликнуться на этот intent. Список может быть очень большим, и в нем могут присутствовать приложения, которые могут обескуражить пользователя, например dropbox.
— нет возможность кастомизации диалога выбора приложения;
— нет гарантии, что внешнее приложение отработает так, как я ожидаю. Например Facebook расшаривает только ссылки, но не текст
— пользователь должен обязательно установить внешнее приложение;
— чаще всего требуется расшаривание только в определенные социалки, и на UI должны быть кнопки, явно обозначающие, кто будет заниматься расшариванием.
— … и некоторые другие.
В какой-то момент я устал убеждать заказчиков, что Intent — это дешево и really android way и сделал свой простой sharekit, который включает в себя fb sdk, неофициальный vk sdk, умеющего расшаривать в различные социалки и покрывающий все названные мной проблемы.
>Также есть фоновые запросы к серверу, которые по таймеру запрашивают данные все время работы приложения(это могут быть запросы на кол-во новых сообщений, инвайты в друзья, изменение баланса валюты внутри приложения и тд).
Такой подход никуда не годится, для этих целей необходимо использовать Push Notifications (GCM в android). Это позволит снизить трафик до минимума, а интерактивность повысить до максимума.
Слишком много ручной работы при авторизации: WebView, куки, разбор ответа. В каждом проекте клиентскому коду необходимо выполнять все то, что у вас находится в LoginActivity в примере. Почему бы не вынести все это в вашу библиотеку? В качестве примера смотрите facebook android sdk, где для авторизации вызывается один метод с необходимыми параметрами и колбеками, а библиотека берет на себя всю работу по открытию WebView в диалоге и прочую нудную работу. Хорошей фичей facebook android sdk также является то, что он может использовать нативное приложение facebook для авторизации, если оно установлено. Это тоже можно добавить в вашу библиотеку.
Как говорит документацияAll requests are handled on a single worker thread — they may take as long as necessary (and will not block the application's main loop), but only one request will be processed at a time. То есть предложенный подход не позволяет выполнять 2 и более запросов одновременно. Верно?
Шерлок — имплементация ActionBar для пре 11-го андроида. Сompatibility-library не содержит ActiobBar. Рекомендация от Google — использовать Action Bar Compatibility
Предпочитаю использовать google http client, а не самописные решения. Библиотека использует ту или иную реализацию http клиента в зависимости от версии платформы и предоставляет удобный апи для разбора ответа. Ну и множество других плюшек, разумеется.
Не согласен. Напротив, пару аннотаций @ Background, @ UiThread считаю очень эффективной. Да, не для каждой задачи подойдёт @ Background, т.к. высок риск мемори ликов, но для задач, которые наверняка выполнятся быстро, но которые нельзя делать в UI потоке — это отличное решение. Например, запись в файл, сохранение настроек, небольшие выборки из БД и пр. Разумеется сетевые запросы не стоит делать в @ Background, для этого нужны совершенно другие подходы. Главное, понимать, как работает это всё «под капотом» и, как выразился автор поста, " включать голову".
— нет контроля над списком приложений, которые могут откликнуться на этот intent. Список может быть очень большим, и в нем могут присутствовать приложения, которые могут обескуражить пользователя, например dropbox.
— нет возможность кастомизации диалога выбора приложения;
— нет гарантии, что внешнее приложение отработает так, как я ожидаю. Например Facebook расшаривает только ссылки, но не текст
— пользователь должен обязательно установить внешнее приложение;
— чаще всего требуется расшаривание только в определенные социалки, и на UI должны быть кнопки, явно обозначающие, кто будет заниматься расшариванием.
— … и некоторые другие.
В какой-то момент я устал убеждать заказчиков, что Intent — это дешево и really android way и сделал свой простой sharekit, который включает в себя fb sdk, неофициальный vk sdk, умеющего расшаривать в различные социалки и покрывающий все названные мной проблемы.
Такой подход никуда не годится, для этих целей необходимо использовать Push Notifications (GCM в android). Это позволит снизить трафик до минимума, а интерактивность повысить до максимума.
А пока что слишком сложно, ищу альтернативы.
Именно так я и сделал.
Спасибо за совет, даже не смотря на форму, в которой он был дан.
Обфускатор на ура отсекает неиспользуемый код, в результате чего размер приложения становится минимальным, сколько бы зависимостей ни тянул проект.