Android уроки: Первые 100 уроков в PDF

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

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

Тогда почему бы не написать виджеты на React Native?

Проведя предварительное расследование, мы быстро обнаружили некоторые препятствия (например, тот факт, что RemoteViews — единственный способ создавать виджеты). В настоящее время в сообществе React Native нет официальной поддержки RemoteViews, необходимого для поддержки виджетов. Это было очень похоже на квадратный колышек в круглом отверстии. Наше приложение для iOS также столкнулось с проблемами, связанными с поддержкой React Native, и мы шли по тому же пути. Shopify верит в использование правильного инструмента для работы, мы считаем, что нативная разработка была правильным выбором в этом случае.

Создавая архитектуру для виджетов, мы хотели обеспечить единообразие работы как на Android, так и на iOS, сохраняя при этом идиомы платформ там, где это имело смысл. В разделах ниже мы хотим дать вам представление о нашем опыте создания виджетов. Указав на некоторые из наиболее сложных проблем, с которыми мы столкнулись. Наша цель — пролить свет на эти редко используемые поверхности, вдохновить их и сэкономить время, когда дело доходит до реализации виджетов в ваших приложениях.

Получение данных

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

Получение данных в приложении

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

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

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

Обеспечение антихрупкости виджетов

Архитектура виджетов построена таким образом, что обновления учитывают использование батареи, когда обновления контролируются системой. Точно так же наши виджеты также должны помнить об экономии полосы пропускания при получении данных по сети. При разработке нашей второй итерации мы столкнулись со своеобразной проблемой, которая усугублялась нашим конкретным вариантом использования. Поскольку нам нужны свежие данные, мы всегда извлекаем новые данные из нашего бэкэнда при каждом обновлении. Каждое обновление происходит примерно через 15 минут, чтобы наши виджеты не переставали обновляться. Мы обнаружили, что виджеты вызывают свой метод обновления 9.0320 onUpdate() , более одного раза в цикле обновления. В таких виджетах, как календарь, эти дополнительные вызовы не требуют особых дополнительных затрат, поскольку данные хранятся локально. Однако в нашем приложении это вызывало от двух до пяти дополнительных сетевых вызовов для одного и того же виджета с теми же данными в быстрой последовательности.

Чтобы исправить ненужные обращения туда и обратно, мы создали простой кратковременный кеш:

1. Система запрашивает у нашего виджета новые данные из Reportify (служба данных Shopify)
2. Сначала мы просматриваем локальный кэш, используя идентификатор widgetID, предоставленный системой.
3. Если есть данные, и эти данные были установлены менее минуты назад, мы возвращаем их и не делаем сетевой запрос. Мы также учитываем такие настройки, как локаль, чтобы не избежать принудительного обновления после смены языка.
4. В противном случае мы извлекаем данные как обычно и сохраняем их в кэше с отметкой времени.

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

Реализация стратегии декодера с динамическим выбором

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

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

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

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

Создание пользовательского интерфейса

Как и в iOS, мы поддерживаем три размера виджета для версий до Android 12 и придерживаемся тех же правил для макета ячейки, за исключением маленького виджета. Небольшой виджет на Android поддерживает одну метрику (по сравнению с двумя на iOS), а наименьший размер виджета на Android — это сетка 2×1. Мы быстро обнаружили, что в это пространство поместится только одна метрика, поэтому этот дизайн немного отличается для разных платформ.

В отличие от iOS с быстрым предварительным просмотром, мы были ограничены предварительным просмотром XML и запуском виджета на эмуляторе или устройстве. Мы также создаем виджеты динамически, поэтому даже предварительный просмотр XML был относительно бесполезен, если мы хотели увидеть предварительный просмотр всего виджета. Виджеты в настоящее время находятся в дорожной карте Jetpack Compose на 2022 год, поэтому это, вероятно, скоро изменится с предварительными сборками Jetpack.

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

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

