Une base de code pour Snow Leopard et Leopard

Question

Arrière-plan

Je suis un développeur qui est en train de créer une application pour Mac. Je suis sur le point de mettre la main sur Snow Leopard. Jusqu'à présent, je construisais sur Leopard. Cela fait environ un an que je développe le cacao, mais pas très intensément.

J'ai beaucoup lu sur Snow Leopard et Grand Central Dispatch en particulier. Je suis conscient du fait qu’il utilise des blocs, mais je n’ai pas approfondi le fonctionnement de ces blocs ni celui de Grand Central Dispatch.

Ma question

Comment puis-je développer au mieux une base de code pour Snow Leopard et Leopard, tout en tirant le meilleur parti possible du nouveau matériel multithread de Snow Leopard?

NSOperationQueue

Mon instinct n'est pas de traiter GCD directement dans mon code, mais lorsque vous avez besoin de mettre une file d'attente, utilisez NSOperationQueue, car j'ai lu dans les sessions de questions-réponses de Mike Ashes que, dans Snow Leopard, NSOperationQueue tire pleinement parti des avantages de GCD et le meurtre qu'il a découvert à Léopard ont maintenant été corrigés.

Gestion manuelle des threads

Toutefois, s’agissant de la gestion de threads d’arrière-plan spécifiques, existe-t-il un moyen de tirer parti de la gestion des threads plus facile à utiliser dans Snow Leopard sans casser des choses dans Leopard? Ou les gens recommandent-ils d'avoir des cibles différentes pour chaque système d'exploitation avec des classes différentes dans chacun? Cela me semble être un cauchemar de maintenance qui ne demande qu'à se produire.

Ou peut-être devrais-je simplement vivre avec le fait que mon application ne soit pas entièrement optimisée pour Snow Leopard et que je colle avec + (void) detachNewThreadSelector: toTarget: withObject: ou quelque chose de similaire.

Qu'en pensent les gens?

Answer 1

Votre impression intestinale sur GCD est correcte. En fait, toute API qui utilise des blocs est désactivée, sauf si vous conditionnez ce code à ne s'exécuter que sur Snow Leopard. Cela a du sens si le code prend en charge des fonctionnalités uniquement disponibles sur Snow Leopard, mais si vous souhaitez également prendre en charge cette fonctionnalité sur Leopard, vous pouvez également utiliser le chemin du code Leopard dans tous les cas, en ajoutant un code spécifique à Snow Leopard. Le chemin qui n'apporte aucune amélioration visible à l'utilisateur ne fera que compliquer votre code et augmenter vos coûts de test.

Cela s’applique en particulier à des tâches telles que la gestion des threads ou GCD. Les modifications nécessitent une architecture importante, il ne s'agit pas simplement:

if (snowLeopard) {
  [NSSnazySnowLeopardClass doSomething];
} else {
  [NSBoringLeopardClass doSomethingEquivalent];
}

En général, si les modifications proposées ne sont que simples, Apple les gère à l'intérieur de la classe sans modifier l'API. En d'autres termes, la question n'est pas de savoir si vous pouvez utiliser le code de gestion de threads plus facile dans Snow Leopard, c'est pourquoi vous devriez quand même avoir besoin de faire la version dure pour Leopard. Un chemin de code supplémentaire est un chemin de code supplémentaire. Le fait de ne pas prendre en charge le support de Leopard en utilisant des API sensiblement différentes sur Snow Leopard (même s’ils sont plus simples à utiliser que celui de Leopard) ne représente que du travail supplémentaire.

Je me demanderais si vous voulez vraiment cibler Leopard. L'adoption de Snow Leopard a été assez équitable, Snow Leopard est une mise à niveau peu coûteuse et, en raison des modifications apportées à l'API, les utilisateurs de petits développeurs utilisant des applications uniquement Snow Leopard seront soumis à une forte pression. Le seul groupe d'utilisateurs qui resteront longtemps sur Leopard sont ceux qui ne sont pas techniquement au courant (qui ont peu de chance d'installer un logiciel tiers) et ceux qui utilisent encore des Mac PPC (qui n'ont pas acheté de nouveau Mac dans 3 ans, donc n’achetez probablement pas beaucoup de logiciels). Si c’est une application qui, selon vous, devrait être commercialisée dans 3 à 9 mois, j’arguerais que l’utilisation de Snow Leopard uniquement est probablement une option raisonnable et permettra de réduire considérablement votre charge de développement et de test.

Answer 2

Une solution serait de comprendre quelles API de Leopard ont été modifiées dans Snow Leopard pour utiliser GCD. Par exemple, NSOperation et NSOperationQueue dans Leopard fonctionnent comme ils l’ont toujours fait. Cependant, dans Snow Leopard, ils ont été réécrits pour tirer parti de GCD. Voila. Mise à niveau instantanée pour vos utilisateurs 10.6.

Une autre option consisterait à utiliser quelque chose comme PLBlocks et à compiler vous-même GCD dans votre code. . Je ne sais pas si cela fonctionnera, mais cela pourrait valoir le coup. =)