Следует начать с того что все приложения для ОС Android распространяются в виде инсталляционных пакетов - файлов с расширением APK.

APK (Android Package) -- формат архивных исполняемых файлов-приложений для Android.

Каждое приложение Android скомпилировано и упаковано в один файл, который включает в себя весь код приложения (.DEX файлы), ресурсы, активы и файл manifest. Файл приложения может иметь любое имя, но расширение должно быть.APK. Например: myAppFile.apk.

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

Файлы этого формата не шифруются, являются подмножеством формата архива ZIP.

Каждый.APK файл -- это сжатый архив для исполнения в DalvikVM (виртуальная машина), который может быть установлен не только на операционной системе Android.

APK файл как архив обычно содержит следующие директории:

· META-INF:

§ MANIFEST.MF: манифест файл

§ CERT.RSA: сертификат приложения

§ CERT.SF: список ресурсов и их SHA1 хеш-сумма например на Рисунке 6:

· Signature-Version: 1.0

· Created-By: 1.0 (Android)

· SHA1-Digest-Manifest: wxqnEAI0UA5nO5QJ8CGMwjkGGWE=

· Name: res/layout/exchange_component_back_bottom.xml

· SHA1-Digest: eACjMjESj7Zkf0cBFTZ0nqWrt7w=

· Name: res/drawable-hdpi/icon.png

· SHA1-Digest: DGEqylP8W0n0iV/ZzBx3MW0WGCA=

Рисунок 6. Структура файла со списком ресурсов и их хеш-сумм.

· Директория lib: содержит скомпилированный исполняемый код адаптированный под различные типы процессоров, обычно разделена на следующие директории:

Ш armeabi: код только для ARM процессоров

Ш armeabi-v7a: код для для процессоров ARMv7 и ниже только.

Ш x86: скомпилированный код только для архитектуры x86

Ш mips: скомпилированный код только для архитектуры MIPS

· Директория res: директория содержит файлы ресурсы не вошедшие в файл resources.arsc(см. ниже)

· Директория assets: содержит активы которые могут получены с помощью AssetManager

· Файл AndroidManifest.xml: дополнительный манифест файл, описывающий версию приложения, разрешения, используемые библиотеки. Как правило это файл идёт в формате binary XML, это формат файлов можно привести к читаемому виду с помощью сторонних утилит таких как AXMLPrinter2, apktool, или Androguard.

· Файл classes.dex: исполняемый файл виртуальной машины Dalvik, полученный путём преобразования скомпилированных JAVA классов с помощью утилиты DX. Утилита входит в состав Android SDK.

· Файл resources.arsc: файл содержит пре-компилированные ресурсы, например в виде бинарных XML файлов.

Из всего выше обозначенного в данной работе при анализе уровня опасности будут использоваться только два файла это AndroidManifest.xml и classes.dex. Ни их структуре остановимся более подробно.

AndroidManifest.xml

Данный файл, как уже говорилось ранее, содержит информацию о приложении, в том числе список требуемых разрешений приложения. В том числе на основе этих данных можно ранжировать уровень опасности приложения. Обратимся как его структуре: в первую очередь необходимо отметить что в установочном пакете androidmanifest.xml имеет бинарный вид, то есть преобразованный xml, хотя в оригинальном состоянии этот файл имеет структуру, обозначенную на Рисунке 7:

Рисунок 7. Подтверждение установки приложения из стороннего источника.

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

В Таблице 1 приведены некоторые разрешения которые представляют наибольшую опасность:

Таблица 1. Описание некоторых опасных разрешений в ОС Android.

ACCESS_COARSE_LOCATION	Приложение сможет получить доступ к приблизительному местоположению, полученному из сетевого расположения источников, таких как вышки сотовой связи и Wi-Fi.
ACCESS_FINE_LOCATION	Приложение сможет получить доступ к точному местоположению от места расположения источников, таких как GPS, вышек сотовой связи и Wi-Fi.
CALL_PHONE	Приложение сможет инициировать телефонный звонок, минуя пользовательский интерфейс Dialer для пользователя.
	Приложение сможет сделать снимок встроенной камерой
