Android widget on disabled

Виджеты на Android. Редкая фича, в которой придется разобраться

Привет, Хабр! Меня зовут Александр Хакимов, я android-разработчик в компании FINCH.

У вас бывало такое, что ваш дизайн был под iOS, а вам приходится адаптировать его под android? Если да, то часто ли ваши дизайнеры используют виджеты? К сожалению, виджет — редкий кейс для многих разработчиков, потому что с ним редко кто работает,

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

Создание виджета

Для создания виджета нужно знать:

1. Особенности компонентов виджета.
2. Особенности отображения виджета в сетке экрана.
3. Особенности обновления виджета.

Разберем каждый пункт отдельно.

Особенности компонентов виджета

С этим пунктом знаком любой разработчик, который хоть раз работал с RemoteViews. Если вы из таких, смело переходите к следующему пункту.

RemoteViews предназначен для описания и управления иерархиями Views, которые принадлежат процессу другого приложения. С помощью управления иерархиями можно изменять свойства или вызывать методы, принадлежащие View, которое выступает частью другого приложения. В RemoteViews входит ограниченный набор компонентов стандартной библиотеки компонентов android.widget.

View внутри виджетов работают в отдельном процессе (как правило, это домашний экран), поэтому для изменения UI виджета используется расширение BroadcastReceiver — AppWidgetProvider, работающий в нашем приложении.

Особенности отображения виджета в «сетке» экрана

Each widget must define a minWidth and minHeight, indicating the minimum amount of space it should consume by default. When users add a widget to their Home screen, it will generally occupy more than the minimum width and height you specify. Android Home screens offer users a grid of available spaces into which they can place widgets and icons. This grid can vary by a device; for example, many handsets offer a 4×4 grid, and tablets can offer a larger, 8×7 grid.

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

Пример настроек виджета при создании в Android Studio

Виджет, который добавили на на Home screen, обычно займет больше места чем минимальные ширина и высота экрана, которые вы задали. Android Home screens предоставляет пользователям сетку доступного пространств, в которых могут быть расположены виджеты и иконки. Эта сетка может отличаться в зависимости от устройства; например, многие телефоны предлагают сетку 4х4, а планшеты могут предложить большие сетки 8х7.

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

Минимальные ширину и высоту виджета для заданного количества столбцов и строк можно вычислить по формуле:

minSideSizeDp = 70 × n − 30, где n —количество строк или столбцов

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

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

Так как AppWidgetProvider по своей сути является расширением BroadcastReceiver-а, с ним можно делать все то же самое, что и с обычным BroadcastReceiver. AppWidgetProvider просто парсит соответствующие поля из Intent, полученного в onReceive и вызывает методы перехвата с полученными extras.

Сложность возникла с частотой обновления контента — все дело в разнице внутренней работы виджетов на iOS и Android. Дело в том, что данные на iOS-виджетах обновляются тогда, когда виджет становится виден пользователю. В Android, такого события не существует. Мы не можем узнать, когда пользователь видит виджет.

Для виджетов на Android рекомендуемым способом обновления является обновление по таймеру. Настройки таймера задаются параметром виджета updatePeriodMillis. К сожалению, эта настройка не позволяет обновлять виджет чаще чем раз в 30 минут. Ниже я расскажу об этом подробнее.

Кейс создания виджета

Дальше речь пойдет о кейсе который был у нас в FINCH в крупном лотерейном приложении с приложением «Столото» для участия в государственных лотереях.

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

В нашем кейсе дизайн виджета предусматривал два состояния:

• Для авторизованного пользователя
• Для неавторизованного пользователя

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

Как вы могли заметить, еще одной особенностью для авторизованного пользователя является кнопка «обновить», но об этом позже.

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

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

Пишем апдейт для каждого инстанса нашего виджета.

Пишем реализацию нашего сервиса. В нем нам важно указать, какую реализацию интерфейса RemoteViewsService.RemoteViewsFactory использовать, чтобы генерировать контент.

Фактически это тонкий wrapper над Adapter. Благодаря ему, мы можем связывать наши данные с remote collection view. RemoteViewsFactory предоставляет методы генерации RemoteViews для каждого элемента в наборе данных. У конструктора нет никаких требований — все что я делаю, это передаю в нем контекст.

