2010-07-23 13 views
11

Me gustaría construir un juego para iPhone y iPad. Como tal, tendría sentido comenzar este proyecto desde cero como una aplicación universal. Sin embargo, iPhone y iPad actualmente ejecutan dos versiones diferentes de iOS, ya que iOS 4 aún no está disponible para el iPad. Hay dos características de iOS 4 (GameCenter e iAd) que me gustaría apoyar en mi juego.¿Cómo debo abordar la construcción de una aplicación universal de iOS que incluya las características de iOS 4, aunque el iPad aún no ejecute iOS 4?

  1. En este caso, ¿es una mala idea crear este proyecto como una aplicación universal?
  2. Si no, ¿cuáles son algunos de los pensamientos que debería tener en cuenta cuando estoy construyendo una aplicación universal que admite dos versiones diferentes de iOS?
  3. ¿Es seguro apostar a que Apple lanzará el iOS 4 para el iPad en el otoño como se especula?
  4. Si es así, ¿de todos modos puedo comenzar a desarrollar estas características de iOS 4 (GameCenter y iAd) en mi versión de iPad de mi juego?

¡Muchas gracias de antemano por toda su sabiduría!

EDIT: Entiendo que este problema implica la gestión de riesgos. Soy consciente de los riesgos, pero me interesan más las consideraciones de diseño tecnológico relacionadas con la construcción de una aplicación universal cuando el iOS está fragmentado entre los diversos dispositivos iOS.

+0

Tenga en cuenta que Game Center no estará disponible por un tiempo, y Apple no aceptará su solicitud de revisión en este momento si usa esa funcionalidad. –

Respuesta

16

Si estás a punto de construir una aplicación universal, sólo recuerda los siguientes dos fragmentos de código fuente:

  • Utilización de las clases sólo si están disponibles en el dispositivo actual

    consideran este pedazo de código:

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

    Cuando se construye una aplicación universal, este código dará lugar a un error de ejecución en cualquier dispositivo que ejecuta una versión de iOS que no sabe acerca de la UILocalN clase de ottica

    Todavía se puede apoyar UILocalNotification en el código de tiempo que se mantiene la compatibilidad hacia atrás utilizando el siguiente fragmento de código:

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

    Esta técnica permite el uso de clases que no están disponibles en ciertas versiones del sistema operativo en los dispositivos que no admiten la clases

  • Utilizando métodos sólo si están disponibles en el dispositivo actual

    Supongamos que desea hacer lo siguiente:

    [[UIApplication sharedApplication] scheduleLocalNotification:n]; 
    

    Utilice el siguiente fragmento de código para llamar condicionalmente el método en el caso que está disponible en el dispositivo actual:

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

Estos dos técnicas son probablemente las únicas cosas que necesita saber para crear su aplicación universal. Ejecute condicionalmente su código según las capacidades del dispositivo y debería estar bien.

Habiendo dicho eso, aún debe considerar que el iPad probablemente utilizará una interfaz de usuario diferente a la de su contraparte de iPhone. Y, desafortunadamente, no podrá probar la interfaz de usuario de su iPad con las características de iOS 4 hasta que estén disponibles en el iPad. Pero esto no debería ser un gran problema: si usa [[UIDevice currentDevice] userInterfaceIdiom] para comprobar si está ejecutando un iPad, puede evitar que su aplicación universal ejecute código que todavía no tenga una IU de iPad.Una vez que Apple lanza iOS 4 para iPads, puede implementar la interfaz de usuario, eliminar esa verificación y lanzar una actualización a la tienda.

+0

gracias, benjamin, extremadamente útil! – BeachRunnerFred

+0

Nota rápida para futuros lectores: DEBE vincular débilmente UIKit si está implementando la aplicación: didReceiveLocalNotification: método UIApplicationDelegate, ya que toma UILocalNotification como parámetro. – leolobato

1

Esta es una pregunta que trata sobre la gestión del riesgo. Los riesgos incluyen:

  1. de Apple no da a conocer el sistema operativo espera "unificado 4.1" dentro del marco de tiempo que necesita
  2. El sistema operativo es liberado a tiempo a sus necesidades , pero uno o ambos de GameCenter o iAds no están incluidos
  3. GameCenter y/o se incluyen iAds, pero no coinciden con la API exacta que esperabas
  4. las API son los que esperaba, pero son pecado con errores CE, ha sido la primera versión en el IPAD
  5. etc ...

Sólo usted puede determinar qué nivel de cada riesgo que se sienta cómodo, la probabilidad de que usted piensa cada riesgo es, si se puede mitigar cada riesgo, y cuáles serían los costos para cualquiera de estos problemas en el camino.

+0

gracias, Shaggy, en realidad estoy más interesado en cualquier consideración de diseño de tecnología que deba tener en cuenta al construir una aplicación universal, ya que el iOS está fragmentado entre los diversos dispositivos. ¿tus pensamientos? – BeachRunnerFred

+1

Usted mencionó "¿Es algo seguro apostar a que Apple libere el iOS 4 para el iPad en el otoño como se especula?" y la respuesta a eso es "no", debido al riesgo involucrado. No es tan fácil querer hablar sobre administración de riesgos y consideraciones de diseño tecnológico como dos cosas separadas en este caso. Estás tratando de crear una aplicación de tal manera que no puedas probarla, sin importar que todo tu trabajo no se desperdicie. –

+0

muy buena idea! gracias, Shaggy! – BeachRunnerFred

11

Es sobre todo hay que hacer dos cosas:

  1. de eslabón débil o no un marco que no están presentes en el 3.2 SDK.
  2. pruebas de escritura en tiempo de ejecución para cualquier API que son nuevas para iOS 4.

Para hacer la primera, haga clic en su objetivo y seleccione “Obtener información”. Los marcos se enumeran en el inspector (bajo la Pestaña "General") con un cuadro desplegable al lado de ellos que te permitirá seleccionar enlaces "Débiles". Esto asegura que la aplicación se ejecutará si el marco no está presente.

Para la segunda, se podría hacer algo como lo siguiente para probar la nueva animación basada en bloques en IOS 4: algo

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

Mediante el uso de métodos introspectivos como -respondsToSelector:, se puede evitar llamar a que el sistema operativo actual no es compatible.

Tenga en cuenta también que, si desea admitir iPhone OS 3.0, se aplicarán las mismas reglas.

Por último, no es posible también, aunque aconseja a hacerlo de esta manera:

#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 

¿Por qué es esto no es recomendable? Simple: solo se compilará el código para la versión más alta de-iOS. Las aplicaciones de iPhone no se compilan por separado para versiones de iOS separadas, por lo que para que esto funcione de hecho , deberá liberar varias versiones de la aplicación.

+0

gracias, Jeff, ¡enormemente útil! – BeachRunnerFred

+0

Esto fue muy perspicaz, ¡gracias! – bentford

+0

Cuando Build se compiló desde iOS 5.0, la línea de código después de #elif defined (__ IPHONE_3_2) nunca se ejecutará en ningún dispositivo con ningún iOS. ¿Esto es verdad? – CReaTuS

Cuestiones relacionadas