Uso de propiedades complementarias

Resumen

• Las propiedades complementarias permiten a las aplicaciones etiquetar archivos con propiedades sin cambiar el archivo
• Resulta útil para los casos en los que tiene propiedades difíciles de calcular o el archivo no se puede modificar.
• El uso de propiedades complementarias es el mismo que el uso de cualquier otra propiedad en el sistema de propiedades de Windows

Introducción

Muchas de las nuevas aplicaciones interesantes de los últimos años requieren la ejecución de operaciones intensivas de CPU en archivos de usuario para extraer propiedades útiles de los archivos más allá de aspectos básicos, como la fecha de creación. Estas aplicaciones realizan el reconocimiento de objetos en imágenes, extracción de intenciones en correos electrónicos y análisis de texto para agrupar documentos. Esto está siendo impulsado por la potencia informática que ahora está disponible en la mayoría de los ordenadores personales.  

Hacer que estos metadatos se puedan buscar al instante permite a los usuarios ser exponencialmente más productivos. Simplemente sabiendo que tu hija está en una foto es interesante, pero ser capaz de buscar la imagen de ella con su abuela es mucho más útil. Hace que la experiencia de usar un ordenador se sienta más personal y más vivo. Parece que alguien desde la máquina se está acercando para ayudarle a encontrar sus recuerdos valiosos.

Durante décadas, la solución para la búsqueda rápida en Windows ha sido el indexador y en Creators Update se ha actualizado para admitir estos nuevos escenarios. Las aplicaciones ahora pueden etiquetar archivos con propiedades adicionales más allá de las que extrae el sistema. Estas propiedades se tratan como ciudadanos de primera clase

Propiedades de Windows

El sistema de propiedades de Windows ha sido una parte clave de la interacción con archivos durante años. Permite a las aplicaciones leer propiedades de archivos sin tener que entender los elementos internos de todos los diferentes formatos de archivo o idiomas en los que podría estar un archivo. Como desarrollador, todo está abstraído para usted: solo tiene que solicitar una lista y especificar si es en orden ascendente o descendente.

El sistema de propiedades está entrelazado con el indexador de Windows: lee todas las propiedades de los archivos dentro de su ámbito y los almacena. Más adelante, cuando una aplicación solicita una lista de todos los .docx de una carpeta que se va a ordenar por fecha de modificación, excepto los creados por John Smith, el indexador puede devolver la lista al instante.

La desventaja de cómo funcionan juntos estos sistemas es que el indexador solía requerir que todas las propiedades que almacenaría sobre un archivo estuvieran disponibles de inmediato. Esto lo limitó en conocer propiedades más interesantes que requieren más tiempo para calcularse, ya que hay una restricción de tiempo estricta.

Aunque el uso de propiedades es fácil, la aplicación puede solicitar un conjunto ordenado de propiedades sobre un archivo, al igual que trabajar con una base de datos, o bien puede pasar una consulta como mediante un motor de búsqueda. El indexador procesará la consulta y devolverá los resultados. Esto proporciona a los desarrolladores la flexibilidad de combinar sus filtros (por ejemplo, solo buscar archivos jpg) con la consulta del usuario (nombre de archivo a partir de "bird").

Propiedades complementarias

Las propiedades complementarias se comportan de forma idéntica a las propiedades normales de Windows con una diferencia muy importante: no se escribirán cuando el archivo se agregue al indexador. Otra aplicación del sistema debe agregar una propiedad complementaria más adelante. Podrían pasar dos minutos una vez que se complete el reconocimiento de objetos o podrían pasar días.

Una vez escrita la propiedad, se puede buscar, filtrar, ordenar o agrupar como cualquier otra propiedad del sistema. También se puede usar en consultas combinadas con otras propiedades del sistema, ya sea complementarias o no. Esto le ofrece la flexibilidad de combinar fácilmente las propiedades complementarias con el código del sistema de archivos existente sin tener que realizar una reescritura.

Escenarios de ejemplo

Hay miles de propiedades diferentes que podría escribir en una propiedad complementaria, pero hay un par de escenarios clave a los que este tutorial seguirá volviendo a:

Etiquetado de imágenes con propiedades extraídas

Estas aplicaciones pueden usar un modelo entrenado por ML para extraer características de una imagen que el sistema no conoce, como el objeto de la imagen. A continuación, puede tomar los objetos que identifica en la imagen y agregarlos al sistema de propiedades para buscar o agruparlos más adelante.

Etiquetado de archivos con un identificador específico de la aplicación

Muchas aplicaciones de sincronización de archivos usan su propio identificador único para realizar un seguimiento de los archivos a medida que se mueven entre el servidor y varios dispositivos cliente. El cliente de sincronización puede escribir este identificador en el sistema de propiedades sin afectar al archivo. Este identificador ya está disponible para la aplicación más adelante para obtener acceso rápido y disponible para que cualquier otra aplicación del sistema lea al comunicarse con el proveedor de sincronización.

