Avec les ressources, il existe un support intégré pour fournir des alternatives pour différentes langues, versions de système d'exploitation, orientations d'écran, etc., comme décrit ici . Rien de tout cela n'est disponible avec les actifs. De plus, de nombreuses parties de l'API prennent en charge l'utilisation d'identificateurs de ressources. Enfin, les noms des ressources sont transformés en noms de champs constants qui sont vérifiés au moment de la compilation, il y a donc moins de possibilité de disparités entre le code et les ressources elles-mêmes. Rien de tout cela ne s'applique aux actifs.
Alors pourquoi avoir un dossier d'actifs? Si vous souhaitez calculer l'élément que vous souhaitez utiliser au moment de l'exécution, c'est assez simple. Avec les ressources, vous devez déclarer une liste de tous les ID de ressource pouvant être utilisés et calculer un index dans la liste. (C'est un peu gênant et présente des possibilités d'erreur si l'ensemble des ressources change au cours du cycle de développement.) (EDIT: vous pouvez récupérer un ID de ressource par son nom en utilisant getIdentifier
, mais cela perd les avantages de la vérification à la compilation.) Les actifs peuvent être également organisé en une hiérarchie de dossiers, qui n'est pas prise en charge par les ressources. C'est une façon différente de gérer les données. Bien que les ressources couvrent la plupart des cas, les actifs ont leur utilisation occasionnelle.
Autre différence: les ressources définies dans un projet de bibliothèque sont automatiquement importées dans des projets d'application qui dépendent de la bibliothèque. Pour les actifs, cela ne se produit pas; les fichiers de ressources doivent être présents dans le répertoire des actifs du ou des projets d'application. [EDIT: Avec le nouveau système de construction basé sur Gradle d'Android (utilisé avec Android Studio), ce n'est plus vrai. Les répertoires d'actifs pour les projets de bibliothèque sont regroupés dans les fichiers .aar, de sorte que les actifs définis dans les projets de bibliothèque sont fusionnés dans les projets d'application (de sorte qu'ils n'ont pas besoin d'être présents dans le /assets
répertoire de l'application s'ils se trouvent dans une bibliothèque référencée).]
EDIT: Une autre différence survient si vous souhaitez empaqueter une police personnalisée avec votre application. Il existe des appels d'API pour créer un à Typeface
partir d'un fichier de police stocké dans le système de fichiers ou dans le assets/
répertoire de votre application . Mais il n'y a pas d'API pour créer un à Typeface
partir d'un fichier de police stocké dans le res/
répertoire (ou à partir d'un InputStream
, ce qui permettrait d'utiliser le res/
répertoire). [ REMARQUE: avec Android O (désormais disponible en aperçu alpha), vous pourrez inclure des polices personnalisées en tant que ressources. Voir la description ici de cette fonctionnalité attendue depuis longtemps. Cependant, tant que votre niveau d'API minimum est de 25 ou moins, vous devrez vous limiter à empaqueter les polices personnalisées en tant qu'actifs plutôt qu'en tant que ressources.]
res
représente les ressources, alors qu'est-ce queassets
signifie ??