Проблемы с Android Wear 2.0 Архитектура для осложнений в реальном времени

Question

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

У набора будут сложности с ЧСС, координатами GPS, часами, минутами, секундами, датой дд / мм, датой дд / мм / гг, батареей и т. Д.

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

Обратите внимание, что некоторые из этих действий могут быть характерны для Huawei Watch 2 LTE.

1) Обновление интервала push / pull.

Под усложнениями я понимаю провайдеров данных, чья единственная обязанность состоит в том, чтобы предоставлять данные тому, кто их называет. Это означает, что мы не уверены (и мы полагаемся на разработчика циферблата), чтобы знать о сложностях и запрашивать обновления соответственно. Это делает некоторые сложности совершенно бесполезными, если они не обновляются во времени (например, отображать секунды). Также могут возникнуть сложности с отображением старых данных (например, старые GPS-координаты, старый сердечный ритм ударов в минуту). Итак, я решил реализовать ProviderUpdateRequester с AlarmManager выдвинуть данные на циферблат. Проблема снова в том, что осложнения должны происходить быстрее, например, за секунды, так как Android будет блокировать ожидающие намерения, если они запланированы слишком часто. Поэтому, чтобы обойти это, я решил использовать обработчики Android в одном и том же экземпляре службы, что оказалось не очень хорошей идеей из-за следующей темы.

2) Жизненный цикл усложнения

Отладкой я обнаружил, что экземпляр ComplicationProviderService объект, который выполняется onComplicationActivated, onComplicationUpdate, onComplicationDeactivated может быть другим. Это означает, что это не липкая служба (один экземпляр), которая будет всегда работать, но каждое обновление создает новый экземпляр службы. Это проблематично из-за серьезных сложностей инициализации: например, GPS или монитора сердечного ритма, который должен прослушивать новые значения, и для получения первого значения может потребоваться некоторое время. А также, для тех сложностей, которые не могут полагаться на AlarmManager и / или должны поддерживать какое-то состояние между выполнением обновлений.

3) Показать осведомленный сервис

Чтобы обойти предыдущий пункт, скажем, у вас есть статические переменные в вашем сервисе усложнения, которые инициализируются onComplicationActivated и отключен в onComplicationDeactivated, Например, это может быть получение ссылки на LocationProvider и начало прослушивания обновлений местоположения. Это будет гарантировать, что каждый вызов onComplicationUpdate не нужно будет выполнять интенсивную / холодную инициализацию и иметь доступ к самым современным данным. Однако это также означает, что ваша логика будет выполнена независимо от того, onComplicationUpdate называется или нет. В режиме окружающей среды (или выключенном экране) циферблат может решить не обновлять усложнение, не вызывая onComplicationUpdate, но он не знает ни о нашей статической логике, ни о ComplicationProviderService имеет обратный вызов, когда экран переходит в режим окружающей среды или включается / выключается. Это проблема, потому что в нашем примере, если экран выключен, мы все еще будем слушать GPS-координаты и, скорее всего, разряжать батарею. Конечно, мы можем справиться с этим, используя комбинацию BroadcastReceiver (Intent.ACTION_SCREEN_ON/OFF) и DisplayManager.DisplayListener, но опять же, не уверен, что я выбрал правильный путь здесь, потому что это будет означать, что мы сейчас создаем сервисы, которые должны быть статически осведомлены о состоянии дисплея.

4) Обнаружение экрана вкл / выкл

BroadcastReceiver за Intent.ACTION_SCREEN_ON/OFF работает должным образом, когда режим окружающей среды отключен, но не включен. Когда режим окружающей среды включен, Intent.ACTION_SCREEN_OFF отправляется при переходе в режим окружающей среды, но Intent.ACTION_SCREEN_ON не отправляется при выходе из окружающего режима. Хотя это немного сложнее, это может быть достигнуто с помощью DisplayManager.DisplayListener чтобы получать обновления на onDisplayChanged Перезвоните.

TL; RD

1) Как вы гарантируете, что на циферблатах своевременно отображаются ваши осложнения, чтобы всегда иметь правильную и самую актуальную информацию?

2) Как вы справляетесь с тяжелой / холодной инициализацией ComplicationProviderService если каждый раз onComplicationUpdate называется экземпляр службы отличается?

3) Делать что-то с большим вниманием к показу сервиса - это безумие?

4) Технически экран все еще включен в режиме окружающей среды, так почему Intent.ACTION_SCREEN_OFF транслируется? Почему нет Intent.ACTION_SCREEN_ON/OFF симметричный, когда включен режим окружающей среды?

5) Может быть, осложнения не следует использовать для раскрытия информации в реальном времени?

большое спасибо

Answer 1

Пара вещей для распаковки:

• Осложнения не предназначены для частого обновления (считайте минуты, а не секунды) - это для экономии заряда батареи.
• ProviderUpdateRequester предназначен для (в среднем нечастых) нерегулярных обновлений, таких как сообщения, поступающие через приложение чата.
• Сложности, зависящие от времени - не существует "обновления" как такового, но Wear предоставляет разработчикам способы для обратного отсчета с определенного времени и для отображения поля, относящегося к дате (мировое время, день месяца), при этом провайдер не отправляет все обновления системы время. Для этого последнего, пожалуйста, обратитесь к документам для ComplicationText.TimeDifferenceBuilder а также ComplicationText.TimeFormatBuilder,

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

Надеюсь, это поможет.