Для динамического создания виджетов мы считываем нашу конфигурацию из общих настроек и передаем эту информацию API RemoteViews.

Если вы знакомы с RemoteViews API, вы можете заметить updateView() , который не является методом RemoteViews по умолчанию. Мы создали этот метод расширения в результате проблемы, с которой мы столкнулись при построении нашего макета виджета таким динамическим образом. Когда виджет обновляется, новые удаленные представления добавляются к существующим. Как вы, наверное, догадались, виджет выглядел не так уж и хорошо. Хуже того, при каждом последующем обновлении добавляется больше удаленных представлений. Мы обнаружили, что объединение двух методов API RemoteViews removeAllViews() и addView() решил эту проблему.

После создания удаленных представлений мы передаем родительское удаленное представление методу AppWidgetProvider updateAppWidget() для отображения желаемого макета.

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

Использование динамических дат

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

В нашем предыдущем дизайне у нас были только маленькие виджеты, и они могли отображать только одну метрику. Эта информация приводила к длинному фрагменту текста, который на небольших устройствах иногда переносился и отображался на двух строках. Это было нормально, когда в нашем старом дизайне было много места, но не в наших новых проектах с большим объемом данных. Мы исследовали, как лучше всего работать с временными метками в виджетах, и самым многообещающим решением было использование относительного времени . Вместо статического значения, такого как «по состоянию на 15:30», как в нашей предыдущей итерации. У нас была бы динамическая дата, которая выглядела бы так: «1 минута, 3 секунды назад».

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

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

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

Добавление конфигурации

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

Работа с диаграммами и изображениями

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

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

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

Устранение мерцания

Одна небольшая, но досадная проблема, с которой мы столкнулись на протяжении всего проекта, — это то, что мы любим называть «мерцанием виджета». Мерцание — это побочный эффект обновления виджетом своих данных. Между обновлениями Android использует initialLayout из конфигурации виджета в качестве заполнителя, пока виджет извлекает свои данные и создает свои новые RemoteViews. Мы обнаружили, что устранить такое поведение невозможно, поэтому мы реализовали несколько стратегий, чтобы уменьшить частоту и продолжительность мерцания.

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

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

Сбор аналитики

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

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

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

Обнаружение добавления и удаления виджетов 

В отличие от iOS, сбор этих данных в Android выполняется очень просто. Чтобы зафиксировать, когда продавец добавляет виджет, мы отправляем наше аналитическое событие при сохранении конфигурации. При удалении виджета встроенные виджеты 9Метод 0793 onDeleted дает нам идентификатор удаленного виджета. Затем мы можем просмотреть информацию о виджете в общих настройках и отправить событие до окончательного удаления информации о виджете с устройства.

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

Наш подход к выбору виджетов в предыдущих версиях заключался в отображении каждого доступного размера в качестве опции. С введением адаптивных макетов нам больше не нужно было отображать каждый размер как отдельный вариант. Теперь продавцы могут выбрать один виджет и изменить его размер в соответствии с желаемым макетом. В предыдущих версиях продавцы могли выбрать маленький, средний и большой виджет. В версиях 12 и выше продавцы могут выбрать только один виджет, размер которого можно изменить до тех же макетов, что и у малого, среднего, большого и нескольких других макетов, которые находятся между ними. Этот шаблон следует тому, что Google делает с их большим виджетом погоды, включенным в устройства, а также примером в их документации. Мы отключили средние и маленькие виджеты в Android 12, добавив флаг в наш AndroidManifest и установка этого значения в attrs.xml для каждой версии:

Приведенный выше подход ведет себя так, как ожидалось, средние и маленькие виджеты теперь недоступны в средстве выбора. Однако, если продавец уже использовал Android 12 и добавил виджет среднего или большого размера до нашего обновления виджета, эти виджеты были удалены с их главного экрана. Это можно легко расценить как ошибку и снизить доверие к этой функции. Оглядываясь назад, мы могли бы создать прототип того, как обновление выглядело бы для продавца, который уже использовал Android 12.

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

