Un vistazo a iOS 5 desde nuestro punto de vista, por Angel Traversi

iOS 5 está en la calle. Hace 3 meses que estamos esperando esta salida, aunque seguramente venimos experimentando algunas de sus funciones desde hace tiempo con los betas.

Es momento de planificar la transición a todas estas nuevas APIs. En realidad a esta altura ya lo tendríamos que tener medianamente definido, pero convengamos que, como desarrollador iOS y por los términos que Apple impone respecto a la confidencialidad, recién ahora puedo hablar libremente del tema y por eso hoy lo incluyo en este artículo.

Nos encantaría comenzar a utilizar todas las APIs nuevas, pero no es fácil decidir esto. Los usuarios finales pueden tardar un tiempo en pasarse a iOS 5 y esto es un problema. Durante varias semanas (¿meses?) nuestros potenciales clientes van a seguir usando iOS 4 y no nos conviene dejarlos fuera porque son posibles ventas que estaríamos perdiendo. 

Dentro de un tiempo, cuando las estadísticas muestren que la gran mayoría se pasó a iOS 5, podremos tranquilos subir el requerimiento mínimo del SO. Pero por el momento, tendremos que convivir con iOS 4 y 5 al mismo tiempo.

¿Como determinar el SO?

¿Cuál es la manera de usar un feature nuevo de iOS 5 sin afectar a los usuarios que siguen con iOS 4?. La respuesta no es otra que “ensuciar” un poco nuestro código usando condicionales y referencias weak (opcionales) a los nuevos frameworks.

Una forma es chequear la versión del sistema operativo:

float version = [[[UIDevice currentDevice] systemVersion] floatValue];

y operar según el valor de version.

Otra forma es consultar si está disponible el framework o API en cuestión. Esta es la solución más prolija y segura, porque en vez de atarnos a una versión, solo discriminamos por el API que queremos usar. Por ejemplo, para saber si está el framework de Twitter disponible:

if ([TWTweetComposeViewController class])

NSLog(@”TWitter está disponible”);

else

NSLog(@”TWitter NO está disponible”);

