Итак, удаленные представления успешно загружены в методе onUpdate класса AppWidgetProvider. Теперь необходимо связать удаленное списковое представление со службой удаленного представления, чтобы эта служба могла вернуть адаптер удаленного представления, который наполнит удаленное списковое представление.
Почему именно со службой? Почему бы ни привязать фабрику удаленных представлений напрямую к удаленному списковому представлению?
Поскольку AppWidgetProvider — это широковещательный приемник, метод onUpdate поставщика виджетов выполняется в рамках временных ограничений широковещательного приемника. Во избежание возникновения критических условий, связанных со временем, в Android. работа по наполнению спискового представления делегируется отдельной службе, унаследованной от android. widget.RemoteViewsService. После этого служба RemoteViewsService отвечает за возврат адаптера списка, который может наполнить список. Адаптер должен относиться к типу RemoteViewsService. RemoteViewsFactory. В некотором смысле это механическая процедура окончательного получения удаленного спискового представления с помощью фабрики удаленных списковых представлений.
В пример кода службы удаленного представления, которая возвращает фабрику удаленных представлений.
В обратите внимание на следующие моменты.
Новый класс должен быть унаследован от RemoteViewsService.
Понадобится специализировать класс RemoteViewsFactory и вернуть фабрику. Эта фабрика вскоре будет рассмотрена.
Будучи службой, унаследованный класс RemoteViewsService (в данном случае TestRemoteViewsService) должен быть также объявлен в файле манифеста.
Как только код класса RemoteViewsService написан, эту службу можно присоединить к объекту удаленного спискового представления, используя код . (Вспомните, что этот код выполняется в методе onUpdate класса AppWidgetProvider.)
В сначала создается явное намерение с указанием для него класса RemoteViewsService. Затем это намерение присоединяется к удаленному списковому представлению с помощью вызова метода setRemoteAdapter и передачи ему идентификатора спискового представления. Передаваемое здесь намерение — это то же самое намерение, которое доставляется методу onGetViewFactory класса RemoteViewsService . Более того, Android использует это намерение для кеширования фабрики, возвращаемой методом onGetViewFactory.
Метод onGetViewFactory поддерживает возможность проверки природы намерения и возврата разных фабрик в зависимости от намерения. Это может оказаться полезным, если одна и та же служба указывается в качестве целевой для множества списковых представлений в виджете. Не вдаваясь в подробные объяснения причин, отметим, что если вы не хотите, чтобы фабрика не кешировалась, тогда должны конструировать эти намерения уникальными. Для обеспечения уникальности намерений можно использовать идентификатор виджета как дополнительные данные.
Хотя заполнение списка делегировано RemoteViewsService, http://www.express-dostavka.com/ за наполнение спискового представления, в конечном счете, отвечает RemoteViewsFactory. Таким образом, для наполнения спискового представления потребуется вначале реализовать адаптероподобный интерфейс RemoteViewsFactory. (Списковые элементы управления и адаптеры списков были описаны .)
В ы сигнатуры ключевых методов класса, реализующего этот интерфейс фабрики.
Давайте посмотрим, что должен делать каждый из этих методо. Начнем с конструктора.
Опубликовал Kest
February 14 2015 14:06:24 ·
0 Комментариев ·
2997 Прочтений ·
• Не нашли ответ на свой вопрос? Тогда задайте вопрос в комментариях или на форуме! •
Комментарии
Нет комментариев.
Добавить комментарий
Рейтинги
Рейтинг доступен только для пользователей.
Пожалуйста, залогиньтесь или зарегистрируйтесь для голосования.
Нет данных для оценки.
Гость
Вы не зарегистрированны? Нажмите здесь для регистрации.
Главная
Каталог файлов
