Всем привет!

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

Новость, которая должна понравиться разработчикам, крупным и мелки — корпорация Google добавила функцию периодических платежей (подписок) в Google Play. Так что для создателей игровых приложений, да и не только игровых, а платных приложений вообще, наступает приятное время. Добавление подписок в приложения может увеличить доход разработчика, и весьма значительно.

Введение

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

Во-первых, в эмуляторе Android появилась поддержка аппаратного видеоускорения, что позволяет с полной скоростью работать не только интерфейсу, но и тестировать программы, использующие OpenGL ES 2.0.

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

Сказано — сделано: создаём канву проекта по андроидному Tutorial'у, достаём с полки старые Direct3D-проекты с использованием загрузки файлов .3ds, рендера-в-текстуру и пачки шейдеров, переписываем на Java и OpenGL ES 2.0, получаем то, что на картинке. Текст поздравления и тому подобное добавим потом.

Вся информация по использованию OpenGL ES 2.0 на Android оказалась сильно разрозненной, знания собирались по крупицам… Надеюсь, этот пост поможет тем, кто в будущем столкнётся с теми же трудностями, что и я.

А теперь подробнее.

Данная статья является эдаким приквелом к моему прошлому посту, посвящённому Glow-эффекту. Я обещал рассказать, как загружать файлы .3ds, чтобы отрисовывать их с применением использованных там шейдеров.

Некоторую общую информацию о формате файла можно прочитать, например, в википедии или в demo.design 3D programming FAQ, однако это всё теория (причём, написанная не без ошибок), а здесь мы поговорим о практике, причём применительно к Java и Android.

Что здесь будет:

• довольно шустрое чтение всего файла (на телефоне двухмегабайтный файл грузится за пару секунд);
• загрузка всей модели, вычисление нормалей, загрузка текстурных координат;
• вся информация о материалах, источниках света;
• загрузка анимации и иерархии объектов.

Чего здесь не будет:

• загрузки самих текстур (мне пока не понадобилось, хотя реализуется легко);
• загрузки информации о камерах (опять же, легко добавить, но не пригодилось);
• использования групп сглаживания для вычисления нормалей (не уверен, что это вообще нужно) (всё-таки будет);
• использования сплайнов для анимации.

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

Этой статьёй я открываю цикл, посвящённый разработке Android-приложений. Но не типичных для Google Play, написанных, очевидно, задней левой mНогой, а приложений корректных и элегантных. В этом деле нам поможет DroidParts — швейцарский нож Android-библиотек с 8 лезвиями:

1. Dependency Injection: инициализация системных и собственных зависимостей;
2. Object-Relational Mapping для SQLite: CRUD-операции «из коробки»;
3. Поддержка Fragments, ActionBarSherlock;
4. Простая (де-)сериализация JSON;
5. AsyncTasks, IntentService с обработкой Exсeptions;
6. RESTful HTTP client с поддержкой JSON;
7. L.og без указания тега, конфигурируемый через AndroidManifest;
8. Утилиты типа асинхронного http-загрузчика с кешированием, View- и Intent-помощников.

Буквально час назад* увидела свет первая версия библиотеки, но сначала…

В позапрошлой своей статье, посвящённой созданию открытки средствами OpenGL под Android, я оставил фразу «текст поздравления добавим позже». Так вот, время пришло.

Текст будет выглядеть примерно так, как на картинке, за исключением того, что он слегка мерцает, каждая «звёздочка» плавно исчезает и появляется (кроме того, в финальном варианте и сам текст другой, и цвет не тот, и размеры шрифта и частиц тоже). Нарисован он с помощью анимированной системы частиц, причём в массиве вершин задаются лишь координаты центра каждой точки и некий «сдвиг по фазе» для анимации, ну а сама анимация сделана через шейдеры.

Отрисовка частиц осуществляется механизмом Point Sprites, который как раз и создан для таких случаев. Основная его особенность в том, что мы задаём лишь координаты центра точки и её размер, а OpenGL сам генерит нам по четыре угловых вершины и два треугольника, включая их пространственные и текстурные координаты, для отрисовки множества одинаковых (в смысле, имеющих одну и ту же текстуру) квадратных картинок. Итак, заглянем под ка[по]т.

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

Два взгляда на проблему

Как известно, в университетах учат строить базы данных по всем правилам: декомпозировать предметную область на сущности, выделить атрибуты и определить первичные ключи, определить отношения между сущностями, привести все это, как минимум, к 3-ей нормальной форме и т.д. Один из “побочных” эффектов такого подхода — падение производительности на операциях чтения, при достаточно сильной декомпозиции и нормализации, так как в запросах необходимо выполнять большее количество джойнов. И чем больше у вас записей в таблицах, тем дольше они выполняются.

Добавим сюда сильно ограниченные аппаратные возможности мобильных платформ, в частности крохотный объем оперативной памяти. Ее и без того мало, так в дополнение к этому, Android ограничивает количество доступной RAM на процесс в зависимости от версии ОС от 16 до 48 МБ. И даже из этих нескольких мегабайт СУБД получает лишь часть, ведь есть еще и само приложение. Ну и в заключение, сам SQLite, в виду своих особенностей поддерживает только два уровня изолированности транзакций. Они либо сериализуются, либо вообще отключены!

В ситуации когда производительность приложения начинает упираться в производительность СУБД на помощь и может прийти альтернативный подход, назовем его key-value ориентированным. Вместо декомпозиции сущности на атрибуты и создания отдельных полей в таблице на каждый атрибут, сущность сохраняется “как есть” в одно единственное поле типа BLOB, иначе говоря сериализуется.

При работе над фронтом для кафе появилась задача обращаться к веб-сервису 1С из приложения, разрабатываемого на Android. Google мне дал несколько ответов на тему как вообще работать с SOAP, используя библиотеку ksoap2-android. Они помогли в передаче простых типов, но когда дело дошло до передачи массива, пришлось немного подумать.