Comment devrais-je m'approche de la construction d'un Universel de l'application pour iOS qui comprennent iOS 4 caractéristiques, même si l'iPad n'est pas encore exécuté iOS 4?

J'aimerais créer un jeu pour l'iPhone et l'iPad. En tant que tel, il serait judicieux de commencer ce projet à partir de zéro comme une application universelle. Cependant, l'iPhone et l'iPad actuellement deux versions de l'iOS depuis iOS 4 n'est pas disponible pour l'iPad encore. Il y a deux iOS 4 fonctions (GameCenter et de la sai) que je tiens à soutenir dans mon jeu.

  1. Dans ce cas, est-ce une mauvaise idée de créer ce projet comme une application universelle?
  2. Si non, quels sont les quelques réflexions que je dois prendre en compte que je suis en train de construire une application universelle qui prend en charge différentes versions de l'iOS?
  3. Est-il un peu fort à parier sur l'Apple libérant de l'iOS 4 pour l'iPad à l'automne comme spéculé?
  4. Si oui, est-il de toute façon je peux commencer la construction de ces iOS 4 fonctions (GameCenter et de la sai) dans mon iPad version de mon jeu?

Merci beaucoup d'avance pour toute votre sagesse!

EDIT: je comprends cette question implique la gestion des risques. Je suis conscient des risques, mais je suis plus intéressé par les techniciens des considérations de conception relatives à la construction d'une application universelle, lors de l'iOS est fragmentée entre les différents appareils iOS.

Notez que Game Center ne sera pas disponible pour un peu de temps, et Apple ne sera pas accepter votre demande de révision pour l'instant, si il utilise cette fonctionnalité.

OriginalL'auteur BeachRunnerFred | 2010-07-23

  1. 16

    Si vous êtes sur le point de construire une App Universelle, rappelez-vous les deux source de fragments de code:

    • À l'aide de classes uniquement si elles sont disponibles sur l'appareil

      Considérer ce morceau de code:

      UILocalNotification* n = [[UILocalNotification alloc] init];

      Lors de la construction d'une Application Universelle, ce code provoque une erreur d'exécution sur tout appareil équipé d'une version d'iOS qui ne savent pas à propos de la UILocalNotification classe.

      Vous pouvez toujours soutenir UILocalNotification dans votre code, tout en conservant la compatibilité descendante en utilisant l'extrait de code suivant:

      Class notificationClass = NSClassFromString(@"UILocalNotification");
if (notificationClass) {
  UILocalNotification* n = [[notificationClass alloc] init];
}

      Cette technique permet d'utiliser des classes qui ne sont pas disponibles dans certaines versions de système d'exploitation sur les périphériques prenant en charge les classes.

    • À l'aide de méthodes uniquement si elles sont disponibles sur l'appareil

      Supposons que vous souhaitez effectuer les opérations suivantes:

      [[UIApplication sharedApplication] scheduleLocalNotification:n];

      Utiliser le morceau de code suivant conditionnelle, l'appel à la méthode dans le cas où il est disponible sur le périphérique actuel:

      if ([UIApplication instancesRespondToSelector:@selector(scheduleLocalNotification:)]) {
  [[UIApplication sharedApplication] scheduleLocalNotification:n];
}

    Ces deux techniques sont probablement les seules choses que vous devez savoir pour créer votre Application Universelle. Exécuter conditionnellement votre code selon les capacités du périphérique et vous devriez être bien.

    Après avoir dit que, vous avez encore besoin de considérer que l'iPad sera probablement en utilisant un autre de l'INTERFACE utilisateur de votre iPhone homologue. Et, malheureusement, vous ne serez pas en mesure de tester votre iPad de l'INTERFACE utilisateur avec l'iOS 4 fonctions jusqu'à ce qu'ils deviennent disponibles sur l'iPad. Mais cela ne devrait pas être trop un problème: si vous utilisez [[UIDevice currentDevice] userInterfaceIdiom] pour vérifier si vous êtes en cours d'exécution sur un iPad, vous pouvez empêcher votre App Universelle de l'exécution de code qui n'a pas d'iPad de l'INTERFACE utilisateur encore. Une fois que Apple publie iOS 4 pour ipad, vous pouvez implémenter l'INTERFACE utilisateur, supprimez-le vérifier, et de publier une mise à jour du store.

    merci, benjamin, très utile!
    Note rapide pour les futurs lecteurs: vous DEVEZ maillon faible UIKit si vous êtes à la mise en œuvre de l'application:didReceiveLocalNotification: UIApplicationDelegate méthode, car il faut UILocalNotification en tant que paramètre.

    OriginalL'auteur Benjamin

  2. 11

    Vous avez surtout besoin de faire deux choses:

    1. Maillons faibles des cadres qui ne sont pas présent dans le SDK 3.2.
    2. Écriture d'exécution des tests pour les Api qui sont nouveaux pour iOS 4.

    De faire le premier, clic-droit sur votre cible et sélectionnez “Obtenir des informations.” Les cadres sont répertoriés dans l'inspecteur (sous l'onglet “Général”) avec une zone de liste déroulante à côté d'eux qui vous permet de sélectionner les “Faibles” de la liaison. Cela garantit que l'application continue à fonctionner si le cadre n'est pas présent.

    Pour la deuxième, vous pourriez faire quelque chose comme ce qui suit pour tester le nouveau bloc-animation dans iOS 4:

    if ([UIView respondsToSelector:@selector(animateWithDuration:animations:)]) {
    //Your awesome animation code here
} else {
    //Your almost-as-awesome, non-block-based animation code here.
}

    En utilisant l'introspection des méthodes telles que -respondsToSelector:, vous pouvez éviter d'appeler quelque chose que le cours d'exécution OS ne prend pas en charge.

    Notez également que si vous voulez soutenir l'iPhone OS 3.0, ces mêmes règles s'appliquent.

    Enfin, il est également possible mais pas conseillé—pour ce faire comme suit:

    #ifdef __IPHONE_4_0
    //Your iOS 4.0-compatible code here
