понедельник, 20 февраля 2012 г.

Android Training-Энергосбережение-Отслеживание заряда батареи и состояния зарядки


Чтобы быть хорошим жителем на устройстве, ваше приложение должно ограничивать свое влияние на срок работы батареи. После этого курса вы будете способны создавать приложения, которые отслеживают и изменяют свою функциональность и поведение в зависимости от состояния устройства.
Принимая такие меры, как отключение фонового сервиса загрузки обновлений при потере связи или снижения темпов обновления при низком заряде батареи вы будете уверены в том, что влияние вашего приложения на срок жизни батареи минимально и это делается без ущерба для пользователей.
Отслеживание заряда аккумулятора и состояния зарядки.
Когда вы хотите изменить частоту фоновых обновлений для уменьшения влияния этих обновлений на срок работы аккумулятора, вам стоит начать с проверки текущего уровня заряда аккумулятора и состояния зарядки.
Влияние на срок работы аккумулятора зависит от уровня зарядки и состояния зарядки устройства. Влияние выполняющихся обновлений в то время, когда устройство заряжается от сети незначительно, так что в большинстве случаев вы можете увеличить частоту обновлений для устройства включенного в розетку. И наоборот, если устройство разряжается, уменьшение частоты обновления поможет продлить жизнь аккумулятору.
Кроме этого можно проверять текущий уровень зарядки и уменьшать частоту или даже выключать обновления при почти разряженном аккумуляторе
Определение текущего состояния зарядки.
Начните с определения текущего состояния зарядки. BatteryManager передает все сведения о батарее и зарядке в sticky Intentе, включающем в себя статус зарядки.
Т.к. это sticky intent, нет нужды регистрировать BroadcastReceiver—простым вызовом registerReceiver передаем null как приемник, и получаем intent состояния аккумулятора. Вы можете передать BroadcastReceiver объект тут, но мы будем обрабатывать обновления позже, так что пока это не обязательно.
IntentFilter ifilter = new IntentFilter(Intent.ACTION_BATTERY_CHANGED);
Intent batteryStatus = context.registerReceiver(null, ifilter);
Вы можете извлечь информацию о текущем состоянии зарядки и, если устройство сейчас заряжается, узнать тип зарядки-от USB или источника переменного тока.
// Заряжаемся или заряжено?
int status = batteryStatus.getIntExtra(BatteryManager.EXTRA_STATUS, -1);
boolean isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING ||
                status == BatteryManager.BATTERY_STATUS_FULL;
// Как мы заряжаемся?
int chargePlug = battery.getIntExtra(BatteryManager.EXTRA_PLUGGED, -1);
boolean usbCharge = chargePlug == BATTERY_PLUGGED_USB;
boolean acCharge = chargePlug == BATTERY_PLUGGED_AC;
Обычно вам стоит увеличить скорость фоновых обновлений в случае, если устройство подключено к источнику переменного тока, уменьшить ее при зарядке через USB, и снизить еще больше в состоянии разрядки батареи.
Отслеживание изменений в состоянии зарядки.
Состояние зарядки может легко поменяться при подключении устройства к сети, так что важно отслеживать изменения в состоянии зарядки и изменять частоту обновлений в нашем случае. BatteryManager передает действие каждый раз когда устройство подключается или отключается от сети питания. Важно получать информацию об этих событиях даже когда ваше приложение не работает-эти события должны влиять на то, как часто вы запускаете ваше приложения для запуска фонового обновления-так что вам следует зарегистрировать BroadcastReceiver в manifest-файле для отслеживания обоих событий, путем определения ACTION_POWER_CONNECTED и ACTION_POWER_DISCONNECTED внутри фильтра intentов.
<receiver android:name=".PowerConnectionReceiver">
  <intent-filter>
    <action android:name="android.intent.action.ACTION_POWER_CONNECTED"/>
    <action android:name="android.intent.action.ACTION_POWER_DISCONNECTED"/>
  </intent-filter>