Hay muchas otras opciones para usar propiedades complementarias, pero ambos hacen buenos ejemplos porque requieren búsqueda rápida o búsqueda, son fragmentos de información que el sistema no sabe y no se puede agregar al propio archivo.

Uso de propiedades complementarias

El uso de las propiedades complementarias es el mismo que escribir una propiedad normal en el sistema de archivos. Si está familiarizado con el uso de StorageFiles y propiedades, puede omitir esto. De lo contrario, veamos un ejemplo rápido de cómo escribir una sola propiedad en un archivo y, a continuación, volver a leer la misma propiedad más adelante.

Redacción de propiedades complementarias

El ejemplo solo modificará el primer archivo que encuentra por motivos de simplicidad, pero generalmente una aplicación agregará la propiedad a cada archivo que encuentre.

// Only indexed jpg files are going to be used 
QueryOptions option = new QueryOptions(CommonFileQuery.DefaultQuery, new string[] { ".jpg" }); 
option.IndexerOption = IndexerOption.OnlyUseIndexer; 
// Typically an app would loop over all the files in the library, updating them all with the new 
// value. To make the sample easier to understand however, this app is only going to update the  
// first file it finds 
var query = KnownFolders.PicturesLibrary.CreateFileQueryWithOptions(option); 
StorageFile file = (await query.GetFilesAsync()).FirstOrDefault(); 
if (file == null) 
{ 
    log("No jpg file found in the library. Stopping"); 
    return; 
} 
log("Found file: " + file.Path); 
// Selecting the property to modify and writing it out 
List<KeyValuePair<string, object>> props = new List<KeyValuePair<string, object>>();             
props.Add(new KeyValuePair<string, object>("System.Supplemental.ResourceId", fileId)); 
await file.Properties.SavePropertiesAsync(props); 

Es importante verificar si la ubicación está indexada antes de escribir una propiedad. En este ejemplo se usan las opciones de consulta para filtrar solo a ubicaciones indizadas. Si esto no es factible, puede comprobar el estado indizado de la carpeta padre (archivo.GetParentAsync().GetIndexedStateAsync()). En cualquier caso, se producirán los mismos resultados

Lectura de propiedades complementarias

De nuevo, la lectura de una propiedad complementaria es la misma que la lectura de cualquier otra propiedad del sistema de archivos. En este ejemplo, la aplicación solo leerá una propiedad de un archivo para el que ya tiene storageFile, pero también podría leer otras propiedades al mismo tiempo.

// An object to hold the result from the indexer, and a string to store  
// the value in once we have confirmed it is valid. 
object uncheckedResourceId; 
string resourceId = ""; 
// Fetching the key value pair from the indexer 
IDictionary<string,object> returnedProps =  
    await file.Properties.RetrievePropertiesAsync(new string[] { "System.Supplemental.ResourceId" });             
if (returnedProps.TryGetValue("System.Supplemental.ResourceId", out uncheckedResourceId)) 
{ 
    if (uncheckedResourceId != null && !String.IsNullOrEmpty(uncheckedResourceId.ToString())) 
    { 
        resourceId = uncheckedResourceId.ToString(); 
    } 
} 

Hay una comprobación para asegurarse de que el valor que regresa del sistema de propiedades es el que usted espera. Aunque es poco probable, es posible que el valor se haya borrado desde que la aplicación lo ha escrito. Esto se tratará en detalle a continuación.

Notas de implementación

Hay algunas opciones sutiles que se realizaron en el diseño de las propiedades complementarias. Para ayudarle con la implementación, se copiaron las secciones siguientes de la especificación de diseño de ingeniería para la característica. Proporcionan una visión de cómo se diseñó la característica y por qué existen algunas de las limitaciones.

Propiedades complementarias disponibles

Solo hay dos propiedades disponibles para las aplicaciones inicialmente: System.Supplemental.ResourceId y System.Supplemental.AlbumID. Si se necesita más, se pueden agregar. El identificador del álbum es una cadena de varios valores que se puede usar para muchas aplicaciones diferentes y resourceId se usa como identificador único para los proveedores de sincronización en la nube.

Compatibilidad con el sistema de archivos

Dado que los medios extraíbles con formato FAT son un escenario importante, las propiedades complementarias admitirán unidades FAT y NTFS. Esto garantizará que las propiedades complementarias estarán disponibles para todos los usuarios, independientemente del tipo de dispositivo.

Ubicaciones no indexadas

En el escritorio hay una serie de carpetas que no están indizada. En estos casos, es posible que las aplicaciones quieran tener acceso a propiedades complementarias. Sin embargo, las propiedades complementarias no están disponibles fuera de las ubicaciones indexadas. Esta compensación se realizó por un par de razones:

• Todas las bibliotecas y ubicaciones de almacenamiento en la nube se indexan de forma predeterminada.
  Estas son las ubicaciones que las aplicaciones para UWP usarán principalmente. Hay otras ubicaciones que no están indexadas (unidades de sistema o de red), pero se usan con menos frecuencia para almacenar datos de usuario.

