Requisitos de los metadatos

Esta guía es compatible con Health Connect versión 1.1.0-alpha12 y versiones posteriores.

Se realizaron cambios en los metadatos de Health Connect para los desarrolladores que se actualicen a la versión 1.1.0-alpha12 o una posterior.

Información de la biblioteca

El ID del artefacto del complemento de Android para Gradle de Google Maven identifica la biblioteca de Health Connect a la que te deberás actualizar. Agrega esta dependencia del SDK de Health Connect a tu archivo build.gradle del módulo:

dependencies {
  implementation "androidx.health.connect:connect-client:1.1.0-alpha12"
}

Cambios de metadatos

Se introdujeron dos cambios de metadatos en el SDK de Health Connect Jetpack a partir de la versión 1.1.0-alpha12 para ayudar a verificar que existan metadatos útiles adicionales en el ecosistema. Si metadata no está incluido en tu constructor Record, es posible que veas un error Constructor internal.

Cómo especificar el método de registro

Debes especificar los detalles de los metadatos cada vez que se cree una instancia de un objeto de tipo Record().

Cuando escribas datos en Health Connect, debes especificar uno de los cuatro métodos de registro con uno de los métodos de fábrica correspondientes para crear una instancia de Metadata:

Por ejemplo:

 StepsRecord(
    startTime = Instant.ofEpochMilli(1234L),
    startZoneOffset = null,
    endTime = Instant.ofEpochMilli(1236L),
    endZoneOffset = null,
    metadata = Metadata(),
    count = 10
)
HealthConnectManager.kt

Tipo de dispositivo

Debes especificar un tipo de dispositivo para todos los datos registrados de forma automática y activa. Para obtener más detalles, consulta la Device clase en la documentación de Jetpack. Los tipos de dispositivos actuales incluyen los siguientes:

Algunos valores de Device.type solo están disponibles en versiones posteriores de Health Connect. Cuando la función de tipos de dispositivos extendidos no está disponible, estos tipos se tratan como Device.TYPE_UNKNOWN.

if (healthConnectClient
     .features
     .getFeatureStatus(
       HealthConnectFeatures.FEATURE_EXTENDED_DEVICE_TYPES
     ) == HealthConnectFeatures.FEATURE_STATUS_AVAILABLE) {

  // Feature is available
} else {
  // Feature isn't available
}

Por ejemplo:

 val WATCH_DEVICE = Device(
    manufacturer = "Google",
    model = "Pixel Watch",
    type = Device.TYPE_WATCH
)

// Phone
 val PHONE_DEVICE = Device(
    manufacturer = "Google",
    model = "Pixel 8",
    type = Device.TYPE_PHONE
)

// Ring
 val RING_DEVICE = Device(
    manufacturer = "Oura",
    model = "Ring Gen3",
    type = Device.TYPE_RING
)

// Scale
 val SCALE_DEVICE = Device(
    manufacturer = "Withings",
    model = "Body Comp",
    type = Device.TYPE_SCALE
)
HealthConnectManager.kt

Fragmentos actualizados

Se actualizaron las guías de Health Connect en todos los casos en que se necesitaban fragmentos nuevos para cumplir con los nuevos requisitos de metadatos. Para ver algunos ejemplos, consulta la página sobre cómo escribir datos.

Nuevos métodos de metadatos

Ya no se pueden crear instancias de metadatos directamente, por lo que debes usar uno de los métodos de fábrica para obtener una instancia nueva de metadatos. Los métodos de fábrica verifican que se proporcione información del dispositivo cuando se usó un dispositivo o sensor para registrar los datos. En el caso de los datos ingresados de forma manual, proporcionar información del dispositivo sigue siendo opcional. Cada función tiene tres variantes de firma:

• activelyRecorded

  • fun activelyRecorded(device: Device): Metadata.
  • fun activelyRecorded(clientRecordId: String, clientRecordVersion: Long = 0, device: Device): Metadata
  • fun activelyRecordedWithId(id: String, device: Device): Metadata

• autoRecorded

  • fun autoRecorded(device: Device): Metadata
  • fun autoRecorded(clientRecordId: String, clientRecordVersion: Long = 0, device: Device): Metadata
  • fun autoRecordedWithId(id: String, device: Device): Metadata

• manualEntry

  • fun manualEntry(device: Device? = null): Metadata
  • fun manualEntry(clientRecordId: String, clientRecordVersion: Long = 0, device: Device? = null): Metadata
  • fun manualEntryWithId(id: String, device: Device? = null): Metadata

• unknownRecordingMethod

  • fun unknownRecordingMethod(device: Device? = null): Metadata
  • fun unknownRecordingMethod(clientRecordId: String, clientRecordVersion: Long = 0, device: Device? = null): Metadata
  • fun unknownRecordingMethodWithId(id: String, device: Device? = null): Metadata

Para obtener más información, consulta el Proyecto de código abierto de Android.

Datos de prueba

Usa la biblioteca de pruebas y MetadataTestHelper para simular valores de metadatos esperados:

private val TEST_METADATA =
    Metadata.unknownRecordingMethod(
        clientRecordId = "clientId",
        clientRecordVersion = 1L,
        device = Device(type = Device.TYPE_UNKNOWN),
    ).populatedWithTestValues(id = "test")

Esto simula el comportamiento de la implementación de Health Connect, que propaga automáticamente estos valores durante la inserción de registros.

Para la biblioteca de pruebas, debes agregar esta dependencia del SDK de Health Connect a tu archivo build.gradle del módulo:

dependencies {
  testImplementation "androidx.health.connect:connect-testing:1.0.0-alpha02"
}

Actualiza la biblioteca

Los pasos principales que debes realizar son los siguientes:

1. Actualiza tu biblioteca a la versión 1.1.0-alpha12.

2. Cuando compiles la biblioteca, se generarán errores de compilación cuando se necesiten metadatos nuevos. Para resolver estos errores y completar la migración, verifica que realices los siguientes cambios:

   • Es obligatorio especificar un método de registro cuando se construye un Record. Para ello, usa uno de los métodos de fábrica proporcionados en Metadata, como Metadata.manualEntry() o Metadata.activelyRecorded(device = Device(...)).
   • En el caso de los datos registrados por un dispositivo, es obligatorio especificar un tipo de dispositivo, como Device.TYPE_WATCH o Device.TYPE_PHONE.

3. Si tu app escribe tipos de dispositivos extendidos, colócalos detrás de FEATURE_EXTENTED_DEVICE_TYPES para evitar TYPE_UNKNOWN inesperados en dispositivos en los que la función no está disponible.