DELETE_PACKAGES	Позволяет приложению удалять пакеты.
DEVICE_POWER	Позволяет приложению отключить питание устройства

Как видно из описаний некоторые разрешения можно группировать, выставив при этом уровень опасности целой группе функций, например разрешения READ_SMS, BRICK являются очень опасными и им можно присвоить уровень опасности 10(максимальный). Это вызвано тем, что под разрешением READ_SMS понимается чтение личных данных пользователей, что является потенциально опасным для пользователя действием со стороны приложения. Под BRICK понимается отключение устройства в целом - что тоже очень опасно для пользователя потому что устройство полностью прекращает свою работу.

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

Данный файл носит в себе основной функционал приложения, содержит байт-код, понятный виртуальной машине Dalvik. Имеет следующую внутреннюю структуру, представленную в Таблице 2:

Таблица 2. Структура Dex файла.

На самом деле это файл, содержащий в себе программный код для виртуальной машины Dalvik. Приложения для Android пишутся на языке Java, но после компиляции кода в.class-файлы, вызывается утилита dx, которая транслирует их в один файл classes.dex, являющийся основной составляющей APK файла. Общий алгоритм формирования dex представлен на Рисунке 8.

Рисунок 8. Механизм формирования файла classes.dex.

Следует отметить, что функционирование данного файла абсолютно связано с использованием API операционной системы. При этом исходный код приложения написан на объектно-ориентированном языке программирования JAVA. И является своего рода компиляцией в компиляции. Как следствие состоит из большего числа строк, содержащих имена методов API, имена различных констант. Вся эта информация может явным образом служить для понимания функционала приложения и как следствие ранжирования его уровня опасности, опираясь на использованные наборы API функций.

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

Есть четыре стандартных блока приложения Android:

- Activity .

- Intent Receiver .

- Service .

- Content Provider .

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

Как только Вы решили, в каких компонентах Вы нуждаетесь для своего приложения, Вы должны перечислить их в файле по имени AndroidManifest.xml. Это - файл XML, где Вы объявляете компоненты своего приложения и каковы их возможности и требования. Мы скоро обсудим, за что AndroidManifest.xml ответственен.

(Это могло быть написано ОЧЕНЬ криво. Тут много текста и никаких картинок примеров. Рекомендую потерпеть и прочесть эту теорию, зато потом Вам будет понятней. Потом все написано гораздо глаже, не волнуйтесь)

Activity

Activity – самый распространенный из четырех стандартных блоков Андроид. Activity обычно - единственный экран в Вашем приложении. Каждый Activity осуществлен как единственный класс, который расширяет базовый класс Activity. Ваш класс отобразит пользовательский интерфейс, составленный из Views, и ответит на события. Большинство приложений состоит из множественных экранов. Например, у приложения обмена сообщениями мог бы быть один экран, который показывает список контактов, второй экран, чтобы написать сообщение выбранному контакту, и другие экраны, чтобы делать обзор старых сообщений или изменить настройку. Каждый из этих экранов был бы осуществлен как Activity. Перемещение в другой экран достигнуто стартом нового Activity. В некоторых случаях Activity может возвратить значение предыдущего Activity - например Activity, которая позволяет пользователю выбирать фотографию, возвратил бы выбранную фотографию вызывающей программе. Когда новый экран открывается, предыдущий экран приостановлен и помещен на стек хронологии. Пользователь может переместиться назад через ранее открытые экраны в хронологии. Экраны могут также хотеть быть удаленными от стека хронологии, когда было бы неуместно для них остаться. Андроид сохраняет стеки хронологии для каждого приложения, начатого от начала экрана.

Intent и фильтры Intent

Андроид использует специальный класс под названием Intent, чтобы двигаться от экрана к экрану. Intent описывает то, что приложение собирается сделать. Две самых важных части структуры Intent - действие и данные к действию. Типичные значения для действия – MAIN (главный экран приложения), VIEW, PICK, EDIT, и т.д. Данные выражены как Uniform Resource Indicator (URI). Например, чтобы рассмотреть веб сайт в браузере, Вы создали бы Intent с действием VIEW и набором данных – адресом сайта.