• El diseño de la superficie de la API de WinRT supone que el indexador está casi siempre disponible.
  Por lo tanto, el indexador ya está disponible en la mayoría de las ubicaciones en las que están interesados las aplicaciones. Si se detecta que los usuarios almacenan datos en ubicaciones no indexadas, la solución más sencilla será agregar esa ubicación al índice. A continuación, las propiedades complementarias funcionan, la enumeración será más rápida y las aplicaciones podrán cambiar el seguimiento de la ubicación.

Leer o escribir propiedades complementarias desde un archivo en una ubicación no indexada

En caso de que una aplicación intente escribir una propiedad complementaria en una ubicación que no está indizada actualmente, la llamada API producirá una excepción. Esta será la misma excepción que se produce cuando alguien intenta actualizar System.Music.AlbumArtist en un archivo .docx (Args no válidos).

Notificaciones de cambio:

Las notificaciones de cambios de UWP y el seguimiento de cambios seguirán funcionando para las propiedades complementarias, como lo hacen para las propiedades estándar. Esto permitirá que las aplicaciones que proporcionan datos realicen un seguimiento de todos los cambios que se producen en una de sus aplicaciones.

Invalidando propiedades:

Las propiedades complementarias de un archivo pueden quedar obsoletas cada vez que se modifica o se mueve un archivo en el sistema. Las aplicaciones que insertan los datos serán las que tienen la información sobre si los datos son válidos o deben actualizarse para que el sistema solo proporcione las herramientas para averiguarlos.

En caso de que se modifique un archivo, pero no se mueva o cambie el nombre, todas las propiedades complementarias del archivo permanecerán sin cambios. Las aplicaciones podrán registrarse para recibir notificaciones de cambio a través de la superficie de API existente y actualizar las propiedades según sea necesario.

Si se mueve el archivo, se invalidarán las propiedades. La aplicación recibirá las notificaciones de cambio de eliminación, creación, cambio de nombre o traslado en función de cómo se realice exactamente la operación. Una vez que la aplicación haya recibido la notificación de cambio, podrá inspeccionar el archivo y actualizar las propiedades complementarias en el archivo según sea necesario.

Reconstrucciones del indexador

En ocasiones, el índice del sistema debe volver a generarse por una de varias razones: el esquema de propiedades podría cambiar, el usuario podría habilitar EDP o simplemente el archivo de base de datos podría estar dañado. En estos casos, no se conservarán las propiedades complementarias. Consideramos realizar el trabajo para intentar conservar las propiedades complementarias cuando se reconstruye el índice, pero había un par de obstáculos principales.

Protección de los datos

En caso de que el archivo de base de datos esté dañado, ya sea por errores de disco o software no autorizado, será imposible proteger los datos almacenados en ese archivo. Tendría que almacenarse en otro lugar del sistema o de alguna manera aislado del resto de la base de datos.

Puesto que ya estamos haciendo mucho trabajo para hacer que el índice sea menos probable que esté dañado, esto reducirá la tasa de incidencia de este caso de todos modos.
Mantenimiento de la asignación entre archivos y sus metadatos durante las recompilaciones

Incluso si el índice puede proteger los datos en una recompilación, es imposible saber si el archivo ha cambiado mientras se estaba recompilando el índice. Es posible que los datos que protege el índice del archivo ya no sean válidos si el archivo se modifica o se mueve.
Comportamiento

En el caso de una recompilación del indexador, se perderán todos los datos complementarios. Las aplicaciones serán responsables de devolver los datos al indexador que se perdió durante la recompilación. Esto supone una carga adicional en las aplicaciones, pero se considera razonable, ya que siempre contendrán el estado maestro para todos sus datos.

Recuperación

Una vez que las aplicaciones hayan notado que el índice se está reconstruyendo, serán responsables de actualizar las propiedades complementarias a su conveniencia.

Privacidad

Algunas de las propiedades que podrían escribirse en los archivos podrían ser tales que los usuarios no deseen que se compartan con otras aplicaciones. Las aplicaciones deben ser capaces de indicar que la información que están escribiendo en las propiedades va a ser privada para sus aplicaciones, compartirse con solo algunas otras aplicaciones o pública para todas las aplicaciones del sistema.

Aunque esto es potencialmente una característica interesante para algunos de los primeros usuarios de la característica, sienten que la obtención de propiedades públicas seguirá agregando mucho valor al diseño. Por lo tanto, esto se marca como deseable, y debemos seguir desarrollando la funcionalidad sin incluir la opción de ocultar los valores si se requiere. Agregarlo más adelante abrirá más escenarios, por lo que será importante tener en cuenta en cualquier diseño.

Conclusiones

Es decir, las propiedades complementarias son una manera fácil de almacenar más propiedades de archivo en el sistema. Su uso es, por supuesto, opcional, pero puede dar a tu aplicación una ventaja sobre otras aplicaciones que no pueden ordenar y buscar sus datos tan rápidamente.

Esperamos ver que las aplicaciones empiecen a usar estas propiedades. Si tiene alguna pregunta sobre cómo usar el encabezado, háganoslo saber en los comentarios siguientes.