Создание новых макетов

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

После изучения ошибки мы обнаружили превышение буфера транзакций Binder. Однако размер буфера составляет 1 МБ, а ошибка отображала 0,66 МБ, что не превышало задокументированный размер буфера. Эта ошибка поставила в тупик многих разработчиков. Поэкспериментировав со способами уменьшения размера, мы обнаружили, что можем либо отказаться от пары целых макетов, либо убрать поддержку четвертой и пятой строк малой метрики. Мы выбрали последнее, поэтому наш виджет 2×3 имеет только три строки данных, когда в нем есть место для пяти.

Переосмысление экрана конфигурации

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

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

Мы также обновили описание, которое отображается в верхней части экрана конфигурации и объясняет это поведение.

Сбор дополнительной аналитики

В iOS мы собираем аналитические данные, когда продавец перенастраивает виджет, чтобы получить представление о шаблонах использования. Реконфигурация для Android была возможна только в версии 12, и из-за ограничений метода AppWidgetProvider onAppWidgetOptionsChanged() мы не смогли получить эти данные на Android.

Я поделюсь дополнительной информацией о создании наших макетов, чтобы придать контекст нашей проблеме. Установка точек останова для новых динамических макетов очень хорошо работает на всех устройствах. Google рекомендует создать сопоставление ваших точек останова с желаемым макетом удаленного просмотра. Чтобы развить предыдущий пример, в котором мы показали метод buildWidgetRemoteView() , мы снова использовали этот метод как часть сопоставления точек останова. Этот подход позволяет нам надежно сопоставлять наши точки останова с желаемым макетом виджета.

При изменении конфигурации или размера виджета вызывается метод onAppWidgetOptionsChanged() . Здесь мы хотели бы зафиксировать наши аналитические данные о том, что изменилось. К сожалению, такого сопоставления представлений здесь нет. У нас есть доступ к значениям ширины и высоты, которые измеряются в dp, что изначально казалось полезным. Сначала мы чувствовали, что можем различить эти измерения во что-то значимое и сопоставить эти значения с размерами макета. Протестировав на паре устройств, мы поняли, что подход ненадежен и приведет к большому объему неверных аналитических данных. Не зная с уверенностью, к какому размеру мы пришли или к какому приближаемся, мы решили пропустить это конкретное аналитическое событие из Android. Мы надеемся довести это до сведения Google и включить его в будущий выпуск.

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

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

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

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

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

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

По мере того, как мы продолжаем узнавать о том, как продавцы используют наше новое поколение виджетов и функции Android 12, мы продолжим оттачивать лучший опыт на обеих наших платформах. Это также дает возможность другим командам Shopify развивать то, что мы начали, и создавать больше виджетов, чтобы помочь продавцам.

Говоря о мобильных платформах, это подводит нас к ускорению работы с WearOS. Наше приложение для WatchOS скоро получит обновление с добавлением Widgetkit; Похоже, пришло время, наконец, предоставить поддержку часов Android Merchants!

Мэтт Боуэн — разработчик мобильных приложений в группе Core Admin Experience. Расположен в Вест-Уорике, Род-Айленд. Личное хобби включает в себя тренировки и просмотр матчей Boston Celtics и New England Patriots.

Джеймс Локхарт — штатный разработчик из Оттавы, Канада. Опыт мобильной разработки за последние 10 с лишним лет: от Phonegap до нативной iOS/Android и теперь нативной React. Он заядлый пекарь и готовит, когда не участвует в административном приложении Shopify.

Сесилия Хунка — разработчик в группе Core Admin Experience в Shopify. Живет в Торонто, Канада, любит живую музыку и головоломки.

Карлос Перейра — старший разработчик из Монреаля, Канада, с более чем десятилетним опытом создания нативных iOS-приложений на Objective-C, Swift, а теперь и на React Native. В настоящее время участвует в административном приложении Shopify.

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