new Intent(android.content.Intent.VIEW_ACTION , ContentURI.create ("http://anddev.org"));

Есть связанный класс, названный IntentFilter. В то время как Intent - запрос сделать кое-что, IntentFilter - описание того, что Intent Activity (или intent receiver, см. ниже), способен к обработке. Activity, который в состоянии отобразить информацию для человека, издала бы IntentFilter, который сказал, что знает, как обработать VIEW действия. Activity издает свой IntentFilters в файле AndroidManifest.xml.

Навигация от экрана к экрану достигнута достигается с помощью Intent. Чтобы переместиться вперед, Activity вызывает startActivity (myIntent). Система тогда смотрит на IntentFilter для всех установленных приложений и выбирает Activity, Intent которого фильтрует myIntent. Новому Activity сообщают о Intent, которое заставляет его начаться. Процесс решения Intent происходит, когда startActivity вызывают. Процесс предлагает две ключевых льготы:

Действия могут многократно использовать функциональные возможности от других компонентов, просто делая запрос в форме Intent.

Действия могут быть заменены в любое время новым Activity с эквивалентным IntentFilter.

Intent Receiver

Вы можете использовать IntentReceiver, когда Вы хотите, чтобы код в своем приложении выполнился в реакции на внешнее событие, например, когда телефон звонит, или когда сеть передачи данных доступна, или когда это - полночь. Intent Receiver не отображают UI, хотя они могут отобразить Уведомления, чтобы привести пользователя в готовность, если кое-что интересное случилось. Поглощенные получатели также регистрированы в AndroidManifest.xml, но Вы можете также регистрировать их в коде, используя Context.registerReceiver(). Ваше приложение не должно работать для его Intent Receiver, которые вызываются; система запустит Ваше приложение, в случае необходимости, когда Intent Receiver будет вызван. Приложения могут также послать свои собственные Intent Receiver другим с Context.broadcastIntent().

Service

Service - код, который долговечен и выполняется без UI. Хороший пример этого - универсальный проигрыватель, запускающий песни из плейлиста. В приложении универсального проигрывателя, вероятно, были бы одно или более Activity, которые позволяют пользователю выбирать песни и запускать их. Однако, воспроизведение самой музыки не должно быть обработано Activity, потому что пользователь будет ожидать, что музыка продолжит играть даже после сворачивания проигрывателя. В этом случае, деятельность универсального проигрывателя могла запустить Service, используя Context.startService(), чтобы работать на заднем плане и сохранить воспроизведение музыки. Тогда система сохранит воспроизведение музыки, пока оно не закроется само. (Вы можете узнать больше о приоритете, данном службам в системе, читая Цикл Жизни Приложения Андроид). Отметьте, что Вы можете соединиться с Service (и запустить его, если он уже не работает) с методом Context.bindService(). Когда есть подключение с Service, Вы можете общаться с этим через интерфейс, выставленный Service. Для Service музыки это могло бы позволить Вам приостанавливать, перематывать, и т.д.

Content Provider

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

Пользовательские интерфейсы Андроид

Пользовательские интерфейсы (UI) в Андроид могут быть созданы двумя путями, через XML-код или в java-коде. Создание структуры графического интерфейса пользователя в XML очень предпочтительно, потому что по принципу Образцового управления средства просмотра, UI должен всегда отделяться от логики программы. К тому же, приспосабливание программы от одной разрешающей способности экрана до другой намного более просто. Определение UI в XML очень похоже к созданию общего документа HTML, где Вы имеете то есть такой простой файл:

The content of the body element.

Все равно как в Андроидовских XML-Layouts. Все хорошо структурировано и может быть выражено древовидными структурами:

android:orientation="vertical"

android:layout_width="fill_parent"

android:layout_height="fill_parent">

android:layout_width="wrap_content"

android:layout_height="wrap_content"

android:text="Hello World"/>

Иерархия Элементов Экрана