Dicho esto, veamos las novedades de iOS tratando de categorizarlas, de manera de poder priorizar su uso o migración. Tenemos:

  • APIs con funcionalidad totalmente nueva: como iCloud Storage o NewsStands
  • Frameworks nuevos sobre funciones “viejas”: como Twitter, GLkit, etc.
  • Interfaces que mejoran: AirPlay/mirroring, Core Image, Event Kit, etc.
  • Interfaces que pasan a deprecated y que son reemplazados por nuevas, como el caso de algunas de MapKit/Core Location, etc.
  • Cambios en el paradigma del desarrollo, como Storyboards. Cambios en la forma de codificar las propiedades y objetos, como Auto Reference Counting
  • Mejora en las herramientas de desarrollo (XCode, Instruments y OpenGL debugging).
  • Lo nuevo, nuevísimo

    iCloud Storage es la gran novedad. Si tenemos aplicaciones orientadas a documentos, del estilo Pages, a la corta o a la larga deberíamos utilizar la nube para albergar los archivos. No hay duda de ello y cuanto antes lo hagamos, mejor. Cuando el usuario se acostumbre a esto, no va a querer otra cosa.

    También son candidatas a iCloud Storage las apps que se usan en más de un dispositivo, para mantener su status centralizado. Por ejemplo los lectores de feeds, que fuera de casa lo usamos en el iPhone y en la comodidad del sillón, en el iPad. Si bien la mayoría se integra con Google Reader, éste no alcanza para tener una experiencia de uso completa. Yo no quiero configurar Pulse o Zite en cada dispositivo, lo quiero hacer una sola vez!. Y si agrego un feed en un dispositivo, quiero que los otros se actualicen.

    El caso de los juegos quedan excluidos porque Game Center seguirá siendo La Nube para ellos.

    Lo nuevo, pero viejo

    Aquí la cosa es más diversa. Los frameworks nuevos sobre funcionalidad ya existente o hecha de otra manera, que nos obliga a replantear el código para ajustarlo a la nueva modalidad. Si ya tienes una app conectada a Twitter, será mejor que la actualices con el nuevo framework porque apuesto a que no lo tienes tan lindo como lo hizo Apple. Por suerte te va a quedar el código mucho más compacto y no tendrás que lidiar con JSON y esas cosas.

    En cambio, hay otros temas que pueden esperar:

  • Si tienes código OpenGL, deberás estudiar si conviene o no migrar a GLKit. Si tienes que comenzar algo nuevo en este sentido, seguro GLKit es la salvación.
  • El nuevo soporte para JSON, desde ya es bienvenido!. Planeemos cómo migramos desde el kit opensource que seguro estas usando…
  • Interfaces mejoradas

    Estas pueden ser de lo más jugosas, porque quizás, con poco esfuerzo, podemos darle valor agregado a nuestras app. Aquí tendrás que chequear las novedades y ver qué onda. A los usuarios les encanta que las app vayan mejorando y ganando funcionalidad sin tener que pagar un peso. A modo de ejemplo:

  • Core Image ahora soporta un numero grande de filtros para las imágenes. 
  • MapKit ahora soporta rotación en base al magnetómetro, como lo hace la app Maps.
  • Assets Library permite crear álbumes de fotos, acceder al nuevo photo stream, etc.
  • Core Graphics tiene soporte para Paths.
  • Facilidades para la personalización de controles UI
  • Soporte de vCards en AddressBook
  • Core Audio, Core Data y Game Kit tienen unas cuantas novedades.
  • Interfaces deprecated

    Este es de los cambios que no le gusta a nadie. Si vamos a soportar solo iOS 5, no hay problema, pero si debemos soportar también iOS 4, no nos queda otra que duplicar el código para cada SO.

    Pero tenemos una a favor: podemos hacernos los distraídos y dejar los cambios para más adelante. Es que quizás no se justifique hacerlo ahora. Tener código duplicado no le gusta a nadie. Si en unos meses todo va bien, iOS 5 dominará y directamente nos pasamos a las nuevas interfaces.

    Herramientas y otras novedades

    Respecto a Storyboards y Automatic reference counting, son dos temas muy importantes que dan para crear artículos propios. El primero se refiere a una forma distinta de diseñar las aplicaciones, a modo de workflow. Lo segundo se refiere a una forma distinta de manejar el ciclo de vida de los objetos. En vez de hacerlo nosotros, lo dejamos al sistema y en particular al garbage collector que se encargue de ello.

    Para concluir, las mejoras en las herramientas obviamente son muy bienvenidas. Por ejemplo, me encanta que XCode ahora muestre los outlets y actions en los .h y .m. Y el Simulator ahora puede simular diferentes ubicaciones (ya no marca siempre el mismo punto de Infinite Loop 1 en los mapas, al fin!!!).

    0 0 votos
    Article Rating
    Subscribe
    Notify of
    2 Comments
    Oldest
    Newest Most Voted
    Opiniones Inline
    Ver todos los comentarios
    krollian
    krollian
    12 years ago

    La forma en que iOS 5 almacena la caché de las Apps genera ciertos conflictos:

    http://www.marco.org/2011/10/13/ios5-caches-cleaning

    ———-
    Usuario de Mac desde los tiempos del LC y el System 7.0

    Anónimo
    Anónimo
    12 years ago

    Hola creo que los desarrolladores de ios se equivocan a no actualizar sus requerimientos a ios 5, un punto a tener en cuenta es que con ios5 el jail ya no es tan necesario y por tanto una posibilidad real de que las ventas aumenten, evitando las patas de palo.
    Pienso que cuanto antes se adapten las aplicaciones a ios5 antes usaremos todos la nueva version y por eso mismo apple trabajara mas en mejoras y los desarrolladores tambien.
    Si un desarrollador quiere ganar dinero que cree apps buenas y no chorradas. Si se pudiera probar la app y con periodo de prueba los desarrolladores se pondrian las pilas mas. La pasta facil en ios pronto se acabara.

    Saludos.

    Un usuario que se gasta dinero en apps y que a veces le defraudan

    2
    0
    Me encantaría saber tu opinión, por favor, deja un comentariox
    ()
    x