</receiver>
В  реализации BroadcastReceiverа вы можете извлечь информацию о текущем состоянии зарядки:
public class PowerConnectionReceiver extends BroadcastReceiver {
    @Override
    public void onReceive(Context context, Intent intent) { 
     int status = intent.getIntExtra(BatteryManager.EXTRA_STATUS, -1);
     boolean isCharging = status == BatteryManager.BATTERY_STATUS_CHARGING ||
                      status == BatteryManager.BATTERY_STATUS_FULL;
     int chargePlug = intent.getIntExtra(BatteryManager.EXTRA_PLUGGED, -1);
     boolean usbCharge = chargePlug == BATTERY_PLUGGED_USB;
     boolean acCharge = chargePlug == BATTERY_PLUGGED_AC;
    }
}
Определение уровня заряда батареи.
В некоторых случая также полезно определить текущий уровень зарядки батареи. Вы можете например уменьшить темп обновлений при уровне заряда ниже определенного уровня.
Информацию о текущем уровне зарядки можно получить извлечением информации об текущем уровне батареи и соотношении:
int level = battery.getIntExtra(BatteryManager.EXTRA_LEVEL, -1);
int scale = battery.getIntExtra(BatteryManager.EXTRA_SCALE, -1);
float batteryPct = level / (float)scale;
Отслеживание важных изменений в уровне заряда батареи.
Вы не можете легко постоянно отслеживать уровень заряда аккумулятора, но вам и не нужно это делать.
В общем, постоянное отслеживание уровня заряда батареи может повлиять на этот самый заряд больше, чем обычное поведение программы, так что хорошей практикой будет отслеживать только важные изменения-например когда устройство доходит до уровня низкого заряда аккумулятора или выходит из него.
Пример ниже показывает, как это реализовать при помощи слушанья ACTION_BATTERY_LOW и ACTION_BATTERY_OKAY.
<receiver android:name=".BatteryLevelReceiver">
<intent-filter>
  <action android:name="android.intent.action.ACTION_BATTERY_LOW"/>
  <action android:name="android.intent.action.ACTION_BATTERY_OKAY"/>
  </intent-filter>
</receiver>
В общем случае хорошей практикой будет выключение всех ваших фоновых обновлений при достижении критически низкого уровня заряда батареи-актуальность данных будет не важна если телефон выключится перед тем, как вы получите доступ к ним.


воскресенье, 19 февраля 2012 г.

Android Training-Разработка эффективной навигации-Итог:приложение-пример Wireframing

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

Рисунок 1. Исчерпывающая экранная карта для новостного приложения.

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



Выбор шаблонов.

Вначале, наши экраны второго уровня (Story Category List, Photo List,и Saved Item List) могут быть объединены при помощи вкладок. Обратите внимание, нет необходимости использовать горизонтально расположенные вкладки, в некоторых случаях выпадающий список элементов UI может служить хорошей заменой, особенно на устройствах с узкими экранами, например телефонах. Мы также можем объединить экраны Saved Photo List и Saved Story List используя вкладки на мобильных телефонах или используя несколько вертикальных панелей на планшетах.

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

Ниже на диаграммах показаны новые карты экранов для мобильных телефонов и планшетов после применения навигационных шаблонов.


Рисунок 2.Финальная карта экранов для новостного приложения для мобильных телефонов.


Рисунок 3. Финальная карта экранов для новостного приложения для планшетов.
Теперь самое время подумать о различных вариантах экранной карты на тот случай, если выбранные вами шаблоны не будут работать как следует на практике. Ниже пример экранной карты для планшетов показывающий списки статей для различных категорий бок-к-боку, с остающимся независимым экраном просмотра статей.
Рисунок 4.  Пример альтернативной карты экранов для планшетов в альбомном режиме.

Эскизы и WireFraming.

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

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

После того как вы закончите с начальными эскизами хорошей идеей будет провести создание цифровых каркасов(digital wireframing) при помощи программ Adobe® Illustrator, Adobe® Fireworks, OmniGraffle, либо других утилит векторных иллюстраций. При выборе средства учтите следующие особенности::
  • Возможность интерактивных каркасов? Утилиты типа Adobe® Fireworks предлагают эту возможность.
  • Есть ли функциональность "мастер-экран", позволяющая повторное использование визуальных элементов в различных экранах? На пример, Action Bars должны быть видны на каждом экране вашей программы.
  • Как сложно обучение? Профессиональные программы для векторной иллюстрации могут требовать длительного обучения, в то время как утилиты для создания каркасов могут предлагать ограниченный набор функций и больше подходить для вашей задачи.

