ios - para - tag heuer connected modular 45 iphone

Dónde y cuándo obtener datos para la complicación del reloj

Question

Después de trabajar con complicaciones durante unos días, me siento confiado al decir lo siguiente sobre el proceso de actualización para las actualizaciones que ocurren en un intervalo prescrito:

• El sistema llama a requestedUpdateDidBegin()
  • Aquí es donde puede determinar si sus datos han cambiado. Si no es así, tu aplicación no tiene que hacer nada. Si sus datos han cambiado, debe llamar a:
    • reloadTimelineForComplication si necesita restablecer todos sus datos.
    • extendTimelineForComplication si solo necesita agregar nuevos elementos al final de la línea de tiempo de la complicación.
  • Nota: el sistema puede en realidad llamar a requestedUpdateBudgetExhausted() lugar de a requestedUpdateDidBegin() si ha gastado demasiado del presupuesto de tiempo de su complicación para el día. Esta es la razón de esta pregunta.
• Si llamó a reloadTimelineForComplication , el sistema llamará getCurrentTimelineEntryForComplication (junto con las variantes futuras y pasadas que obtienen arreglos, dependiendo de la configuración de viaje en el tiempo)
• Esta es una conjetura, ya que aún no la he probado, pero creo que si llama a extendTimelineForComplication solo se getTimelineEntriesForComplication(... afterDate date: NSDate ...) .
• Luego, el sistema llamará a getNextRequestedUpdateDateWithHandler para que pueda especificar durante cuánto tiempo hasta que su complicación requiera una nueva actualización.

La documentación de Apple es bastante clara: no debe solicitar actualizaciones con demasiada frecuencia o realizar un procesamiento excesivo en el código de la complicación o agotará su presupuesto de tiempo y la complicación dejará de actualizarse. Entonces, mi pregunta es: ¿dónde y cuándo hace la actualización?

Para el contexto, mi escenario es una URL con datos de retorno que cambia hasta dos veces por hora.

El lugar más obvio en el que colocar el código de recuperación de URL es la func requestedUpdateDidBegin() Recupera los datos, los almacena y, si no hay cambios, simplemente regresa. Si hubo un cambio, entonces extienda o vuelva a cargar la línea de tiempo.

Sin embargo, una recuperación de URL puede ser costosa. Alternativas:

• Coloque el código en la aplicación del teléfono y envíelo con una WCSession , pero si el usuario cierra esa aplicación, las actualizaciones ya no sucederán.
• Use actualizaciones de inserción, pero esta no es una aplicación web, por lo que no tengo dónde enviarlas.
• Obviamente actualizaré todos los datos cuando el usuario interactúe con la aplicación del reloj, pero eso ahora significa que solo se actualiza cuando el usuario usa la aplicación, lo que niega la necesidad de una complicación.

¿Hay algún otro lugar? ¿Puedo tener una función periódica en la aplicación de reloj que no sea parte de la complicación? ¿Dónde está el lugar correcto para obtener los datos para una actualización de complicaciones?

Answer 1

Para watchOS 3, Apple recomienda que getNextRequestedUpdateDate de usar la getNextRequestedUpdateDate datos de complicaciones getNextRequestedUpdateDate programada para actualizar tu complicación.

El viejo camino para watchOS 2

requestedUpdateDidBegin() realmente solo está diseñado para actualizar la complicación. Mantener su complicación (y ver la aplicación) actualizada generalmente implica mucho más que volver a cargar la línea de tiempo (y recuperar datos de forma asíncrona nunca encaja bien con el enfoque anterior).

La nueva forma de watchOS 3.

El nuevo y mejor enfoque es utilizar las tareas de la aplicación de actualización en segundo plano . Puede usar una serie de tareas en segundo plano para schedule y handle la extensión de la aplicación que se está activando en segundo plano para:

• Adquirir Nuevos Datos

  • usar WKWatchConnectivityRefreshBackgroundTask para obtener datos del teléfono, o
  • uso de WKURLSessionRefreshBackgroundTask para descargar datos de un servidor
• actualiza tu modelo una vez que lleguen los datos,
• actualice su complicación desde el modelo (recargando o extendiendo la línea de tiempo), y finalmente
• actualice la instantánea del dock de su aplicación para mostrar los datos en el dock