Далее будет пару слов об основных методах:

1. onCreate – создание адаптера.
2. getLoadingView – метод предлагает возвращать View, которое система будет показывать вместо пунктов списка, пока они создаются. Если ничего здесь не создавать, то система использует некое дефолтное View.
3. getViewAt – метод предлагает создать пункты списка. Здесь идет стандартное использование RemoteViews.
4. onDataSetChanged вызывается, когда поступил запрос на обновление данных в списке. Т.е. в этом методе мы подготавливаем данные для списка. Метод заточен под выполнение тяжелого, долгого кода.
5. onDestroy вызывается при удалении последнего списка, который использовал адаптер (один адаптер может использоваться несколькими списками).
6. RemoteViewsFactory живет пока все инстансы списка живы, поэтому мы можем хранить в нем текущие данные, например, список текущих айтемов.

Определяем список данных, который будем показывать:

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

При вызове команды на обновление данных, так же вызываем updateDataSync()

Внутри updateDataSync тоже все просто. Очищаем текущий список item-ов. Загружаем данные профиля и игры.

Здесь уже поинтереснее

Так как нам важно показывать профиль только авторизованному пользователю, то и информацию профиля нам нужно загружать только в этом случае:

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

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

Метод updateGamesSync() использует getWidgetGamesInteractor и добавляет в список widgetItems набор актуальных для виджета игр.

Прежде чем перейти к генерации карточек, рассмотрим подробнее модель WidgetItem. Она реализована через kotlin sealed class, что делает модель более гибкой, а работу с ней более удобной.

Создаем RemoteViews и определяем их отклик через FillInIntent

Метод setOnClickFillInIntent назначает указанной viewId intent, который будет объединен с родительским PendingIntent для определения поведения при клике на view с этим viewId. Таким образом, мы сможем реагировать на клики пользователей в нашем WidgetProvider.

Ручное обновление виджета

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

Все изменилось когда «бизнес» обратил внимание, что когда пользователь смотрит на виджет, на нем отображаются неактуальные данные: «Вот на моем iPhone, я открываю виджет и там САМЫЕ свежие данные моего профиля».

Ситуация банальна: iOS генерирует новые карточки при КАЖДОМ показе виджетов, ведь для этого у них отведен специальный экран, а Android не имеет подобных событий для виджета в принципе. Пришлось учесть, что некоторые лотереи проводятся раз в 15 минут, поэтому виджет должен давать актуальную информацию – ты хочешь поучаствовать в каком-то тираже, а он уже прошел.

Чтобы выйти из этой неприятной ситуации и как то решить проблему с обновлением данных, мной было предложено и реализовано проверенное временем решение — кнопка «обновить».

Добавляем эту кнопку в макет layout-a со списком и инициализируем её поведение при вызове updateWidget

Первые наработки показали грустную картину: от нажатия на кнопку «обновить» до фактического обновления, могло пройти несколько секунд. Хотя виджет и генерируется нашим приложением, он фактически находится во власти системы и общается с нашим приложением через broadcast-ы.

Т.е. при нажатии на кнопку «обновить» нашего виджета запускается цепочка:

1. Получить Intent в onReceive провайдера action’ .
2. AppWidgetManager.ACTION_APPWIDGET_UPDATE.
3. Вызов onUpdate для всех указанных в intent-e widgetIds.
4. Зайти в сеть за новыми данными.
5. Обновить локальные данные и отобразить новые карточки списка.

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

Во-первых, я добавил флаг isWidgetLoading с глобальным доступом через интерактор. Роль этого параметра довольно проста — не показывать кнопку «обновить», пока идет загрузка данных виджета.

Во вторых, процесс загрузки данных в фабрике я разделил на три этапа:

START — начало загрузки. На этом этапе состояние всех вьюшек адаптера и глобального флага загрузки меняется на «загружается».

MIDDLE — этап основной загрузки данных. После их загрузки глобальный флаг загрузки переводится в состояние «загружено», а в адаптере отображаются загруженные данные.

