В данном материале можно будет увидеть различные инструменты и подсказки, которые здорово облегчают жизнь Android разработчикам. Большая часть собрана напрямую от знакомых разработчиков и содержит вещи, которые должен знать каждый. Дополнения и расширения приветствуются, и если вы знаете о каком-то крутом механизме, который не был упомянут в статье, не поленитесь перейти в оригинал и открыть pull request.

Совсем недавно, на собеседовании в Яндексе, мне довелось обсуждать организацию Rest-взаимодействия в Android-приложениях. В ходе обсуждения всплыл вопрос – почему из трех паттернов, предложенных на Google IO 2010 Virgil Dobjanschi, первый используется существенно чаще двух других. Вопрос меня заинтересовал.

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

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

Вторым условием является наличие ContentProvider'а, процесс написания которого разжеван в документации. Признаться честно, мне не очень нравится как там это описано: все кажется громоздким и сложным. Поэтому немного повелосипедим и еще разок пережуем эту тему. Можно было бы обойтись и провайдером-заглушкой, но мы люди серьезные и будем использовать всю мощь этого инструмента.

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

В приложении будет возможность добавлять/удалять ленты, просматривать список новостей и открывать их в браузере. Визуализировать процесс синхронизации и ее запуск будем с помощью добавленного недавно в support-library класса SwipeRefreshLayout. Почитать, что это и как использовать, можно тут.

Чтобы настраивать автоматическую синхронизацию через определенные интервалы времени, нам потребуется экран настроек этого добра. Желательно, чтобы доступ к нему был не только из приложения, но и из системного экрана нашего аккаунта (как на скриншоте к статье). Используем для этого PreferenceFragment'ы. С функциональностью определились, приступим.

Вступление

Приветствую, коллеги!

Достаточно часто при разработке мультимедийных Андроид-приложений (далее просто “приложений”) мы сталкиваемся с задачей создания собственных компонентов, не предусмотренных в системе. Это могут быть всяческие ручки-переключатели, визуализаторы спектра и т. п. Некоторые из них могут быть получены простой заменой графического ресурса, поворотом канвы на 90 градусов и т. п. Но, иногда, все же приходится делать что-то свое “с нуля”.
В этой статье я собираюсь рассказать о создании компонента — простой клавиатуры фортепиано, при помощи наследования от класса View и реализации всех внутренностей “самостоятельно”. Почему в кавычках — увидите дальше.

В серии статей я постараюсь осветить такие вопросы, как:

1. отрисовка компонента
2. добавление скроллинга с использованием стандартных скроллбаров
3. взаимодействие, использование селекторов для клавиш
4. Сохранение состояния компонента при повороте экрана
5. добавление подсветки при оверскролле
6. передача параметры в XML
7. pinch zoom

Первая статья будет о первых трёх пунктах.

Если Вам интересны эти темы, добро пожаловать под кат.

Наблюдая за со своими знакомыми, которые недавно начали изучать программирование или перешли на Eclipse c другой IDE, я часто замечаю что они почти не используют вспомогательные инструменты среды разработки. Они либо не знают о них вообще, либо не понимают какую практическую пользу они могут принести.
Данная статья предназначена в основном для начинающих в работе с Eclipse. Но в процессе подготовки статьи я сам узнал о нескольких простых и удобных инструментах, которые за два года активной разработки ни разу не использовал.
В данной статье речь пойдет о навигации и редактировании.
Внутри скриншоты.

В графическом приложении для рисования используется SurfaceView и пара Bitmap размером с экран (например, я хочу изобразить плавное листание страниц книги).

На многих устройствах с большим разрешением экрана приложение падает c ошибкой
AndroidRuntime: java.lang.OutOfMemoryError: bitmap size exceeds VM budget

Проблема в том, что память для Bitmap, а также для SurfaceView резервируется из общей кучи процесса. Лимит размера кучи — невелик, как правило немногим больше 10Мб. И задается этот лимит при сборке системы.

Попытки улучшить ситуацию урезанием формата пикселя с 32 бит до 16 не слишком помогают. Проблема просто вылезает позже — например, при открытии окна поверх SurfaceView (видимо, при этом создается еще один Bitmap размером с экран).

Ограничение размера графических буферов программы в 3-4 экрана — это до обидного мало! Попробуем исправить такую несправедливость.

Вот признайтесь: читая Android Interface Guidelines, вам не приходила мысль, что это все, конечно, офигенно, но на старые (2.3 <) Андроиды приходиться перелопачивать половину стилей, чтобы смахивало на Holo интерфейс?

Или так: в последнем Андроиде есть ну просто офигенная фича, а вам вот нужно ее использовать?

Самое первое, что приходит на ум: ActionBar и ActionBarSherlock.
ABS — это замечательно, но одним ActionBar не отделаешься. Мы хотим Holo тему, а не только Holo бар, блин.

Эх, такой привлекательный ActionMode на списках чего стоит…

Позвольте представить вам HoloEverywhere — проект, целью которого является портирование Holo стиля, Holo виджетов и других фишек на Android 1.6 и старше.

При создании портала крайне часто основной функцией BackEnd является работа с БД. Как правило сейчас никто не использует обычные и не очень удобные для написания Statement’ы, а в место этого используют ORM фреймворки. В случае с GWT этим фреймворком скорее всего становится Hibernate, так как на сервере у нас Java. Мне далеко не первому пришла в голову мысль о том, что крайне удобно и просто было бы передавать не отдельные данные а целиком POJO(персистентные объекты) используемые Hibernate. Вот я создал свой сервис, возвращающий на клиентскую часть POJO. POJO пронаследовал от Serializable. Запускаю приложение и получаю вот такое вот исключение:

Caused by: com.google.gwt.user.client.rpc.SerializationException: Type 'org.hibernate.collection.PersistentSet' was not included in the set of types which can be serialized by this SerializationPolicy or its Class object could not be loaded. For security purposes, this type will not be serialized.
at com.google.gwt.user.server.rpc.impl.StandardSerializationPolicy.validateSerialize(StandardSerializationPolicy.java:83)
at com.google.gwt.user.server.rpc.impl.ServerSerializationStreamWriter.serialize(ServerSerializationStreamWriter.java:591


Не сразу понятно что пошло не так. Дело в том, что как только объект становится персистентным, в нем происходит ряд изменений, необходимых для работы Hibernate. Например обычные Set меняются на PersistentSet. Из-за этого браузер уже никак не может десериализовать отправленный ему объект, ни при каких условиях.