Основной функциональный модуль приложения Android - Activity - объект класса android.app.activity. Activity может сделать много вещей, но отдельно у него нет присутствия на экране. Чтобы дать Вашему Activity присутствие на экрана и проектировать его UI, Вы работаете с Views и Viewgroups - основными единицами выражения пользовательского интерфейса на платформе Андроид.

Views

View - объект, расширяющий базовый класс android.view.view . Это - структура данных, свойства которой сохраняют Layouts и информационное наполнение для определенной прямоугольной области экрана. Объект View обрабатывает измерение, его схему размещения, рисунок, изменения центра, прокрутку, и клавиши/знаки для области экрана, которую он представляет. Класс View служит базовым классом для всех графических фрагментов - ряд полностью осуществленных подклассов, которые рисуют интерактивные элементы экрана. Графические фрагменты обрабатывают свое собственное измерение и рисунок, таким образом Вы можете использовать их, чтобы создать Ваш UI более быстро. Список доступных графических фрагментов включает TextView, EditText, Button, RadioButton, Checkbox, ScrollView и т.д.

Viewgroups

Viewgroup - объект класса android.view.viewgroup. Viewgroup - специальный тип объекта View, функция которого - содержать набором View и Viewgroup и управлять ими. Viewgroups позволяют Вам добавлять структуру к Вашему UI и создавать сложные элементы экрана, к которым можно обратиться как к единственному объекту. Класс Viewgroup служит базовым классом для Layouts - ряда полностью осуществленных подклассов, обеспечивающего общие типы Layouts экрана. Layouts дают Вам способ встроить структуру для ряда View.

UI с древовидной структурой

На платформе Андроид Вы определяете UI Activity использование дерева View и Viewgroup узлов, как показано в диаграмме ниже. Дерево может быть столь же простым или сложным, как Вы его сделаете, и Вы можете построить его, используя наборы предопределенных графических фрагментов и Layouts Андроида, или заказных типов View, которые Вы создаете самостоятельно.

UI Андроид – древовидная структура.

Чтобы прикрепить дерево к экрану и отрендрить его, Ваш Activity вызывает свой метод setContentView() и передает информацию на корневой объект узла. Как только у система Андроид получает информацию на корневой объект узла, она начинает работать непосредственно с узлом, чтобы измерить, и отрисовать дерево. Когда Ваш Activity становится активным и получает приоритет, система регистрирует Ваш Activity и просит корневой узел измерить и отрисовать дерево. Тогда корневой узел просит, чтобы его дочерние вершины отрисовали себя - в свою очередь, каждый Viewgroup узел в дереве ответственен за отрисовку его прямых дочерних узлов. Как упомянуто ранее, у каждой группы View есть ответственность измерения ее доступного пространства, расположения ее дочерних узлов, и вызов draw() на каждом дочернем узле, чтобы позволить все им рендрить себя. Дочерние узлы могут просить размер и местоположение в родителе, но у родительского объекта есть конечное решение, где и насколько большой каждый ребенок может быть.

Сравнение Андроида Элементы UI к Swing Элементы UI

Поскольку некоторые разработчики, которые читают это, возможно, нашли, что UIs схож с Swing, сейчас будет немного общих черт между Андроидом и Swing.

Activity в Андроид - почти (J) Frame в Swing.

View в Андроид - (J) Component в Swing.

TextViews в Андроид - (J) TextField в Swing.

EditTexts в Андроид - (J) TextField в Swing.

Button в Андроид - (J) Button в Swing.

Установка слушателей к View в Андроид является почти тем же самым, чем и в Swing.

