L'environnement de Mac OS X (2).

Mes commentaires :

Pour une fois, les commentaires viennent avant le texte d'Apple, car cette partie est très technique, et pas vraiment à la portée d'un utilisateur lambda, et c'est plutôt normal, elle est faite pour des développeurs. Mais n'en négligez pas la lecture, car elle vous apprendra beaucoup de choses qui vous permettront de mieux comprendre Mac OS X.

L'essentiel repose sur la notion de paquetage (bundle), qui est proposé par Apple comme mode privilégié d'installation des applications. Quand vous installez une application, le mode opératoire normal vous invite à glisser un dossier (avec une extension .app) dans le répertoire des applications (vous devez avoir un statut d'administrateur pour le faire). Un paquetage regroupe l'ensemble des ressources dont une application a besoin pour fonctionner, y compris les ressources de localisation qui lui permettent de fonctionner sous des langues différentes.

Un paquetage (bundle) est fondamentalement un dossier. Ce que vous prenez pour un fichier (avec l'extension .app) dans le dossier /Volumes/Macintosh HD/Applications (ou /Volumes/SnowLeopard/Applications si vous avez suivi mes conseils) représente en réalité un dossier. Vous pouvez aller voir facilement son contenu : par exemple, dans le dossier "Applications", faites un Crtl-clic sur Text Edit.app pour accéder au menu contextuel, et choisissez "Afficher le contenu du paquet" ; explorez (sans rien modifier) le contenu qui est ainsi présenté ; parcourez les dossiers pour voir ce qu'ils contiennent. Les fichiers .nib sont les fichiers de l'interface graphique gérés par Interface Builder.

titre

Le contenu de Text Edit.app ; explorez l'ensemble du dossier (mais sans rien modifier).

Avec XCode (et Interface Builder), le système de développement d'Apple, les développeurs disposent d'outils pour créer ces paquetages, ce qui ne veut pas dire que la tâche de développement est simple. On s'en rend un peu compte à lire les recommandations qui suivent, mais c'est encore beaucoup plus compliqué que vous ne l'imaginez. L'important, puisque vous ne serez sans doute jamais des développeurs, n'est pas de rentrer dans le détail, mais d'avoir une vue d'ensemble des contraintes qu'impose Mac OS X ; c'est bien montré dans ce qui suit.

Ce que dit Apple :

5- Le Finder

Voici quelques conseils pour que votre application s'intègre bien avec le Finder :

• Donner au paquetage (bundle) de l'application une extension .app ; le Finder en tient compte pour lancer l'application. Selon les Préférences du Finder<Options Avancées, le nom de l'extension peut être affiché ou masqué.

• Mettre les applications CFM (Code Fragment Manager) dans un paquetage ; vous pouvez toujours tirer avantage du mécanisme des paquetages de Mac OS X.

• Fournissez des informations au Finder à l'aide de listes de propriétés (property lists). C'est le mode standard pour placer et stocker des informations sur votre applications et les types de documents.

• Quand vous sauvez vos documents assurez-vous que vous leur donnez une extension de fichier convenable pour permettre l'inter-opérabilité. Vous pouvez aussi définir les types File et Créateur ; ils ne sont pas indispensables, mais assurent l'inter-opérabilité dans l'environnement classique.

• Evitez de modifier le type Créateur des documents existants. Il indique une forme de propriété du fichier. Votre application peut définir un type créateur pour les fichiers qu'elle crée, mais elle ne doit pas modifier le type Créateur d'autres applications. L'utilisateur peut toujours associer des fichiers avec une application spécifique à l'aide de la fenêtre d'informations.

• Si votre application crée des documents dans des formats autres que HTML, RTF, texte pur, TIFF, PNG, JPEG, PDF et mov, il vous faut proposer un générateur Quick Look pour que le Finder puisse afficher ces documents dans une vue Cover Flow ou dans Quick Look.

6- Formats et extensions de fichiers

Quand c'est possible, utilisez des formats de fichiers standards pour vos documents ; cela rend plus facile l'échange de données entre votre application et d'autres. Les utilisateurs seront plus enclins à adopter votre application s'ils savent qu'ils peuvent récupérer les données, ou en mettre.

Pour la sauvegarde des données de configuration, faites-le dans un fichier texte, pour que l'utilisateur puisse le modifier. Les applications de Mac OS X utilisent XML. Vous pouvez écrire des données XML à l'aide du support fourni pour les préférences système et XML dans Core Foundation et Cocoa.

De nombreuses plateformes se basent sur l'existence d'une extension au nom de fichier pour identifier le type de fichier. Bien que depuis longtemps, les développeurs sous Mac OS X aient découragé leur utilisation, les extensions facilitent les échanges de fichiers entre des utilisateurs de plateformes différentes. Les applications qui sauvegardent des documents doivent inclure une extension de fichier appropriée. En même temps, elles doivent respecter les préférences de l'utilisateur concernant l'affichage des extensions des fichiers et des documents.

7- L'internationalisation

Le système d'empaquetage des applications de Mac OS X accepte des textes localisés, des images, des fichiers nib et d'autres ressources. Mais adapter une application à des marchés différents va au delà d'une simple traduction de chaînes de caractères. La compatibilité internationale propose quelques considérations d'ensemble pour assurer l'internationalisation ; au minimum, vous devez inclure les éléments suivants :

• Organisez votre programme en paquetage pour tirer parti du support d'internationalisation de Mac OS X.

• Utilisez du texte Unicode. Mac Os X supporte Unicode complètement, et votre application doit le faire aussi.

• Modifiez votre code pour obtenir des chaînes de caractères visibles par l'utilisateur à partir des fichiers .string. Utilisez les interfaces de Core Foundation et Cocoa pour récupérer les les chaînes de caractères à partir des fichiers de ressources de votre paquetage.

• Utilisez des fichiers .nib pour stocker les données de l'interface utilisateur

8- Problèmes associés à des utilisateurs multiples

Mac OS X est une système multi-utilisateurs : non seulement il accepte de multiples comptes utilisateurs, mais aussi, il permet à des utilisateurs multiples de se partager simultanément les ressources du même ordinateur. Avec cette technique de changement rapide d'utilisateur, l'utilisateur abandonne l'usage de l'ordinateur sans sortir de sa session. Dans ces conditions, des conflits peuvent intervenir si les applications ne gèrent pas convenablement les ressources qu'elle partagent : la mémoire partagée, les fichiers de cache, les sémaphores et les tuyaux nommés (named pipes) doivent être soigneusement étiquetés pour empêcher leur corruption par d'autres utilisateurs utilisant la même application. Les applications ne doivent pas considérer qu'elles ont un accès exclusif aux ressources du système, comme un CD ou un DVD.

Il faut donc garder à l'esprit quelques éléments spécifiques lors de la conception du programme :

• Les ressources nommées d'une application, qui peuvent être accessibles à partir de multiples sessions d'utilisateurs doivent inclure un identificateur (ID) de session dans le nom de celle-ci. Cela s'applique aux fichiers de cache, à la mémoire partagée, aux sémaphores, aux tuyaux nommés, entre autres.

• Les utilisateurs n'ont pas tous les mêmes privilèges ; seuls les administrateurs peuvent écrire des fichiers dans le dossier /Applications. Certains utilisateurs peut avoir des privilèges limités, ou un accès limité à certaines parties du système ; ils peuvent en particulier être incapables d'exécuter les actions suivantes :
- accéder à toutes les vitres des Préférences Système
- modifier le Dock
- changer leur mot de passe
- brûler des DVDs ou des CDs
- ouvrir certaines applications.

• Sur une ordinateur, les utilisateurs peuvent être locaux, ou venir du réseau, donc ne supposez pas que le répertoire maison (Home) est sur le volume local. Vous pouvez avoir affaire au réseau.

9- La gestion des ressources

Les applications en paquetage facilitent l'installation, et sont plus faciles à éliminer pour l'utilisateur. C'est le mécanisme de distribution à privilégier. Voici quelques conseils :

• Mettez toutes les ressources nécessaires dans le paquetage de l'application ; il doit contenir tout ce qui est nécessaire pour faire tourner l'application.

• Ne mettez que les sous-ensembles de fichiers nécessaires à la localisation dans les répertoires de ressources spécifiques au langage. Si des ressources n'ont pas besoin de localisation, inutile de les multiplier : le chargement des paquetages recherche les ressources globales aussi bien que les ressources localisées, et renvoie celle qui est la plus appropriée.

• Utilisez un installeur pour mettre des ressources optionnelles dans le sous-répertoire approprié de la Bibliothèque. Les ressources optionnelles correspondent à des modèles de documents, ou à d'autres ressources utiles pour l'application, mais pas nécessaires au lancement de celle-ci. La plupart de ces fichiers doivent être mis dans un sous-répertoire spécifique à l'application dans ~/Library/Application Support ou dans /Library/Application Support.

• Evitez de stocker des données dans la fourche ressources de l'exécutable de l'application ; elle n'est pas faite pour cela. Sauvegardez vos ressources dans des fichiers individuels dans le paquetage de l'application.

10- Les threads

Pendant la conception de l'application, identifiez les opérations qui peuvent être faites en parallèle. Le multi-thread pour une application améliore la flexibilité de l'interface utilisateur en déplaçant les calculs longs en dehors de la boucle d'évènements principale. Le multi-thread peut améliorer la rapidité de certaines tâches , notamment sur les systèmes multi-processeurs. L'utilisation des threads réclame beaucoup de précautions pendant la conception, pour s'assurer que les structures des données partagées ne sont pas corrompues par d'autres threads.