Наконец, XML Layout Editor который поставляется в составе Android Development Tools (ADT) плагина для Eclipse может быть часто использован для создания прототипов. В тоже время вам стоит быть осторожным и фокусироваться более на высокоуровневые детали разметки и меньше на визуальные детали.

Создание цифровых каркасов.

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


Рисунок 6.Figure 6.Каркасы новостного приложения для планшетов в альбомном режиме и альтернативная разметка со списками статей (Скачать SVG)

(Скачать SVG каркасов)

Оригинальный текст доступен тут.

Android Training-Создание эффективной навигации-Создание предковой и временной навигации



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

Поддержка временной навигации: Назад.

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


Рисунок 1. Поведение кнопки "Назад" после запуска приложения для работы с e-mail из приложения для работы с контактами.

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

Создание предковой навигации-кнопки вверх и домой.
Перед Android 3.0, самая распространенная форма предковой навигации была навигация "Домой". Это в основном реализовывалось как элемент Домой доступный при помощи кнопки Меню на устройстве или кнопки Домой в верхней левой части экрана, обычно как компонент Action Bar. После нажатия Домой пользователь перемещался к экрану вверху иерархии экранов, обычно известной, как домашний экран приложения.

Предоставление прямого доступа к домашнему экрану приложения может дать пользователю ощущение удобства и безопасности. Независимо от того, где они находятся в приложении, кнопка Домой всегда приведет к их к известному домашнему экрану.
Android 3.0 ввел действие Вверх, которое представлено на Action Bar как замена для кнопки Домой, описанной выше. После нажатия Вверх пользователь должен быть перемещен в родительский экран иерархии. Этот навигационный шаг обычно означает перемещение на предыдущий экран(как описано про клавишу Назад)),но это не всегда так. Разработчики должны убедиться что Вверх для каждого экрана означает навигацию к простому, предопределенному родительскому экрану.


Рисунок 2. Пример поведения при навигации Вверх после запуска приложения для работы с e-mail из приложения для работы с контактами.
В некоторых случаях является уместным для Вверх выполнять действие вместо навигации к родительскому экрану. Для примера возьмем приложение Gmail для Android 3.0 планшетов. При просмотре переписки пока устройство находится в альбомном режиме, список переписок, как и детали представлены бок-к-боку. Это форма группировки родитель-потомок экранов, описанная в предыдущем уроке.В тоже время, при просмотре переписки в портретном режиме, показываются только детали. Кнопка вверх используется для временного показа родительской панели, которая выпадает с левой части экрана. Нажатие кнопки Вверх еще раз при видимой левой панели выходит из экрана с контекстом выбранной переписки к полному списку переписок.
Примечание к реализации: Лучшей практикой, при реализации Домой или Вверх является предварительная очистка заднего стека любых экранов-потомков. Для Домой, только экран, остающийся в заднем стеке должен быть домашним экраном. Для навигации Вверх, текущий экран должен быть удален из заднего стека, в то время, как Назад выполняет навигацию по иерархии экранов. Вы можете использовать FLAG_ACTIVITY_CLEAR_TOP FLAG_ACTIVITY_NEW_TASK intent флаги вместе для достижения такого эффекта.
Оригинальный материал доступен тут.

Android Training-Создание эффективной навигации-Создание потомковой и боковой навигации

Одним из способов обеспечения доступа к полному набору экранов приложения является использование иерархической навигации. В этом уроке мы обсудим потомковую(descendant) навигацию, позволяющую пользователям спуститься вниз по иерархии экранов к дочернему экрану, и боковую(lateral) навигацию, позволяющую пользователям получить доступ к "братским" (sibling, т.е. находящимся на одном уровне иерархии) экранам.


Рисунок 1. Потомковая(Descendant) и боковая(Lateral) навигация.

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

Рисунок 2. Родственные в коллекции и родственные разделы.