Llame al método setTaskCompleted cada tarea tan pronto como se complete la tarea.

Otros beneficios del uso de tareas de aplicaciones

Una de las características clave de este diseño es que la extensión del reloj ahora puede manejar una variedad de escenarios de primer plano y de fondo que cubren:

• inicialmente cargando datos cuando su aplicación / complicación comienza,
• actualizar los datos en segundo plano, cuando la extensión es activada por una tarea en segundo plano, y
• actualizar los datos en primer plano, cuando el usuario reanude su aplicación desde el dock.

Apple recomienda que utilice cada oportunidad que se le brinde, independientemente de si su aplicación está en primer plano o en segundo plano para mantener su complicación, aplicación y instantánea de acoplamiento actualizadas.

¿Existen limitaciones?

El número total de tareas disponibles por día se divide entre el número de aplicaciones en el dock. Cuantas menos aplicaciones haya en el dock, más tareas podrá utilizar. Cuantas más aplicaciones haya en el dock, menos podrá utilizar.

• Si su complicación está activa, su aplicación puede despertarse al menos cuatro veces por hora.

• Si su complicación no está activa, se garantiza que su aplicación se activará al menos una vez por hora.

Como su aplicación ahora se ejecuta en segundo plano, se espera que complete sus tareas en segundo plano de manera eficiente y rápida.

Las tareas en segundo plano están limitadas por la cantidad de tiempo de CPU y el uso de CPU permitido. Si excede el tiempo de CPU (o usa más del 10% de la CPU mientras está en segundo plano), el sistema terminará su aplicación (lo que provocará un bloqueo).

Para más información

• Una buena introducción que explica cuándo y por qué actualizar la aplicación de su reloj se trata en Diseñar grandes experiencias de Apple Watch .

• Para información específica, la sesión actualizada de la aplicación Keeping Your Watch cubre todo lo que necesita saber para mantener al día su complicación, aplicación y instantánea de acoplamiento.

• WatchBackgroundRefresh código de ejemplo de WatchBackgroundRefresh muestra cómo usar la WKRefreshBackgroundTask para actualizar las aplicaciones de WatchKit en segundo plano.

Answer 2

Edit: El Tea (op) ha publicado una buena respuesta en https://.com/a/32994055/630614

Esta es una pregunta / problema interesante, ¡y me he estado preguntando acerca de muchas de las mismas!

En su mayor parte, parece que cuando estoy trabajando en una nueva complicación necesito dar un paso atrás y ver cuándo realmente quiero actualizarla. Una complicación de "cuenta regresiva" podría establecer todas las entradas futuras de la línea de tiempo al mismo tiempo, cuando se establece la "fecha de finalización". Una aplicación que muestra el estado actual de un servicio web podría tener datos relevantes almacenados en NSUserDefaults cuando se recibe un APNS.

Si no tiene acceso a APNS, no desea ejecutar su aplicación iOS en un modo en segundo plano y no desea realizar solicitudes HTTP desde Apple Watch, puedo pensar en otras 2 opciones.

1) Programar notificaciones locales. La parte buena es que su Apple Watch debe ejecutar didReceiveLocalNotification , pero la parte mala es que el usuario recibirá una notificación cuando simplemente esté tratando de verificar el estado sin interrupciones.

2) Envíe un mensaje a iOS a través de sendMessage(_:replyHandler:errorHandler:) en su método reloadTimelineForComplication , configurando nil para que replyHandler haga lo más rápido posible:

Al llamar a este método desde su extensión WatchKit mientras está activo y en ejecución, se activa la aplicación iOS correspondiente en segundo plano y se hace accesible.

Su aplicación iOS podría realizar las solicitudes de red necesarias y luego almacenar la información o enviarla a Apple Watch. Desafortunadamente, no creo que la extensión del reloj haga que se llame a session.didReceive... hasta que lo ejecute, pero podría acceder a los datos en la próxima llamada a requestedUpdateDidBegin .

Como dije, estoy muy interesado en esta misma cosa, así que vuelva a publicar algunas ideas y quizás podamos extrapolar algunas de las mejores prácticas aquí.