iphone - descargar - ¿Cómo debería abordar la construcción de una aplicación universal de iOS que incluya las características de iOS 4, a pesar de que el iPad todavía no ejecuta iOS 4?
ios 12 (4)
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.
- En este caso, ¿es una mala idea crear este proyecto como una aplicación universal?
- Si no, ¿cuáles son algunos de los pensamientos que debería tener en cuenta al construir una aplicación universal que admita dos versiones diferentes del iOS?
- ¿Es algo seguro apostar a que Apple lanzará el iOS 4 para el iPad en el otoño como se especula?
- Si es así, ¿de todos modos puedo comenzar a construir estas características de iOS 4 (GameCenter e iAd) en mi versión iPad de mi juego?
¡Muchas gracias de antemano por toda su sabiduría!
EDITAR: 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.
Si está por construir una aplicación universal, recuerde los siguientes dos fragmentos de código fuente:
Usar clases solo si están disponibles en el dispositivo actual
Considera este pedazo de código:
UILocalNotification* n = [[UILocalNotification alloc] init];
Al crear una aplicación universal, este código generará un error de tiempo de ejecución en cualquier dispositivo que ejecute una versión de iOS que no conozca la clase UILocalNotification.
Aún puede admitir UILocalNotification en su código mientras mantiene la compatibilidad con versiones anteriores mediante el siguiente fragmento de código:
Class notificationClass = NSClassFromString(@"UILocalNotification"); if (notificationClass) { UILocalNotification* n = [[notificationClass alloc] init]; }
Esta técnica le permite utilizar clases que no están disponibles en ciertas versiones de SO en dispositivos que sí admiten las clases.
Usar métodos solo si están disponibles en el dispositivo actual
Supongamos que le gustaría hacer lo siguiente:
[[UIApplication sharedApplication] scheduleLocalNotification:n];
Use la siguiente pieza de código para llamar condicionalmente al método en caso de que esté disponible en el dispositivo actual:
if ([UIApplication instancesRespondToSelector:@selector(scheduleLocalNotification:)]) { [[UIApplication sharedApplication] scheduleLocalNotification:n]; }
Estas 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.
Una vez dicho esto, 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 verificar si está ejecutando en un iPad, puede evitar que su Aplicación Universal ejecute código que aún no tenga UI 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.
Esta es una pregunta que trata sobre la gestión del riesgo. Los riesgos incluyen:
- Apple no lanza el sistema operativo "unificado 4.1" esperado dentro del marco de tiempo que necesita
- El SO se entrega a tiempo para sus necesidades, pero uno o ambos de GameCenter o iAds no están incluidos
- GameCenter y / o iAds están incluidos, pero no coinciden con la API exacta que esperabas
- Las API son lo que esperabas, pero tienen problemas ya que es la primera versión en el iPad
- etc ...
Solo usted puede determinar con qué nivel de riesgo se siente cómodo, con qué probabilidad cree que está cada riesgo, si puede mitigar cada riesgo y cuáles serían los costos de cualquiera de estos problemas en el camino.
Una buena publicación sobre este tema: http://cocoawithlove.com/2010/07/tips-tricks-for-conditional-ios3-ios32.html
Usted principalmente necesita hacer dos cosas:
- Enlace débil a cualquier marco que no esté presente en el 3.2 SDK.
- Escriba pruebas de tiempo de ejecución para cualquier API que sea nueva en iOS 4.
Para hacer lo primero, haga clic derecho en su objetivo y seleccione "Obtener información". Los marcos se enumeran en el inspector (en la pestaña "General") con un cuadro desplegable al lado de ellos que le permitirá seleccionar " Débil "vinculación". Esto asegura que la aplicación se ejecutará si el marco no está presente.
Para hacer lo segundo, podría hacer algo como lo siguiente para probar la nueva animación basada en bloques en iOS 4:
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:
puede evitar llamar algo que el sistema operativo actual no admite.
Tenga en cuenta también que si desea soportar iPhone OS 3.0, se aplicarán estas mismas reglas.
Finalmente, también es posible, aunque no recomendable, hacer esto de la siguiente 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é esto no es aconsejable? Simple: solo se compilará el código para la versión de iOS con el número más alto. Las aplicaciones de iPhone no se compilan por separado para versiones de iOS separadas, por lo que para que esto realmente funcione , tendría que lanzar varias versiones de la aplicación.