Потомковая и боковая навигация могут быть реализованы при помощи списков, вкладок и других шаблонов пользовательского интерфейса. Шаблоны интерфейса пользователя, как и шаблоны проектирования ПО являются обобщенными, общими решениями повторяющихся задач проектирования взаимодействия с пользователем. Мы исследуем несколько общих шаблонов боковой навигации в секциях ниже.


Кнопки и простые цели.

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

Рисунок 3. Пример интерфейса с навигацией, основанной на кнопках с соответствующим отрывком карты экранов. Также показан шаблон dashboard, обсуждаемый ниже.

Общим, основанном на кнопках шаблоне для доступа к различным разделам верхнего уровня приложения является шаблон dashboard. Он представляет собой сетку из больших кнопок-значков которые составляют большинство родительского экрана. Сетка обычно имеет 2 или 3 строки и колонки, в зависимости от количества разделов верхнего уровня в приложении. Этот шаблон предоставляет отличный путь показать все разделы приложения визуально красивым способом. Крупные нажимаемые цели также делают этот UI очень удобным в использовании. Dashboard лучше всего для тех случаев, когда каждый раздел одинаково важен, как определено в решениях продукта или лучше использовании в реальном мире. Несмотря на это, шаблон не работает хорошо на больших экранах и требует от пользователей дополнительный шаг для доступа к содержимому приложения.
Более сложные пользовательские интерфейсы могут использовать множество других шаблонов организации взаимодействия с пользователем для улучшения непосредственности и уникальности содержания, все равно оставаясь интуитивно понятными.

Списки, сетки, карусели и стеки.

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

Вкладки.

Использование вкладок является популярным решением для боковой навигации. Этот шаблон позволяет объединять родственные экраны, таким образом в контейнер вкладок в родительском экране могут быть вложены дочерние экраны, в другом случае разнесенные по различным контекстам. Вкладки больше всего подходят для небольших наборов(4 или меньше) экранов родственных разделов.
Рисунок 5. Пример телефонной и планшетной навигации, основанной на вкладках с соответствующим отрывком карты.
Несколько лучших практик при использовании вкладок. Вкладки должны быть устойчивы среди связанных экранов. Только назначенная область содержимого должна меняться при выборе вкладки, индикаторы вкладки должны быть доступными все время. Кроме того, переключение вкладок не должно рассматриваться как история. Для примера, если пользователь переключается из вкладки А в другую вкладку Б, нажатие клавиши назад не должно выбирать заново вкладку А. Вкладки обычно располагаются горизонтально, хотя другие варианты навигации при помощи вкладок наподобии выпадающего списка в Action Bar тоже возможны. Наконец, и самое главное, вкладки должны всегда находиться вверху экрана.
Вот самые очевидные преимущества вкладок перед навигацией, основанной на списках и кнопках:
  • Пользователи получают мгновенный доступ к содержимому вкладки из родительского экрана.
  • Пользователи могут быстро перемещаться между родственными экранами без необходимости посещения родительского экрана перед этим.
Примечание: при переключении вкладок является важным сохранять непосредственность переключения, не блокировать доступ к заголовкам вкладок показыванием модальных диалогов при загрузке содержимого.
Распространенная критика состоит в том, что на заголовки вкладок тратится пространство забираемое у содержимого вкладки. Это обычно приемлемо, и преимущества перевешивают недостатки использования этого шаблона. Вы также должны чувствовать себя свободным при кастомизации заголовков вкладок показывая текст и/или значки для оптимального использования вертикального пространства. При настройке высоты заголовков убедитесь что заголовки достаточно крупные для нажатия человеческим пальцем без ошибок.



Горизонтальное перелистывание страниц(Swipe виды).

Другим популярным шаблоном боковой навигации является горизонтальное перелистывание страниц также известное, как "swipe views". Этот шаблон применяется лучше всего к экранам, родственным в коллекции, например, список категорий (статьи о мире, бизнесе, технологии и здоровье). Подобно вкладкам, этот шаблон также позволяет объединять экраны так, что родитель представляет содержимое дочерних экранов, встроенных в его собственную разметку.