END — конец загрузки. Адаптеру на этом шаге не требуется изменять данные адаптера. Этот шаг нужен чтобы корректно обработать этап обновления вьюшек в WidgetProvider.

Давайте посмотрим подробнее как теперь выглядит обновление кнопки в провайдере:

А теперь посмотрим на то, что происходит в адаптере:

1. В конце этапов START и MIDDLE я вызываю метод updateWidgets для того, чтобы обновить состояние view управляемых провайдером.
2. После выполнения шага START для пользователя визуально отображается «загрузка» в ячейках виджета, и начнется этап MIDDLE.
3. Перед тем как вызвать обновление данных адаптера на шаге MIDDLE, провайдер скроет кнопку «обновить».
4. После выполнения шага MIDDLE, для пользователя будет отображаются новые данные и начнется этап END.
5. Перед тем как вызвать обновление данных адаптера, на шаге END, провайдер скроет кнопку «обновить». С точки зрения фабрики все данные будут актуальными, поэтому на шаге END меняем значение loadingStep на START.

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

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

Источник

Create a simple widget

App widgets are miniature application views that can be embedded in other applications (such as the home screen) and receive periodic updates. These views are referred to as widgets in the user interface, and you can publish one with an app widget provider (or widget provider). An app component that is able to hold other widgets is called an app widget host (or widget host). The following example shows a music widget.

Figure 1: Example of a music widget

This document describes how to publish a widget using a widget provider. For details on creating your own AppWidgetHost to host app widgets, see Build a widget host.

For information about how to design your widget, see App widgets overview.

Widget components

To create a widget, you need the following basic components:

AppWidgetProviderInfo object Describes the metadata for a widget, such as the widget’s layout, update frequency, and the AppWidgetProvider class. Defined in the XML in this document. AppWidgetProvider class Defines the basic methods that allow you to programmatically interface with the widget. Through it, you will receive broadcasts when the widget is updated, enabled, disabled, or deleted. AppWidgetProvider is declared in the manifest and then implemented, as described in this document. View layout Defines the initial layout for the widget. Defined in XML, as described in this document. Figure 2: App widget processing flow Note: Android Studio automatically creates a set of AppWidgetProviderInfo , AppWidgetProvider , and view layout files. Simply choose New > Widget > App Widget.

In addition to the required basic components, if your widget needs user configuration you should implement the App Widget configuration activity. This activity allows users to modify widget settings (for example, the time zone for a clock widget).

• Starting in Android 12 (API level 31), you can choose to provide a default configuration and allow users to reconfigure the widget later. See Use the widget’s default configuration and Enable users to reconfigure placed widgets for more details.
• In Android 11 (API level 30) or lower, this activity is launched every time the user adds the widget to their home screen.

Declare the AppWidgetProviderInfo XML

The AppWidgetProviderInfo defines the essential qualities of a widget. Define the AppWidgetProviderInfo object in an XML resource file using a single element and save it in the project’s res/xml/ folder.

Widget sizing attributes

The default home screen positions widgets in its window based on a grid of cells that have a defined height and width. Moreover, most home screens only allow widgets to take on sizes that are integer multiples of the grid cells (for example, 2 cells horizontally x 3 cells vertically).

The widget sizing attributes allow you to both specify a default size for your widget and provide lower and upper bounds on the size of the widget. In this context, the default size of a widget is the size that the widget will take on when it is first added to the home screen.