myView.setOnClickListener(new OnClickListener(){ ...

myButton.addActionListener(new ActionListener() {...

Разрабатывать под Android я начал относительно недавно (3 месяца назад) и первое с чем столкнулся - очень малое количество "русскоязычного" материала по этой теме, особенно, касательно таких вопросов как продумывание интерфейса или использование встроенных фич среды Android. Все что я находил, в большинстве своем, сводилось или к переводу статей с http://developer.android.com или примерами решающими конкретную задачу.

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

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

Конкретно в этой статье пойдет речь о программном обеспечении, необходимом для начала разработки под Android, литературе и немного о структуре приложения.

Быстрый старт

Для начала разработки вам необходимо 2 вещи: Android SDK (можно скачать с http://developer.android.com/intl/zh-TW/sdk/index.html) и, собственно, среда разработки.

SDK устанавливается через интернет (сам установочный модуль весит немного, на момент когда начинал я - около 10 Мб). Запустив установочный модуль (SDK Setup.exe) сразу запустится проверка репозитория на наличие обновлений API и прочих приблуд, по умолчанию ваше SDK пустое, и по любому для начала работы надо будет что-то из предложенного выбора обновлений скачать. Внимание! Возможно возникнет проблема соединением с репозиторием, для того чтобы её решить нужно перейти в Settings и поставить галочку напротив "Force https: \\ что-то там еще..." и попробовать соединится с репозиторием снова.

Размер загружаемого контента будет зависить от вашего выбора (в текущем варианте около 1 Гб). Для того чтобы ускорить загрузку, можно ограничить свой выбор 1 - 2 модулями (например SDK Platform Android API 1.5 и 2.0). В целом, все зависит от того под какую версию Android-а вы планируете разрабатывать. Наиболее популярные на данный момент версии API: 1.5, 1.6, 2.0. Лично я качал все...

Внимание! Учтите тот факт, что это вам не iPhone! Платформа постоянно растет и развивается и то что хорошо компилилось на Android API 1.5, под 2.0 вам выдаст предупреждение о том, что вы пользуетесь устаревшими библиотеками или методами (эх, Java ;-)). Плюс, в новых версиях API доступны методы недоступные в более ранних, для того чтобы наглядно увидеть какие библиотеки поддерживает данное API, можно на http://developer.android.com/intl/zh-TW/reference/android/app/Activity.html в правом верхнем углу поставить галочку напротив надписи "Filter by API level" и указать интересующую вас версию API (по состоянию на март 2010 года - максимальная 7-ка).

Увидеть загруженные модули можно перейдя по вкладке "Installed Packages". Обновить и удалить их можно там же.

Итак, SDK вы загрузили... теперь требуется создать эмуляторы для отладки ваших приложений. Для того чтобы создать эмулятор, необходимо в том же модуле загрузки, перейти по вкладке Virtual Device. В открывшемся окне перед вами появится таблица (сначала пустая) со списком созданных эмуляторов. Функционал окна позволяет вам создавать, удалять, "ремонтировать" (данную функцию никогда не использовал), просматривать информацию и запускать эмуляторы. Нажав на кнопку "New" вы попадете в мастер создания эмуляторов.

В мастере, вам необходимо указать имя эмулятора, целевую платформу (выпадающий список Target), объем SD карты памяти (обратите внимание, по умолчанию, объём в Мб), скин (тип и разрешение экрана устройства), а так же поддерживаемое "железо": поддержка камеры, работы батареи, GPS и т.д. (нажав на кнопку "New" вы попадает в окно выбора свойства эмулятора и его значения).

Для завершения создания эмулятора нужно нажать на "Create AVD". Внимание! После создания эмулятора невозможно поменять его свойства. Если вам необходим эмулятор с другими свойствами - то прийдется создавать новый. После создания эмулятора, считайте, что пол пути для "быстрого" старта уже пройдено...

Теперь переходим к среде разработки. Выбор тут у нас невелик: или ставим плагин под Eclipse/NetBeans (http://developer.android.com/intl/zh-TW/sdk/eclipse-adt.html и http://kenai.com/projects/nbandroid/ , соответственно) или качаем уже собранную IDE (например, MOTODEV Studio for Android 1.1 с сайта http://developer.motorola.com/docstools/motodevstudio/). Впринципе, установив плагин под Eclipse в конечном итоге вы и получите, почти, MOTODEV Studio for Android 1.1, но вам нужна эта возня??? Что же касается плагина под NetBeans, то я не знаю в каком он состоянии сейчас, но та версия с которой мне приходилось работать не имела визуального редактора UI, что, мягко говоря, тормозило работу.

Лично мой выбор пал на второй вариант (MOTODEV Studio рулит;-))... Всю необходимую информацию по установке и настройке среды разработки, вы найдете без проблем погуглив с пол часика.

Чтиво

Наличие русскоязычной литературы по разработке под Android, лично я, пока не наблюдал. Поэтому сразу перейдем к англоязычному контенту... Итак, для меня стали Библией Android: Apress Beginning Android и Apress Pro Android.

В этих книгах достаточно популярно и доступно описывается что, зачем и почему, а так же приводятся достаточно понятные примеры... Стоит отметить, что обе книги в качестве базы рассматривают платформу Android 1.5, версии книг под 2.0 (Apress Beginning Android 2 и Apress Pro Android 2, соответственно) хоть и присутствуют на сайте издателя, для загрузки мне еще не попадались.

Много справочного материала (правда с частично неработающими примерами;-)) есть на основном сайте проекта (http://developer.android.com), полезным будет не только почитать реферы и DevGuide но и посмотреть видео уроки.

Структура

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

Итак, условно, приложение под Android состоит из 3-х блоков:

1. Манифест (AndroidManifest.xml) - дескриптор файла приложения, обязательный элемент, в котором определены такие страшные штуки как: activities, content providers, services, intent receivers (о них пойдет речь в следующих статьях). А так же в манифесте вы можете описывать "разрешения" (permissions) необходимые для работы вашего приложения. Более подробно манифест я планирую описать в следующих статьях.
2. Папка "src" - папка содержащая весь исходный код программы, является обязательной.
3. Папка "res" - самая вкусная папка, в ней содержаться все "ресурсы" приложения;-) Вы пока еще об этом не знаете, но она сильно вам облегчит жизнь, более того, я бы сказал, что самое ВСЕ разработчика для Android. Наличие данной папки для проекта обязательно.

Кроме того, корневая папка приложения может еще содержать в себе папку "assets", данная папка не обязательна и может содержать в себе различные вспомогательные ресурсы (другие папки и файлы).

И еще одна тонкость... В корень приложения можно забросить папку "libs", в которую, в последующем можно будет добавить нативные С/С++ библиотеки (о них мы тоже как-нибудь поговорим, но позже).

В процессе сборки приложения, появится папка "gen" с вложенным пакетом и файлом R.xml - это тоже очень полезный файл, в котором содержаться дисрипторы ресурсов, генерится средой разработки и лезть туда руками крайне не рекомендуется.

Ресурсы (кроме графических) как и манифест представленны в виде XML файлов. И те кто что-то понимает в Java EE сразу для себя найдут много сходного, и будут правы... Структуру XML для различных типов ресурсов я так же планирую расписать в следующих статьях, а пока лишь распишу вкратце содержимое папки "res":

1. drawable -папка, которая содержит файлы с графическим контентом а так же xml-предписания работы с ними, не обязательна.
2. anim - папка, в которой содержаться xml-файлы с описанием анимации.
3. layout - папка, содержит xml описание слоем для реализации UI.
4. values - папка - контейнер для таких xml-файлов как: strings, styles, colors, dimens, arrays (контент обозначенных файлов соответствует их названию).
5. xml - папка содержащая различные xml-файлы вспомогательного характера.
6. raw - папка для хранения не XML данных используемых в приложении.

Казалось бы, судя по структуре все и так понятно... Но уверяю вас - это только вершина айсберга. Путем нехитрых манипуляций с этими папками и их контентом можно достаточно легко реализовывать такие вещи как интернационализация и локализация вашего приложения, а так же реализовать, примерно, до 80% работы с вашим UI.

Подводя итоги

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

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

Поскольку разработка приложений под Android набирает популярность, думаю обзор основных UI паттернов для Android-приложений будет кому-то полезен. Основой для статьи является вот этот вот источник. Рассматриваемые паттерны: Dashboard, Action Bar, Quick Actions, Search Bar и Companion Widget.

На мой взгляд тема UI паттернов является важной по нескольким причинам:

1. Привлечение пользователей: паттерны помогают сделать приложение более юзабильным, более понятным.
2. Проход на рынок: следование паттернам может сыграть важную роль при продвижении приложения на app market’ы.
3. Не стоит строить велосипед: при знании паттернов намного проще заниматься проектированием интерфейса приложения, используя имеющиеся решения.

Принципы дизайна интерфейса, отмеченные инженерами Google:

• Simple vs Clear : интерфейс должен быть простым(не нагруженным) и понятным для использования
• Content vs Chrome : необходимо использовать максимум экрана, при этом уменьшать его визуальную сложность (использовать ограниченное число кнопок/иконок)
• Consistent yet engaging : консистентность реакции пользователя – пользователь должен понимать что он делает/как сделать то, что ему необходимо
• Enhanced by cloud : данные пользователя следует хранить в облаке; пользователь должен иметь возможность выбирать настройки(организовывать данные) один раз, без повторных действий.

UI Design Patterns (по аналогии с Software Design Patterns) описывают общее решение для повторно возникаемых задач/проблем и возникают как “побочный продукт” процесса разработки.

Ниже перечислены пять UI паттернов с примерами на основе .

DashBoard

Dashboard (Панель инструментов) – представляет описание основных возможностей приложения, является главным меню приложения. Dashboard занимает весь экран, фокусируется на 3-6 наиболее важных функциях приложения, также может содержать информацию об обновлениях.
Поскольку паттерн Dashboard по сути является лицом приложения, подходить к его разработке нужно особенно аккуратно.

Action Bar

Action Bar предоставляет быстрый доступ к дополнительным функциям приложения, является наилучшим решением представления функций, используемых из любой точки приложения(поиск, синхронизация, рефреш и т.п.).
Action Bar не является полноценной заменой меню, но содержит ключевые действия, которые пользователь может выполнить(пользователь не должен входить в меню для выполнения этих действий). При этом паттерн не должен содержать контекстуальных действий(таких как копировать/вставить) Action Bar может также использоваться для ориентирования пользователя в приложении(а именно, показывать ему где он находится).

Quick Actions

Quick Actions – предоставляет доступ к контекстуальным функциям приложения, вызывается при клике на ”цели”, выводится на эран в качестве popup. Ключевые характеристики Quick Actions: действия должны соответствовать контексту, быть простыми и понятными(возможно использование иконок), действий не должно быть много. Стоит также отметить, что всплывающий popup не должен перекрывать “цели”(должен появляться либо снизу, либо сверху по отношению к “цели”). Использовать данный паттерн рекомендуется когда нет детального описания item-a, а также когда в приложении необходимо выполнить дополнительные действия, связанные с контекстом. Quick Actions не следует использовать, когда доступен мультиселект.

Search Bar

Search Bar – используется для поиска по приложению (заменяет Action Bar). Search Bar должен поддерживать предложения по поиску, а также может содержать селектор для выбора типа поиска.
Рекомендации по реализации паттерна: следует использовать для простого поиска по приложению, представлять богатые предложения поиска(например, заголовок с иконкой и описанием).

Companion Widget

Companion Widget – виджет, представляет основную информацию о приложении, может быть настроен пользователем. Кроме иконки должен иметь содержание(описание, значек апдейта, возможно некоторые функции приложения), должен сохранять пространство рабочего стола, а также предоставлять пользователю возможность настройки вида виджета.
Инженеры Google рекомендуют уделять больше внимания этому элементу интерфейса, поскольку он играет важное значение во взаимодействии с пользователем. Простой ярлык приложения – не самое лучшее решение.

Рассмотренные паттерны являются базовыми при разработке Android приложений, однако это не значит что все их обязательно необходимо применять. Главной все же остается идея, исходя из которой можно рассматривать различные варианты решений(это к тому что, разрабатывать все же стоит от идеи, а не от паттерна).
Удачи вам в реализации ваших идей!

P.S. Если тема вызывет интерес, можно продолжить обзором других UI паттернов.