Рисунок 6. Пример интерфейса навигации с горизонтальной прокруткой страниц с соответствующим отрывком карты экранов.
В UI с горизонтальным перелистыванием страниц, простые дочерние экраны(называемые страницами)отображается по одному. Пользователи имеют возможность осуществлять навигацию по родственным экранам методом нажатия и перетаскивания экрана горизонтально в направлении желаемой соседней страницы. Это жестовое взаимодействие часто дополняется другими элементами UI которые отображают текущую страницу и доступные страницы для обеспечения понятности и предоставления большего объема содержимого пользователю. Эта практика особенно необходима при использовании шаблона для боковой навигации экранов родственных разделов. Примерами таких элементов могут быть владки, прокручивающиеся надписи или значки делений(tick marks).


Рисунок 7. Примеры вспомогательных элементов для перелистывания страниц.

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

Оригинальный материал доступен по следующему адресу.

Android Training-Создание эффективной навигации-Планирование для различных размеров сенсорных экранов


Исчерпывающая карта экранов из предыдущего урока не привязана к конкретному форм-фактору устройства, хотя может выглядеть отлично на телефоне или устройстве подобного размера. В тоже время приложения для Android должны быть адаптированы к различным типам устройств, от 3" телефонов до 10" планшетов и 42" телевизоров. В этом уроке мы рассмотрим причины и техники объединения нескольких экранов из исчерпывающей карты.

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

Объединение экранов при помощи многопанельных разметок.

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

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

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

Следующие рисунки демонстрируют некоторые проблемы, которые могут появиться при перемещении пользовательского интерфейса на большие разметки и способы устранения этих проблем с многопанельными разметками:
Рисунок 1. Однопанельные разметки на больших экранах приводят  в альбомном режиме к трате свободного пространства и чрезмерным длинам строк.
Рисунок 2.Многопанельные разметки в альбомном режиме приносят лучший визуальный баланс, больше полезности и лучшую читабельность.


Примечание реализации: После принятия решения о размере экрана, который будет разделять одно- и многопанельные разметки вы можете предоставить различные разметки, содержащие одну или несколько панелей для устройств в различных категориях размеров экрана(типа large/xlarge) или различных категориях ширины экранов (например sw600dp).

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

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

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

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

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

Объединение экранов на карте экранов.
Теперь когда мы способны сгруппировать отдельные экраны вместе предоставляя многопанельные разметки на устройствах с большими экранами, давайте применим эту технику к нашей избыточной карте экранов из предыдущего урока чтобы получить лучшее представление о иерархии нашего приложения на таких устройствах:
Рисунок 3.Обновленная карта экранов нашего приложения для планшетов.

Оригинальный материал доступен по адресу


суббота, 18 февраля 2012 г.

Android Training-Создание эффективной навигации-Планирование экранов и отношений между ними


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

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

Большинство приложений имеют неотъемлемую информационную модель которая может быть представлена в виде дерева или графа объектов. В более очевидных условиях вы можете нарисовать диаграмму различных видов информации которая покажет тип вещей с которыми пользователи взаимодействуют в вашем приложении. Разработчики программного обеспечения и архитекторы часто используют диаграммы сущность-связь(ERDs) для описания информационной модели приложения.

Давайте рассмотрим пример приложения, которое позволяет пользователям просматривать набор новостей, разбитых по категориям и фотографии. Возможная модель для такого приложения представлена ниже в виде ERD.
Рисунок 1. Диаграмма сущность-связь для новостного приложения-примера.


Создание списка экранов.

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

В нашем приложении-примере мы хотим позволить пользователям просматривать, сохранять и делиться категоризированными новостными заметками и фотографиями. Ниже представлен исчерпывающий список экранов, который покрывает все варианты взаимодействия пользователей.
  • "Домашний" экран или экран "запуска" для доступа к историям и фотографиям
  • Список категорий
  • Список новостных заметок для данной категории
  • Детальный вид заметки (из которого мы можем сохранять и делиться)
  • Список фотографий, не разбитый по категориям
  • Детальный вид фото(из которого мы можем сохранять и делиться)
  • Список всех сохраненных элементов
  • Список сохраненных фотографий
  • Список сохраненных заметок