Attributes and description
targetCellWidth and targetCellHeight (Android 12), minWidth and minHeight	Starting in Android 12, the targetCellWidth and targetCellHeight attributes specify the default size of the widget in terms of grid cells. These attributes will be ignored in Android 11 and lower, and may be ignored if the home screen doesn’t support a grid-based layout. The minWidth and minHeight attributes specify the default size of the widget in dp. If the values for a widget’s minimum width or height don’t match the dimensions of the cells, then the values are rounded up to the nearest cell size. Note: We recommend specifying both the targetCellWidth / targetCellHeight and minWidth / minHeight sets of attributes, so that your app can fall back to using minWidth and minHeight if the user’s device doesn’t support targetCellWidth and targetCellHeight . If supported, the targetCellWidth and targetCellHeight attributes take precedence over the minWidth and minHeight attributes.
minResizeWidth and minResizeHeight	Specifies the widget’s absolute minimum size. These values should specify the size under which the widget would be illegible or otherwise unusable. Using these attributes allows the user to resize the widget to a size that may be smaller than the default widget size. The minResizeWidth attribute is ignored if it is greater than minWidth or if horizontal resizing isn’t enabled (see resizeMode ). Likewise, the minResizeHeight attribute is ignored if it is greater than minHeight or if vertical resizing isn’t enabled. Introduced in Android 4.0.
maxResizeWidth and maxResizeHeight	Specifies the widget’s recommended maximum size. If the values aren’t a multiple of the grid cell dimensions, they are rounded up to the nearest cell size. The maxResizeWidth attribute is ignored if it is smaller than minWidth or if horizontal resizing isn’t enabled (see resizeMode ). Likewise, the maxResizeHeight attribute is ignored if it is greater than minHeight or if vertical resizing isn’t enabled. Introduced in Android 12.
resizeMode	Specifies the rules by which a widget can be resized. You can use this attribute to make homescreen widgets resizeable—horizontally, vertically, or on both axes. Users long-press a widget to show its resize handles, then drag the horizontal and/or vertical handles to change its size on the layout grid. Values for the resizeMode attribute include horizontal , vertical , and none . To declare a widget as resizeable horizontally and vertically, use horizontal|vertical . Introduced in Android 3.1.

Example

To illustrate how the attributes in the preceding table affect widget sizing, assume the following specifications:

• A grid cell is 30dp wide and 50dp tall.
• The following attribute specification is provided.

Starting with Android 12:

We will use the targetCellWidth and targetCellHeight attributes as the default size of the widget.

The widget’s size will be 2×2 by default. The widget can be resized down to 2×1 or resized up to 4×3.

Android 11 and lower:

We will use the minWidth and minHeight attributes to compute the default size of the widget.

The default width = Math.ceil(80 / 30) = 3

The default height = Math.ceil(80 / 50) = 2

The widget’s size will be 3×2 by default. The widget can be resized down to 2×1 or resized up to take up the full screen.

Additional widget attributes

Attributes and description
updatePeriodMillis	Defines how often the widget framework should request an update from the AppWidgetProvider by calling the onUpdate() callback method. The actual update is not guaranteed to occur exactly on time with this value and we suggest updating as infrequently as possible—perhaps no more than once an hour to conserve the battery. For the full list of considerations to pick an appropriate update period, see Optimizations for updating widget content.
initialLayout	Points to the layout resource that defines the widget layout.
configure	Defines the activity that launches when the user adds the widget, allowing them to configure widget properties. See Enable users to configure widgets. (Starting in Android 12, your app can skip the initial configuration. See Use the widget’s default configuration for details.)
description	Specifies the description for the widget picker to display for your widget. Introduced in Android 12.
previewLayout (Android 12) and previewImage (Android 11 and lower)	Starting in Android 12, the previewLayout attribute specifies a scalable preview, which you’ll provide as an XML layout set to the widget’s default size. Ideally, the layout XML specified as this attribute should be the same layout XML as the actual widget with realistic default values. In Android 11 or lower, the previewImage attribute specifies a preview of what the widget will look like after it’s configured, which the user sees when selecting the app widget. If not supplied, the user instead sees your application’s launcher icon. This field corresponds to the android:previewImage attribute in the element in the AndroidManifest.xml file. Note: We recommend specifying both the previewImage and previewLayout attributes, so that your app can fall back to using previewImage if the user’s device doesn’t support previewLayout . For more details, see Backward-compatibility with scalable widget previews.
autoAdvanceViewId	Specifies the view ID of the widget subview that should be auto-advanced by the widget’s host. Introduced in Android 3.0.
widgetCategory	Declares whether your widget can be displayed on the home screen ( home_screen ), the lock screen ( keyguard ), or both. Only Android versions lower than 5.0 support lock-screen widgets. For Android 5.0 and higher, only home_screen is valid.
widgetFeatures	Declares features supported by the widget. For example, if you’d like your widget to use its default configuration when a user adds it, specify both the configuration_optional and reconfigurable flags. This bypasses launching the configuration activity after a user adds the widget. (The user can still reconfigure the widget afterwards.)