#elif defined(__IPHONE_3_2)
    //Your iPhone OS 3.2-compatible code here
#elif defined(__IPHONE_3_0)
    //Your iPhone OS 3.0-compatible code here
#endif

    Pourquoi ce n'est pas conseillé? Simple: seul le code de la plusnumérotés à la version iOS sera compilé. les applications de l'iPhone ne sont pas compilés séparément pour séparer les versions d'iOS, de sorte à obtenir ce fait travail, vous devez sortir de multiples versions de l'application.

    merci, Jeff, très utile!
    Cela a été très perspicace, merci!
    Lors de Construire a été compilé à partir d'iOS 5.0, puis la ligne de code après #elif defined(__IPHONE_3_2) ne sera jamais fonctionner à tous les appareils avec n'importe quel iOS. C'est vrai?
    Pas de. les versions d'iOS sont définies pour toutes les versions futures, ainsi, de sorte __IPHONE_3_2 sera définie lors de la compilation pour iOS 5. __IPHONE_OS_VERSION_MIN_REQUIRED peuvent répondre à vos besoins.

    OriginalL'auteur Jeff Kelley

  3. 2

    Un bon post sur ce sujet: http://cocoawithlove.com/2010/07/tips-tricks-for-conditional-ios3-ios32.html

    merci, iwasrobbed, excellent article en effet!

    OriginalL'auteur iwasrobbed

  4. 1

    C'est une question qui est tout au sujet de la gestion des risques. Les risques comprennent:

    1. Apple n'a pas communiqué de l'attendre
      "unifiée 4.1" OS à l'intérieur de la
      calendrier vous avez besoin
    2. L'OS est sorti à temps pour votre
      besoins, mais l'un des deux ou les deux GameCenter
      ou iAds ne sont pas inclus
    3. GameCenter et/ou iAds sont inclus,
      mais elles ne correspondent pas exactement API
      vous vous attendiez à
    4. Les Api sont ce que vous attendiez, mais
      ils sont buggés puisque c'est le premier
      version sur iPad
    5. etc...

    Vous seul pouvez déterminer quel niveau de chaque risque que vous êtes à l'aise avec, quelle est la probabilité que vous pensez de chaque risque, si vous pouvez atténuer chaque risque, et que les coûts seraient pour l'un de ces problèmes le long du chemin.

    merci, hirsute, en fait je suis plus intéressé par les techniciens des considérations de conception j'ai besoin de réfléchir lors de la construction d'une application universelle, depuis l'iOS est fragmentée entre les différents appareils. vos pensées?
    Vous avez parlé de "Est-il un peu fort à parier sur l'Apple libérant de l'iOS 4 pour l'iPad à l'automne comme spéculé?" et la réponse est "non", en raison du risque impliqué. Il n'est pas si facile de vouloir parler de gestion du risque et de la technologie de conception des considérations comme deux choses distinctes dans ce cas. Vous essayez de construire une application de telle manière que vous ne pouvez pas tester, jamais l'esprit, assurez-vous tout votre travail ne sera pas aller à déchets.
    très bonne idée! merci, shaggy!

    OriginalL'auteur Shaggy Frog