Схема отношений экранов.
Теперь мы можем определить прямые отношения между экранами, стрелка от экрана А к экрану Б означает что экран Б должен быть доступен напрямую при взаимодействии с пользователем в экране А. Как только мы определим набор экранов и отношения между ними мы можем представить это в виде карты экранов, которая показывает все ваши экраны и отношения.
Рисунок 2. Исчерпывающая карта экранов для нашего новостного приложения.

Если в будущем мы захотим позволить пользователям отправлять новости или загружать фотографии мы можем добавить дополнительные экраны на эту диаграмму.

Не только упрощенный дизайн.

На данный момент возможно спроектировать полностью функциональное приложение на основе исчерпывающей карты экранов. Упрощенный пользовательский интерфейс может содержать кнопки и списки, ведущие к дочерним экранам:
  • Кнопки, ведущие к различным секциям(заметки, фото, сохраненные элементы)
  • Вертикальные списки отображающие коллекции(списки заметок, фотографий)
  • Детальная информация (вид с заметкой, полноэкранный вид с фото)

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

Android Training-Улучшение производительности разметок-Создание плавной прокрутки ListViewа

Ключом к плавной прокрутке ListView является освобождение основного потока приложения (UI потока) от тяжелых вычислений. Убедитесь что работа с данными в постоянной памяти устройства, данными в сети или базе данных осуществляется в отдельном потоке. Для проверки состояния вашего приложения вы можете включить StrictMode.
Использование фонового потока.

Использование фонового потока("рабочего потока") снимает напряжение в главном потоке, предоставляя ему возможность сфокусироваться на отрисовке UI. В большинстве случаем, использование AsyncTask обеспечивает простой путь выполнения вашей работы вне основного потока. AsyncTask автоматически ставит в очередь все запросы execute() и затем выполняет их последовательно. Такое поведение является глобальным в целом процессе и означает что вам не стоит волноваться о создании собственного пула потоков.
В коде ниже AsyncTask используется для загрузки изображений в фоновом потоке и дальнейшем показе по завершению. Также он показывает счетчик прогресса на месте изображений пока они загружаются.
// использование AsyncTask для загрузки картинок в фоновом потоке
new AsyncTask<ViewHolder, Void, Bitmap>() {
    private ViewHolder v;

    @Override
    protected Bitmap doInBackground(ViewHolder... params) {
        v = params[0];
        return mFakeImageLoader.getImage();
    }

    @Override
    protected void onPostExecute(Bitmap result) {
        super.onPostExecute(result);
        if (v.position == position) {
         
            v.progress.setVisibility(View.GONE);
            v.icon.setVisibility(View.VISIBLE);
            v.icon.setImageBitmap(result);
        }
    }
}.execute(holder);

Начиная с Android 3.0 (API level 11), дополнительная опция в AsyncTask позволяет ему работать на нескольких ядрах процессора.Вместо вызова execute() вы можете указать executeOnExecutor() и множественные запросы могут выполняться одновременно в зависимости от количества доступных ядер.
Помещение обьектов вида в View Holder.
Ваш код может вызывать findViewById() последовательно во время прокрутки ListView, что может замедлить быстродействие. Даже когда Adapter возвращает inflated вид для очистки, вам может понадобиться просмотреть и обновить элементы. Другим способом является использования шаблона "view holder".
Объект ViewHolder хранит каждый компонент вида разметки, так что можно получить доступ ко всем ним без повторного просмотра. Для начала, создадим класс для хранения набора видов, например::
static class ViewHolder {
  TextView text;
  TextView timestamp;
  ImageView icon;
  ProgressBar progress;
  int position;
}
Теперь заполним ViewHolder и сохраним его внутри разметки.
ViewHolder holder = new ViewHolder();
holder.icon = (ImageView) convertView.findViewById(R.id.listitem_image);
holder.text = (TextView) convertView.findViewById(R.id.listitem_text);
holder.timestamp = (TextView) convertView.findViewById(R.id.listitem_timestamp);
holder.progress = (ProgressBar) convertView.findViewById(R.id.progress_spinner);
convertView.setTag(holder);
Теперь мы можем легко получить доступ к каждому виду без дополнительного просмотра, экономя ценные процессорные циклы.
Оригинальный материал доступен тут.