Use the AppWidgetProvider class to handle widget broadcasts

The AppWidgetProvider class handles widget broadcasts and updates the widget in response to widget lifecycle events. The following sections describe how to declare AppWidgetProvider in the manifest and then implement it.

Declare a widget in the manifest

First, declare the AppWidgetProvider class in your application’s AndroidManifest.xml file. For example:

The element requires the android:name attribute, which specifies the AppWidgetProvider used by the widget. The component should not be exported unless a separate process needs to broadcast to your AppWidgetProvider , which is usually not the case.

The element must include an element with the android:name attribute. This attribute specifies that the AppWidgetProvider accepts the ACTION_APPWIDGET_UPDATE broadcast. This is the only broadcast that you must explicitly declare. The AppWidgetManager automatically sends all other widget broadcasts to the AppWidgetProvider as necessary.

The element specifies the AppWidgetProviderInfo resource and requires the following attributes:

• android:name : Specifies the metadata name. Use android.appwidget.provider to identify the data as the AppWidgetProviderInfo descriptor.
• android:resource : Specifies the AppWidgetProviderInfo resource location.

Implement the AppWidgetProvider class

The AppWidgetProvider class extends BroadcastReceiver as a convenience class to handle widget broadcasts. It receives only the event broadcasts that are relevant to the widget, such as when the widget is updated, deleted, enabled, and disabled. When these broadcast events occur, the following AppWidgetProvider methods are called:

onUpdate() This is called to update the widget at intervals defined by the updatePeriodMillis attribute in the AppWidgetProviderInfo. (See the table describing additional widget attributes in this document). This method is also called when the user adds the widget, so it should perform the essential setup, such as define event handlers for View objects or start a job to load data to be displayed in the widget. However, if you have declared a configuration activity without the configuration_optional flag, this method is not called when the user adds the widget, but is called for the subsequent updates. It is the responsibility of the configuration activity to perform the first update when configuration is complete. (See Creating a widget configuration activity.) The most important callback is onUpdate() . See Handle events with the onUpdate() class in this document for more information. onAppWidgetOptionsChanged()

This is called when the widget is first placed and any time the widget is resized. Use this callback to show or hide content based on the widget’s size ranges. Get the size ranges—and, starting in Android 12, the list of possible sizes a widget instance can take—by calling getAppWidgetOptions() , which returns a Bundle that includes the following:

• OPTION_APPWIDGET_MIN_WIDTH : Contains the lower bound on the width, in dp units, of a widget instance.
• OPTION_APPWIDGET_MIN_HEIGHT : Contains the lower bound on the height, in dp units, of a widget instance.
• OPTION_APPWIDGET_MAX_WIDTH : Contains the upper bound on the width, in dp units, of a widget instance.
• OPTION_APPWIDGET_MAX_HEIGHT : Contains the upper bound on the height, in dp units, of a widget instance.
• OPTION_APPWIDGET_SIZES : Contains the list of possible sizes ( List ), in dp units, a widget instance can take. Introduced in Android 12.

onDeleted(Context, int[])

This is called every time a widget is deleted from the widget host.

This is called when an instance the widget is created for the first time. For example, if the user adds two instances of your widget, this is only called the first time. If you need to open a new database or perform another setup that only needs to occur once for all widget instances, then this is a good place to do it.

This is called when the last instance of your widget is deleted from the widget host. This is where you should clean up any work done in onEnabled(Context) , such as delete a temporary database.

This is called for every broadcast and before each of the preceding callback methods. You normally don’t need to implement this method because the default AppWidgetProvider implementation filters all widget broadcasts and calls the preceding methods as appropriate.

You must declare your AppWidgetProvider class implementation as a broadcast receiver using the element in the AndroidManifest . See Declare a widget in the manifest in this document.

Handle events with the onUpdate() class

The most important AppWidgetProvider callback is onUpdate() because it is called when each widget is added to a host (unless you use a configuration activity without the configuration_optional flag). If your widget accepts any user interaction events, then you need to register the event handlers in this callback. If your widget doesn’t create temporary files or databases, or perform other work that requires clean-up, then onUpdate() may be the only callback method you need to define. For example, if you want a widget with a button that launches an activity when clicked, you could use the following implementation of AppWidgetProvider :

Kotlin

This AppWidgetProvider defines only the onUpdate() method for the purpose of creating a PendingIntent that launches an Activity and attaching it to the widget’s button with setOnClickPendingIntent(int, PendingIntent) . Notice that it includes a loop that iterates through each entry in appWidgetIds , which is an array of IDs that identify each widget created by this provider. In this way, if the user creates more than one instance of the widget, then they are all updated simultaneously. However, only one updatePeriodMillis schedule will be managed for all instances of the widget. For example, if the update schedule is defined to be every two hours, and a second instance of the widget is added one hour after the first one, then they will both be updated on the period defined by the first one and the second update period will be ignored (they’ll both be updated every two hours, not every hour).

Note: Because AppWidgetProvider is an extension of BroadcastReceiver , your process is not guaranteed to keep running after the callback methods return (see BroadcastReceiver for information about the broadcast lifecycle). If your widget setup process can take several seconds (perhaps while performing web requests) and you require that your process continues, consider starting a Task using WorkManager in the onUpdate() method. From within the task, you can perform your own updates to the widget without worrying about the AppWidgetProvider closing down due to an Application Not Responding (ANR) error.

Receive widget broadcast Intents

AppWidgetProvider is just a convenience class. If you would like to receive the widget broadcasts directly, you can implement your own BroadcastReceiver or override the onReceive(Context,Intent) callback. The Intents you need to care about are as follows:

Create the widget layout

You must define an initial layout for your widget in XML and save it in the project’s res/layout/ directory. Refer to Design guidelines for details.

Creating the widget layout is simple if you’re familiar with layouts. However, be aware that widget layouts are based on RemoteViews , which do not support every kind of layout or view widget. You cannot use custom views or subclasses of the views that are supported by RemoteViews .

RemoteViews also supports ViewStub , which is an invisible, zero-sized View you can use to lazily inflate layout resources at runtime.

Support for stateful behavior

Android 12 adds new support for stateful behavior using the following existing components:

The widget is still stateless. Your app must store the state and register for state change events.

Figure 3: Example of stateful behavior Note: Always explicitly set the current checked state using RemoteViews.setCompoundButtonChecked , or you may encounter unexpected results when your widget is dragged or resized.

The following code example shows how to implement these components.

Kotlin

Provide two different layouts, with one targeting devices running Android 12 or higher ( res/layout-v31 ) and the other targeting previous Android 11 or lower (in the default res/layout folder).

Implement rounded corners

Android 12 introduces the following system parameters to set the radii of your widget’s rounded corners:

system_app_widget_background_radius : The corner radius of the widget background, which will never be larger than 28dp.

system_app_widget_inner_radius : The corner radius of any view inside the widget. This is exactly 8dp less than the background radius to align nicely when using an 8dp padding.

The following example shows a widget that uses system_app_widget_background_radius for the corner of the widget and system_app_widget_inner_radius for views inside the widget.

Figure 4: Rounded corners

1 Corner of the widget.

2 Corner of a view inside the widget.

Important considerations for rounded corners

• Third-party launchers and device manufacturers can override the system_app_widget_background_radius parameter to be smaller than 28dp. The system_app_widget_inner_radius parameter will always be 8dp less than the value of system_app_widget_background_radius .
• If your widget doesn’t use @android:id/background or define a background that clips its content based on the outline (with android:clipToOutline set to true ), the launcher tries to automatically identify the background and clip the widget using a rectangle with rounded corners of up to 16dp. See Ensure your widget is compatible with Android 12).

To ensure widget compatibility with previous versions of Android, we recommend defining custom attributes and using a custom theme to override them for Android 12, as shown in the following examples of XML files:

/values/attrs.xml

/values/styles.xml

/values-31/styles.xml

/drawable/my_widget_background.xml

/layout/my_widget_layout.xml

Content and code samples on this page are subject to the licenses described in the Content License. Java is a registered trademark of Oracle and/or its affiliates.

Источник