Servicios y herramientas en ios

Transcripción

1 Índice iad, AdMob e In Apps La publicidad de Apple: iad La publicidad de Google: AdMob Otras plataformas de publicidad en ios Micropagos: In-Apps iad, AdMob e In Apps - Ejercicios Incorporando iad a una aplicación ios (1 punto) Incorporando AdMob a una aplicación ios (1 punto) Integrando in-apps: desbloquear pantalla secreta (1 punto) icloud y notifications push icloud Notificaciones push...61 icloud y notifications push - Ejercicios Compartiendo datos en la nube: icloud (1.5 puntos) Notificaciones push (1.5 puntos) Background e hilos Gestión de hilos en ios Modo background Background e hilos - Ejercicios Usando los hilos (1 punto) Entrando en segundo plano y en primer plano (0.5 puntos) Programando una alarma con Notificaciones locales (1.5 puntos)...85 Acceso a la agenda Introducción Posibles usos Implementando el acceso a la agenda...88

2 8 9 Acceso a la agenda - Ejercicios Obteniendo datos de la agenda: nombre y apellidos (2 puntos) Obteniendo datos de la agenda: dirección (1 punto)...94 Técnicas de márketing y casos de éxito Análisis del mercado actual Estudio de los modelos de negocio Promocionando una app Casos de éxito Técnicas de márketing y casos de éxito - Ejercicios Técnicas de márketing y casos de éxito Publicación en App Store y distribución Ad Hoc La App Store Proceso de distribución en la App Store y Ad Hoc Publicación en App Store y distribución Ad Hoc - Ejercicios Publicación en App Store y distribución Ad Hoc

3 1. iad, AdMob e In Apps En esta primera sesión de Servicios ios comenzaremos estudiando el sistema de publicidad de Apple: iad. iad está siendo actualmente uno de los servicios de publicidad más usados en aplicaciones ios junto con otros como AdMob, el propio de Google. Durante esta sesión veremos las ventajas y desventajas usar iad en nuestras aplicaciones, configuraremos el servicio de iad desde el portal de desarrolladores, itunes Connect, y realizaremos una aplicacion de ejemplo que lo use. Una vez visto iad analizaremos el otro sistema de publicidad más usado en aplicaciones móviles: AdMob. Al igual que iad, analizaremos en detalle las ventajas y desventajas de su uso y veremos un ejemplo paso a paso de integración en una aplicación. Por último analizaremos el uso de las compras dentro de las aplicaciones, también llamados "micropagos" o como Apple los llama: in-app. El uso de in-apps está a dia de hoy muy extendido como modelo de negocio en las aplicaciones para móviles. Su uso se está extendiendo cada vez más ya que permite explotar económicamente las aplicaciones gratuitas de una forma "limpia" y bastante atractiva al usuario final. En esta sesión veremos detenidamente como preparar nuestras aplicaciones para el uso de in-apps y realizaremos un ejemplo paso a paso La publicidad de Apple: iad Durante la keynote de 2010 Apple presentó algo muy novedoso y atractivo para el mundo de las aplicaciones ios, una nueva plataforma de publicidad que denominó como iad. El nuevo sistema de publicidad estuvo disponible junto con la salida del iphone 4. La idea fundamental de iad es proporcionar al usuario una publicidad de calidad y con un gran atractivo por la forma de integrarse en las aplicaciones Ventajas y desventajas del uso de iad iad ofrece un sistema de publicidad no intrusivo: los anuncios se muestran en una ventana a parte (popup) dentro de la aplicación, lo que permite que el usuario acceda a esta publicidad sin salir de la aplicación, algo que no ocurre con el resto de modelos de publicidad. Este es un punto a favor. Otra de las ventajas de iad es el sistema de reparto de ganancias que tiene. En un sistema de publicidad común nosotros, como desarrolladores editores, recibimos unos beneficios basados en el ratio de CPC (Coste por click) o CPM (Coste por impresión). En iad el sistema vuelve a cambiar y nosotros recibiremos ganancias de ambos ratios, eso sí, al igual que ocurre en las aplicaciones de pago, recibiremos un 70% de las ganancias obtenidas. Es habitual que el desarrollador obtenga más beneficios de iad que de otras plataformas de publicidad. 3

4 iad está integrado en su totalidad con el sistema de APIs del SDK de ios, así como en los portales de desarrolladores lo que supone una facilidad enorme a la hora de preparar la aplicación para mostrar anuncios así como para gestionar las ganancias. No necesitaremos acceder a otro sistema y gestionar todo por otro lado, con iad lo tenemos integrado al 100%. Pero todo no son cosas buenas... iad tiene una gran desventaja respecto a otras plataformas: la disponibilidad. Actualmente aún existen muchos paises sin total cobertura de anuncios, lo que supone un problema grave para aquellos desarrolladores que basen su modelo de negocio unicamente en este sistema. El país que más disponibilidad tiene de iad es, como no podría ser de otra manera, Estados Unidos. En España, por ejemplo, la disponibilidad es baja. Existen métodos alternativos que nos permiten detectar que en el caso de que nuestra aplicación no reciba anuncios aparezca otra plataforma como AdMob o nuestros propios anuncios. La falta de disponibilidad de anunciantes es en gran medida debido a las altísimas tarifas que impone Apple a los anunciantes, los cuales se ven obligados a dejar a un lado iad para pasarse a otras plataformas más baratas. En este sentido Apple está progresivamente bajando las tarifas, por lo que se espera que a corto-medio plazo existan muchos más anunciantes en iad y por lo tanto, más disponibilidad. Por útlimo comentar que una de las grandes desventajas del modelo de negocio de publicidad en aplicaciones móviles es la necesidad de disponer de una conexión activa a Internet para acceder a los anuncios. Como en el punto anterior, existen varios métodos alternativos que deberemos de contemplar en el caso de que el usuario no disponga de Internet, como por ejemplo mostrar anuncios propios que promocionen nuestros productos (otras aplicaciones...) Integrando iad en nuestras aplicacioness En este punto veremos como integrar la plataforma de publicidad iad en nuestras aplicaciones ios. El banner de publicidad estará preparado para la rotación del dispositivo: este tiene que rotar junto con el dispositivo. Comenzaremos creando un proyecto desde cero en XCode el cual contendrá una vista únicamente y después incorporaremos iad. Comenzamos! Empezamos creando un proyecto nuevo en XCode usando la plantilla Single View Application. Los datos del proyecto serán los siguientes: Product name: serviciosios_sesion01_iad Company Identifier: es.ua.jtech Class prefix: UA Device family: iphone Seleccionar sólo "Use Automatic Reference Counting", el resto de opciones las dejamos desmarcadas. 4

5 Datos del proyecto Una vez creado el proyecto en XCode vamos a modificar la vista que se crea por defecto, UAViewController.xib y vamos a añadirle dos campos y un fondo de color de texto quedando la vista de la siguiente forma: 5

6 UAViewController.xib Una vez que hemos diseñado la vista principal de nuestra aplicación vamos a crear los outlets para relacionar los campos de texto y así poder acceder a ellos desde la controladora. Para hacer esto debemos abrir el fichero UAViewController.h y añadir las siguientes líneas justo antes de la 6

7 @property (weak, nonatomic) IBOutlet UILabel (weak, nonatomic) IBOutlet UITextView *texto; Ahora hacemos lo propio en el fichero de implementación UAViewController.m, añadimos para poder acceder a las labelestadoiad = texto = _texto; Ahora sólo nos queda relacionar los componentes de la vista (los dos campos de texto) con los outlets. Una vez hecho esto ya tenemos la vista creada y lista para usar. Con la vista diseñada y relacionada desde la controladora vamos a implementar el sistema de iad. Comenzamos añadiendo el framework de iad al proyecto. Esto lo hacemos desde la pestaña de Build Phases de la pantalla de información del proyecto. Deplegamos la pestaña Link Binary With Libraries y añadimos el framework iad.framework. Elegir el framework Deberemos de modificar la controladora UAViewController: Añadimos la referencia a la clase ADBannerView que será la encargada de mostrar el banner en la vista. También creamos dos nuevas propiedades en la clase, un flag que nos indique si el banner está visible y otra para referenciar al propio banner. Por último debemos de indicar a la controladora que esta implementará los métodos del protocolo ADBannerViewDelegate, los cuales nos advertirán si se visualiza el banner, si se ha pulsado sobre el, etc. El archivo UAViewController.h quedaría por tanto de la siguiente manera: 7

8 #import <UIKit/UIKit.h> #import UAViewController : (weak, nonatomic) IBOutlet UILabel *labelestadoiad; (weak, nonatomic) IBOutlet UITextView *texto; (nonatomic, strong) IBOutlet ADBannerView *adbannerview; (nonatomic) BOOL Abrimos de nuevo el archivo UAViewController.xib y arrastramos el objeto Ad BannerView a la vista situándolo en la parte superior. Una vez ajustado el banner lo relacionamos como hemos hecho con el resto de outlets quedando la vista principal de la siguiente forma. También deberemos indicar en la vista que la propiedad delegate del objeto Ad BannerView referencia a la controladora, para ello pulsamos la tecla ctrl sobre el banner y sin soltar la tecla arrastramos el cursor del ratón hasta File's owner y seleccionamos "delegate". 8

9 Ad BannerView Por último nos queda completar la implementación de la controladora añadiendo que faltan y los métodos del protocolo ADBannerViewDelegate: //synthesize adbannerview = banneresvisible = _banneresvisible; //metodos de la clase delegada de ADBannerView #pragma mark ADBannerViewDelegate - (void)bannerviewdidloadad:(adbannerview *)banner { if (!self.banneresvisible) { self.banneresvisible = YES; 9

10 - (void)bannerview:(adbannerview *)banner didfailtoreceiveadwitherror:(nserror *)error { if (self.banneresvisible) { self.banneresvisible = NO; En primer método de los dos implementados se ejecutará cuando se cargue la vista del banner. El segundo método servirá para indicarnos si ha ocurrido algún error al recibir el banner de Apple. Para terminar modificaremos los dos métodos anteriores para que actualicen el campo de texto según el banner sea visible o no: - (void)bannerviewdidloadad:(adbannerview *)banner { if (!self.banneresvisible) { self.banneresvisible = YES; self.labelestadoiad.text funcionando"; - (void)bannerview:(adbannerview *)banner didfailtoreceiveadwitherror:(nserror *)error { if (self.banneresvisible) { self.banneresvisible = NO; self.labelestadoiad.text en iad :("; Con esto útlimo ya tenemos iad integrado en una aplicación muy sencilla. Si arrancamos la aplicación veremos que aparecerá un banner de test el cual si pulsamos sobre el nos aparecerá una ventana emergente que con la publicidad (ahora nos aparecerá publicidad de pruebas). La publicidad real aparece únicamente cuando la aplicación está a la venta en la App Store. Si rotamos el dispositivo podemos ver que el banner no se adapta bien a la rotación, para solucionar esto deberemos de completar la implementación añadiendo un par de métodos nuevos y modificando los del protocolo ADBannerViewDelegate. Comenzamos añadiendo dos métodos nuevos para gestionar la rotación del dispositivo y la de la vista del banner: // Método que adapta el tamaño del banner según la rotación del dispositivo - (void)rotabannerposicion:(uiinterfaceorientation)tointerfaceorientation { if (self.adbannerview!= nil) { if 10

11 (UIInterfaceOrientationIsLandscape(toInterfaceOrientation)) { [self.adbannerview setcurrentcontentsizeidentifier: ADBannerContentSizeIdentifierLandscape]; else { [self.adbannerview setcurrentcontentsizeidentifier: ADBannerContentSizeIdentifierPortrait]; // Método que se ejecuta automáticamente cuando el dispositivo rota (void)willrotatetointerfaceorientation:(uiinterfaceorientation)tointerfaceorientation duration:(nstimeinterval)duration { [self rotabannerposicion:tointerfaceorientation]; Ahora añadimos una llamada al método rotabannerposicion desde los métodos del protocolo del AdBannerView quedando los métodos de la siguiente manera: - (void)bannerviewdidloadad:(adbannerview *)banner { if (!self.banneresvisible) { self.banneresvisible = YES; self.labelestadoiad.text funcionando"; [self rotabannerposicion:[uidevice currentdevice].orientation]; - (void)bannerview:(adbannerview *)banner didfailtoreceiveadwitherror:(nserror *)error { if (self.banneresvisible) { self.banneresvisible = NO; self.labelestadoiad.text en iad :("; [self rotabannerposicion:[uidevice currentdevice].orientation]; Si volvemos a ejecutar la aplicación veremos que el banner rota junto con el dispositivo y este se adapta al tamaño adecuado. 11

12 Vista vertical 12

13 Vista horizontal 1.2. La publicidad de Google: AdMob En este apartado analizaremos las ventajas y desventajas de usar la plataforma de publicidad de Google para móviles AdMob y veremos cómo implementarla en una aplicación propia AdMob: Ventajas y desventajas Se podría decir que, en ios, AdMob es el complemento perfecto de iad y es que AdMob tiene varios puntos a favor bastante destacables, vamos a analizarlos uno a uno: Por un lado, en contra de lo que ocurre con iad, la publicidad de AdMob está disponible en la mayoría de paises y de ellos las impresiones son casi al 100%, por lo que en el caso de implementarlo nos aseguraremos que siempre o casi siempre nos aparecerá el banner, algo que no podemos asegurar a dia de hoy con iad. Google es es encargado de la plataforma AdMob, lo que nos asegura una fiabilidad y estabilidad bastante importante. También disponemos de una API bastante documentada y diversos tutoriales para implementar AdMob en nuestras aplicaciones, lo que nos facilita el trabajo. 13

14 Otro punto a favor tiene que ver con la compatibilidad de la plataforma, y es que AdMob es, aparte de ios, compatible con Android, por lo que podremos tener asociada una misma cuenta para distintas plataformas de móviles. Por otro lado, una desventaja que tiene AdMob es que no está integrada con el sistema de desarrolladores de Apple, en concreto con el portal de itunes Connect, por lo que todas las estadísticas de clicks, ganancias, etc. funcionan de otra forma y deberemos de gestionar dos cuentas distintas, una para AdMob y otra para Apple. Respecto a las ganancias y al reparto de beneficios de la publicidad, en AdMob se suele obtener algo menos de ganancias ya que los ratios de CPC y CPM son algo menores. Por último comentar que la publicidad de AdMob en versiones anteriore era intrusiva para la experiencia del usuario. En la versión actual han mejorado este punto y ya funciona de manera similar a iad: al pulsar sobre el banner de publicidad no saldrá de la aplicación y se abrirá a cambio una ventana emergente. Esto es un punto a favor, sin duda alguna Integrando AdMob Con el fin de aprender a integrar AdMob en nuestras aplicaciones ios vamos a realizar un sencillo ejemplo en el que mediante una serie de pasos sencillos nos registraremos como desarrolladores, nos descargaremos el SDK de AdMob para ios y finalmente lo implementaremos. Para poder hacer uso de AdMob tanto en ios como en Android deberemos de registrarnos previamente en su sitio web, para ello abrimos un navegador y entramos en Una vez dentro pulsamos sobre Register en la parte superior derecha, rellenamos todos los campos del formulario y pulsamos en Submit. 14

15 AdMob Una vez registrados en el portal, pulsamos sobre Sitios y aplicaciones > Agregar sitio/aplicación. De nuevo deberemos de rellenar todos nuestros datos de la empresa y de la cuenta personal del banco para los ingresos. 15

16 AdMob Una vez rellenado el formulario anterior nos aparecerá una nueva ventana para elegir la plataforma de la aplicación que vamos a realizar. Ahi seleccionamos Aplicación de iphone 16

17 AdMob Ahora rellenamos los detalles de la aplicación (nombre, categoría, descripción, estilo de los banners...). En el nombre de la aplicación escribiremos sesion01 admob. Completamos el resto de datos y pulsamos en Continuar. 17

18 AdMob Una vez completados los datos básicos de la aplicación vamos a descargarnos el SDK de AdMob. Para descargar el SDK debemos pulsar en Descargar AdMob ios SDK. También podemos acceder a la documentación entrando en el enlace que hay justo debajo del botón de descarga. AdMob Con esto ya nos hemos creado una cuenta en AdMob y nos hemos descargado la última 18

19 versión del SDK para ios. Ahora vamos a crear un nuevo proyecto en XCode usando la plantilla Single View Application y que tendrá los siguientes datos: Product name: serviciosios_sesion01_admob Company Identifier: es.ua.jtech Class prefix: UA Device family: iphone Seleccionar sólo "Use Automatic Reference Counting", el resto de opciones las dejamos desmarcadas. Ahora, con el proyecto abierto, arrastramos la carpeta completa del SDK de AdMob a la raiz del proyecto seleccionando la opción Copy items into destination group's folder (if needed). También deberemos de añadir al proyecto los siguientes frameworks: AudioTollbox.framework, MediaPlayer.framework,MessageUI.framework SystemConfiguration.framework. y AdMob Una vez añadidos los frameworks necesarios y el SDK de AdMob vamos a "comenzar" con el desarrollo del contenido de la aplicación. Vamos a modificar la vista principal UAViewController.xib añadiéndole, al igual que en el ejemplo de iad, dos campos de texto y un fondo, la vista deberá quedar de la siguiente manera: 19

20 AdMob Ahora vamos a modificar la controladora UAViewController para añadirle el código necesario del banner. El archivo UAViewController.h debe quedar como sigue: 20

21 #import <UIKit/UIKit.h> #import UAViewController : (strong, nonatomic) GADBannerView Ahora modificamos el archivo UAViewController.m añadiendo el siguiente código al método viewdidload: - (void)viewdidload { [super viewdidload]; // Do any additional setup after loading the view, typically from a nib. // Posicionamos el banner en la parte inferior de la vista self.admob = [[GADBannerView alloc] initwithframe: CGRectMake(0.0, self.view.frame.size.height GAD_SIZE_320x50.height, GAD_SIZE_320x50.width, GAD_SIZE_320x50.height)]; self.admob.adunitid = AdMob_ID; // Añadimos el banner a la vista self.admob.rootviewcontroller = self; [self.view addsubview:self.admob]; // Hacemos una petición de test para el banner GADRequest *r = [[GADRequest alloc] init]; r.testing = YES; [self.admob loadrequest:r]; También deberemos definir nuestro AdMob ID y del banner: // Debajo del import #define // Nuestro Publisher ID ( // Debajo de la etiqueta AdMob = _AdMob; Una vez hechos estos últimos cambios ya podemos compilar y arrancar nuestra aplicación. Si todo ha ido bien veremos el banner de prueba en la parte inferior de la vista. 21

22 AdMob Si queremos que el banner aparezca en la parte superior de la pantalla, al igual que hicimos en el ejemplo de iad, deberemos de modificar ligeramente el código de posicionamiento del método viewdidload de la siguiente manera: self.admob = [[GADBannerView alloc] initwithframe:cgrectmake(0.0, 0.0, GAD_SIZE_320x50.width, GAD_SIZE_320x50.height)]; 22

23 AdMob Si queremos que el banner rote al mismo tiempo que giramos el dispositivo deberemos de implementarlo nosotros. Podemos acceder a más información sobre la API de AdMob así como a código de ejemplo en esta dirección: 23

24 1.3. Otras plataformas de publicidad en ios Además de iad (Apple) y de AdMob (Google) existen otras plataformas de publicidad de las cuales podemos hacer uso en nuestras aplicaciones. Una de las más conocidas es AdSense (también de Google) y MobClix. Esta útlima se suele usar como complemento a iad o AdMob ya que sus ratios de CPM y CPC son bastantes pequeños por lo que los beneficios que obtenemos son pocos. AdSense en cambio ofrece unos porcentajes de ganancias algo mayores pero tiene el inconveniente que la publicidad que ofrece es muy poco atractiva: banners con fondo blanco o negro y con texto, sin imágenes. Esta plataforma suele ser muy poco efectiva y, por lo tanto, poco recomendada para usar como sistema de publicidad principal. Como hemos visto en los puntos anteriores, muchas veces tenemos el problema de la falta de conexión a Internet o falta de disponibilidad de banners. Esto provoca que la publicidad no se muestre en la aplicación y por lo tanto, no obtengamos ganancias de esta. Para evitar esto deberemos de implementar un "plan alternativo" que nos asegure que siempre se va a mostrar la publicidad. Tenemos dos opciones para implementar este plan alternativo: programarlo en nuestra aplicación nosotros mismos o utilizar una API que nos ayude a hacerlo. Esta última opción es la que vamos a analizar con un poco más de profundidad. Existen varios sistemas online que ofrecen un servicio de "rotación" de publicidad entre distintas plataformas, entre ellas destaca para móviles AdWhirl ( AdWhirl un sistema que se encarga dinámicamente y de forma totalmente automática de cambiar entre redes de publicidad según la preferencia que indiquemos nosotros y la disponibilidad de estas. 24

25 Imagen AdWhirl además destaca porque podemos incorporar nuestros propios banners y disponemos de toda la gestión de las plataformas de publicidad desde un mismo panel de control, lo que nos facilita enormemente la tarea de gestión de estas. En AdWhirl podemos añadir la inmensa mayoría de redes de publicidad, entre ellas están: iad, AdMob, JumTab, Millennial Media, Quattro Wireless, Mobclix, AdSense, etc... Una vez registrados en el sistema (totalmente gratuito) deberemos escoger las redes que queremos usar en nuestra aplicación y asignarles una preferencia. Esta preferencia se tendrá en cuenta a la hora de mostrar la publicidad, si una red no tiene disponiblidad de banners pasará a la siguiente con más preferencia. Obviamente deberemos registrarnos previamente en aquellas plataformas (o redes) de publicidad que vayamos a utilizar en AdWhirl, y desde el panel de control añadiremos las claves de cada una Micropagos: In-Apps Una vez visto el modelo de negocio de publicidad vamos a analizar en profundidad otro modelo bastante usado entre los desarrolladores de Apple: in-apps. 25

26 In-app Los in-apps o micropagos son compras que se realizan dentro de la aplicación. Una aplicación de ios puede tener tantos in-apps como quiera del desarrollador y cada uno de estos al precio que se desee (según las tarifas de Apple). Existen varios tipos de in-apps aunque los más usados son consumibles y no consumibles: Consumibles: Aquellos que el usuario puede comprar más de una vez, por ejemplo: dinero virtual en un juego social. No consumibles: Aquellos que el usuairo sólo puede comprar una vez, por ejemplo: desbloquear un nivel en un juego. Suscripciones auto renovables: Permite realizar una venta de servicios por un tiempo y que cuando finalice ese periodo se auto-renueve esa venta de forma automática. Por ejemplo: si el usuario se suscribe a la compra de una revista mensual. Suscripciones no renovables: Permite realizar una venta de servicios por un tiempo limitado. Por ejemplo: acceso de un mes completo a una funcionalidad concreta de una aplicación de navegación. Suscripciones gratutitas: Permite realizar suscripciones gratuitas a revistas (sólo disponible para aplicaciones del Newsstand de Apple). Lo más habitual es implementar el sistema de in-apps en aplicaciones gratuitas ya que de este modo conseguiremos muchos más descargas y, por lo tanto, más clientes potenciales de in-apps. La implementación de in-apps en una aplicación ios es algo compleja y requiere de una cuenta activa como desarrollador en Apple. En el siguiente apartado realizaremos un ejemplo paso a paso de incorporación de un in-app en una aplicación para iphone. 26

27 Implementando los in-apps: App freemium En este apartado veremos en más detalle como incorporar los in-apps en nuestras aplicaciones. Para ello realizaremos un ejemplo de una aplicación freemium o lo que es lo mismo: aplicación reducida con opción a compra para desbloquear la versión completa). La aplicación la implementaremos paso a paso durante los cuales veremos como crear los in-apps dentro del portal de itunes Connect y como programarlos en modo de test o sandboxing en una aplicación sencilla. Empezamos! El ejemplo que vamos a realizar consistirá en una sencilla aplicación iphone la cual estará formada por dos vistas: una principal a la que todo el mundo tendrá acceso y otra a la que sólo se podrá acceder si hemos comprado un in-app que costará 0.79 euros, una pantalla "secreta". Este in-app será de tipo no consumible, es decir, sólo podremos comprarlo una vez y tendremos que tener en cuenta la compra para que cada vez que el usuario arranque la aplicación compruebe si ya ha comprado el in-app Preparación: Apple Developer y itunes Connect Antes de empezar con la programación de la aplicación en XCode vamos a crear un App ID para nuestra aplicación. El App ID es una cadena de texto única que identifica cada una de nuestras aplicaciones, en este caso crearemos un App ID dentro del portal de desarrolladores ( con el nombre Ejemplo in app y el identificador (Bundle ID) es.ua.jtech.ejemploinapp. Provisioning Portal Antes de empezar con la programación de la aplicación en XCode vamos a crear los 27

28 in-apps dentro del portal itunes Connect. Conviene recordar que para acceder a este portal deberemos de tener una cuenta activa como desarrollador Apple. Accedemos al portal ( usando nuestro Apple ID y contraseña. Una vez dentro entraremos dentro del apartado Manage Your Applications y creamos una nueva aplicación pulsando en Add New App. Manage Your Applications El formulario que nos aparece lo completamos según la siguiente imagen y pulsamos en "Continue". App Informaion Seguimos completando el resto de formularios básicos de creación de una aplicación nueva en itunes Connect... Una vez hecho esto (nos llevará un tiempo ya que debemos de escribir una descripción, subir unas imágenes básicas, etc.) pasaremos a crear los in-apps. Una vez que hayamos guardado el formulario anterior pulsamos sobre el botón "Manage In-App Purchases" para comenzar con la creación de los in-apps. 28

29 Manage In-App Purchases En el formulario que nos aparece ahora deberemos de escoger entre cuatro tipos distintos de in-apps, los dos primeros son los que hemos comentado anteriormente (consumibles y no consumibles) y los otros dos son exclusivos para aplicaciones del quiosco (Newstand). Nosotros escogeremos el segundo tipo, Non Consumable ya que una vez que el usuario compre el in-app este se bloqueará y no tendrá que comprarlo más veces. In app Ahora deberemos de completar todos los campos del formulario sobre el in-app. Escribiremos un nombre único para identificarlo, una breve descripción en al menos un idioma, un precio (elegimos la primera tarifa, tier 1) y una imagen. Rellenaremos el formulario tal y como se muestra en la siguiente imagen: 29

30 In-App configuración Una vez completado el formulario anterior ya tenemos el in-app creado y configurado en itunes Connect. Ahora deberemos de implementarlo en nuestra aplicación, pero antes vamos a diseñar toda la estructura básica Implementación de toda la estructura básica Comenzamos creando un proyecto nuevo en XCode con la plantilla Single View 30

31 Application al que llamaremos serviciosios_sesion01_inapps y tendrá los siguientes datos: Product name: serviciosios_sesion01_inapps Company Identifier: es.ua.jtech Class prefix: UA Device family: iphone Seleccionar sólo "Use Automatic Reference Counting", el resto de opciones las dejamos desmarcadas. Una vez creado el proyecto en XCode vamos a modificar la vista principal UAViewController.xib añadiendo una etiqueta de texto y dos botones, uno para comprar el in-app y otro para abrir la pantalla "secreta": 31

32 Vista Ahora programamos la controladora principal de la aplicación. Abrimos el archivo UAViewController.h y lo dejamos de la siguiente manera: #import UAViewController : UIViewController 32

33 @property (weak, nonatomic) IBOutlet UIButton (weak, nonatomic) IBOutlet UIButton *botonabreventanasecreta; -(IBAction)clickBotonCompra:(id)sender; Ahora modificamos el archivo UAViewController.m añadiendo y las acciones de los botones: botoncompra = botonabreventanasecreta = _botonabreventanasecreta; // Añadimos los siguientes métodos -(IBAction)clickBotonCompra:(id)sender { NSLog(@"clickBotonCompra"); // Código de lanzamiento del in-app -(IBAction)clickBotonVentanaSecreta:(id)sender { NSLog(@"clickBotonVentanaSecreta"); // Código para abrir la ventana secreta Ahora vamos a diseñar la "ventana secreta", para ello vamos a crear un nuevo objeto de tipo UIViewController Subclass que llamaremos VentanaSecretaViewController. Abrimos la vista y la editamos a nuestro gusto, por ejemplo: 33

34 VentanaSecretaViewController Una vez hecho esto ahora nos queda relacionar los Outlets y las acciones de la vista principal, esto lo hacemos desde la propia vista, y completar la acción del botón que abre la ventana secreta: -(IBAction)clickBotonVentanaSecreta:(id)sender { 34

35 VentanaSecretaViewController *ventanasecreta = [[VentanaSecretaViewController alloc] initwithnibname:@"ventanasecretaviewcontroller" bundle:nil]; [self presentmodalviewcontroller:ventanasecreta animated:yes]; Comprobamos que la aplicación funciona correctamente Implementación del in-app Una vez implementado el funcionamiento básico de la aplicación (sin in-apps) vamos a incorporar el in-app para desbloquear la ventana secreta. Comenzamos añadiendo el framework StoreKit al proyecto y modificando el fichero UAViewController.h importando la clase StoreKit y añadiendo el protocolo SKProductsRequestDelegate en la definición de la controladora para que esta implemente sus métodos delegados. Este sería el flujo de información entre la aplicación nuestra y la App Store que vamos a usar: 35

36 Flujo de información con la App Store El código que implementará el in-app quedaría como sigue: #import <UIKit/UIKit.h> #import UAViewController : UIViewController <SKProductsRequestDelegate, (weak, nonatomic) IBOutlet UIButton *botoncompra; 36

37 @property (weak, nonatomic) IBOutlet UIButton retain) NSMutableArray retain) NSMutableArray *productdetailslist; -(IBAction)clickBotonCompra:(id)sender; Ahora tenemos que modificar el archivo UAViewController.m añadiendo las clases delegadas del protocolo SKProductsRequestDelegate y del observer SKPaymentTransactionObserver. El código final quedaría de la siguiente manera: #import "UAViewController.h" #import botoncompra = botonabreventanasecreta = productidentifierlist = productdetailslist = _productdetailslist; - (void)didreceivememorywarning { [super didreceivememorywarning]; // Release any cached data, images, etc that aren't in use. #pragma mark - View lifecycle - (void)viewdidload { self.productidentifierlist = [[NSMutableArray alloc] init]; self.productdetailslist = [[NSMutableArray alloc] init]; [self.productidentifierlist addobject:@"ejemplo3"]; // Cargamos la lista de productos SKProductsRequest *request = [[SKProductsRequest alloc] initwithproductidentifiers:[nsset setwitharray:self.productidentifierlist]]; request.delegate = self; [request start]; // Comprobamos si hemos comprado antes el in-app if ([[NSUserDefaults standarduserdefaults] boolforkey:@"inappcomprado"] == YES){ self.botonabreventanasecreta.hidden = NO; else { self.botonabreventanasecreta.hidden = YES; // Reinicia cualquier transacción si esta se interrumpió [[SKPaymentQueue defaultqueue] addtransactionobserver:self]; [super viewdidload]; 37

38 - (void)viewdidunload { [super viewdidunload]; // Release any retained subviews of the main view. // e.g. self.myoutlet = nil; - (void)viewwillappear:(bool)animated { [super viewwillappear:animated]; - (void)viewdidappear:(bool)animated { [super viewdidappear:animated]; - (void)viewwilldisappear:(bool)animated { [super viewwilldisappear:animated]; - (void)viewdiddisappear:(bool)animated { [super viewdiddisappear:animated]; - (BOOL)shouldAutorotateToInterfaceOrientation: (UIInterfaceOrientation)interfaceOrientation { // Return YES for supported orientations return (interfaceorientation!= UIInterfaceOrientationPortraitUpsideDown); #pragma mark Acciones de los botones -(IBAction)clickBotonCompra:(id)sender { NSLog(@"clickBotonCompra"); // Código de lanzamiento del in-app if ([self.productdetailslist count] > 0 && [SKPaymentQueue canmakepayments]){ SKProduct *thisproduct = [self.productdetailslist objectatindex:0]; SKPayment *payment = [SKPayment paymentwithproduct:thisproduct]; [[SKPaymentQueue defaultqueue] addpayment:payment]; NSLog(@"Comprando..."); else { NSLog(@"No existen productos"); -(IBAction)clickBotonVentanaSecreta:(id)sender { NSLog(@"clickBotonVentanaSecreta"); VentanaSecretaViewController *ventanasecreta = [[VentanaSecretaViewController alloc] initwithnibname:@"ventanasecretaviewcontroller" bundle:nil]; 38

39 [self presentmodalviewcontroller:ventanasecreta animated:yes]; #pragma mark - InApps métodos /* * METODO QUE SE ACTIVA CUANDO RECIBIMOS LOS PRODUCTOS QUE TENEMOS EN IN-APP */ -(void)productsrequest:(skproductsrequest *)request didreceiveresponse:(skproductsresponse *)response { NSLog(@"didReceiveResponse. Total productos: %d", [response.products count]); [self.productdetailslist addobjectsfromarray: response.products]; for (NSString *invalidproductid in response.invalidproductidentifiers) { NSLog(@"Producto invalido id: %@", invalidproductid); /* * CARGA DE PRODUCTOS TERMINADA */ -(void)requestdidfinish:(skrequest *)request { /* * FALLO CON LA CARGA DE LOS PRODUCTOS */ -(void)request:(skrequest *)request didfailwitherror:(nserror *)error { NSLog(@"Failed to connect with error: %@", [error localizeddescription]); /* * METODO QUE DESBLOQUEA EL BOTÓN */ - (void)desbloqueaventanasecreta { NSLog(@"Actualiza flag de in app comprado"); [[NSUserDefaults standarduserdefaults] setbool:no forkey:@"inappcomprado"]; [[NSUserDefaults standarduserdefaults] synchronize]; // Activamos el boton self.botonabreventanasecreta.hidden = NO; /* * METODO QUE SE ACTIVA CUANDO SE COMPLETA UNA COMPRA */ - (void)completetransaction:(skpaymenttransaction *)transaction { NSLog(@"completeTransaction..."); [self desbloqueaventanasecreta]; 39

40 [[SKPaymentQueue defaultqueue] finishtransaction: transaction]; /* * METODO QUE SE ACTIVA CUANDO SE CONTINUA CON UNA COMPRA */ - (void)restoretransaction:(skpaymenttransaction *)transaction { NSLog(@"restoreTransaction..."); [self desbloqueaventanasecreta]; [[SKPaymentQueue defaultqueue] finishtransaction: transaction]; /* * METODO QUE SE ACTIVA CUANDO UNA COMPRA FALLA */ - (void)failedtransaction:(skpaymenttransaction *)transaction { if (transaction.error.code!= SKErrorPaymentCancelled) { NSLog(@"Transaction error: %@", transaction.error.localizeddescription); [[SKPaymentQueue defaultqueue] finishtransaction: transaction]; /* * METODO QUE SE ACTIVA CUANDO REALIZAMOS UNA TRANSACCIÓN */ - (void)paymentqueue:(skpaymentqueue *)queue updatedtransactions:(nsarray *)transactions { NSLog(@"updatedTransactions..."); for (SKPaymentTransaction *transaction in transactions) { switch (transaction.transactionstate) { case SKPaymentTransactionStatePurchased: [self completetransaction:transaction]; break; case SKPaymentTransactionStateFailed: [self failedtransaction:transaction]; break; case SKPaymentTransactionStateRestored: [self restoretransaction:transaction]; default: Atención 40

41 El bundle ID de la aplicación en XCode debe de coincidir con el Bundle identifier que hemos especificado al crear la aplicación en itunes Connect. Si ejecutamos el código nos debería de aparecer el botón de la ventana secreta desactivado. Cuando pulsemos sobre el botón de comprar in-app nos pedirá un nombre de usuario y contraseña, ahí tendremos que escribir nuestro usuario de pruebas que previamente hemos creado dentro de la sección Manage Users del portal itunes Connect. En el momento de confirmar la compra se ejecutará el método updatedtransactions el cual activará, si todo ha ido bien, el botón para mostrar la ventana secreta. 41

42 Confirmación in-app 42

43 2. iad, AdMob e In Apps - Ejercicios Antes de empezar a crear los proyectos, debes descargarte las plantillas desde bitbucket. Para ello: 1. Entraremos en nuestra cuenta de bitbucket.org, seleccionaremos el repositorio git expertomoviles/serv-ios-expertomoviles (del que tendremos únicamente permisos de lectura), y haremos un Fork de dicho repositorio en nuestra cuenta, para así tener una copia propia del repositorio con permisos de administración. 2. Para evitar que bitbucket nos dé un error por sobrepasar el número de usuarios permitidos, debemos ir al apartado Access management de las preferencias del repositorio que acabamos de crear y eliminar los permisos de lectura para el grupo Estudiantes (tendremos estos permisos concedidos si al hacer el Fork hemos especificado que se hereden los permisos del proyecto original). Los únicos permisos que debe tener nuestro repositorio deben ser para el propietario (owner) y para el usuario Experto Moviles. 3. Una vez tenemos nuestra copia del repositorio con las plantillas correctamente configuradas en bitbucket, haremos un clone en nuestra máquina local: git clone 4. De esta forma se crea en nuestro ordenador el directorio serv-ios-expertomoviles y se descargan en él las plantillas para los ejercicios del módulo y un fichero.gitignore. Además, ya está completamente configurado y conectado con nuestro repositorio remoto, por lo que lo único que deberemos hacer será subir los cambios conforme realicemos los ejercicios, utilizando los siguientes comandos: git add. git commit -a -m "[Mensaje del commit]" git push origin master 2.1. Incorporando iad a una aplicación ios (1 punto) Para realizar el ejercicio debemos usar la plantilla con el nombre EjercicioIAD. En este ejercicio vamos a implementar una aplicación muy sencilla para iphone que contenga la plataforma de publicidad iad como modelo de negocio. La aplicación estará compuesta por una sola ventana que tendrá un objeto de tipo UILabel el cual informará del estado de la publicidad (visible o no visible). En el caso de que esta no esté visible mostraremos una imagen de publicidad nuestra. De este modo siempre se mostrará publicidad en la aplicación. Para completar el ejercicio deberemos de realizar los siguientes pasos: a) Modificamos el fichero UAViewController.xib añadiendo un objeto de tipo Label en mitad de la vista, un objeto de tipo Ad BannerView (el banner iad) en la parte superior de la pantalla y por último un objeto de tipo Image View justo encima del banner de iad que será nuestro propio banner. Definimos los outlets 43

44 correspondientes en el fichero UAViewController.h y establecemos las relaciones desde la vista. b) Indicamos que el delegado del objeto Ad BannerView es la controladora (File's Owner). c) Modificamos la definición de la controladora (fichero UAViewController.h) para que esta implemente el protocolo ADBannerViewDelegate. d) Completamos el método bannerviewdidloadad: para que cuando este se ejecute oculte nuestro banner personalizado y cambie el texto del label para que ponga "Banner visible" e) Completamos el método bannerview:didfailtoreceiveadwitherror: para que cuando este se ejecute muestre nuestro banner personalizado y cambie el texto del label para que ponga "Banner no visible" f) Comprobar que funciona todo bien. Probar a rotar el dispositivo: el banner se debe de posicionar correctamente tanto en horizontal como en vertical. También probar quitar la conexión a internet para que se muestre nuestro banner Incorporando AdMob a una aplicación ios (1 punto) Para realizar el ejercicio debemos usar la plantilla con el nombre ejercicio_admob. En este ejercicio vamos a incorporar la red de publicidad AdMob a una aplicación de iphone. Para evitar todo el proceso de registro en el sitio de AdMob ( usaremos la plantilla indicada. Completar el archivo UAViewController.m con el código necesario para: a) Crear el banner para que aparezca en la parte inferior de la pantalla. b) Crear el banner para que aparezca en la parte superior de la pantalla. c) Cargar el banner en modo testing Qué ventajas y desventajas encuentras al usar la plataforma AdMob con respecto a iad? (contestar en un fichero de texto dentro del proyecto) Integrando in-apps: desbloquear pantalla secreta (1 punto) Para realizar el ejercicio debemos usar la plantilla con el nombre ejercicio_inapp. En este ejercicio vamos a usar lo aprendido de los in-apps para acceder a una pantalla "secreta" de una aplicación. Básicamente el ejercicio consistirá en programar parte de una controladora para conseguir que cuando "compremos" un in-app se desbloqueará un botón que dará acceso a una pantalla antes nunca vista. Ya que para usar in-apps necesitamos disponer de una cuenta de desarrollador Apple y nosotros no la tenemos (la universitaria no sirve para esto), usaremos una plantilla con todo el proceso previo de preparación de la aplicación en itunes Connect, certificados, etc ya implementado. Lo único que deberemos hacer será completar una serie de pasos 44

45 necesarios para el funcionamiento del in-app. a) Importar el framework StoreKit.framework necesario para el uso de la API de in-apps. b) Completar el método restoretransaction: de la clase UAViewController c) Completar el método completetransaction: de la clase UAViewController d) Completar el método desbloqueaventanasecreta Podemos probar si funciona el in-app usando el siguiente usuario de test: Nombre de usuario: Contraseña: usuariotest1a Nota Para almacenar en memoria el estado de in-app comprado o no comprado podemos hacerlo usando el método de persistencia NSUserDefaults de la siguiente forma: [[NSUserDefaults standarduserdefaults] setbool:yes forkey:@"inappcomprado"]; 45

46 3. icloud y notifications push Con la llegada de ios 5 los desarrolladores se han puesto manos a la obra para adaptar en la medida de lo posible todas sus aplicaciones a los nuevos requerimientos y especificaciones de Apple. A lo largo del curso hemos hablado de distintas novedades que nos trae ios 5 como el nuevo sistema de ARC (Automatic Reference Counting), la integración de Twitter en el sistema operativo, los Storyboards para diseñar la estructura de las apps, etc. En esta sesión es el turno de hablar de una de los mayores novedades que nos proporciona esta nueva versión de ios y es nada más y nada menos que icloud. Con icloud podremos, en resumen, gestionar todos los documentos, configuraciones e incluso bases de datos completas en la nube para de este modo tener acceso de forma totalmente transparente e instantánea para el usuario final a la misma información en todos los dispositivos ios, Macs y PCs que tengamos asociados a nuestra cuenta. En el primer apartado ampliaremos en profundidad este tema y veremos qué ventajas nos puede llegar a suponer el uso de este sistema en nuestras aplicaciones. También diseñaremos una aplicación desde cero que implemente icloud. Por otro lado hablaremos de las notificaciones push, las cuales podemos hacer uso en las aplicaciones que desarrollemos para determinados casos y que, sin duda, ofrecerán un punto a favor en cuanto a mejora en la experiencia del usuario y sobre todo, un gran avance en temas de marketing. De las notificaciones push hablaremos en el segundo apartado de esta sesión y veremos también cómo implementarlas en nuestras aplicaciones. Comenzamos! 3.1. icloud Seguro que en algún momento has oído hablar de icloud, ya sea por la televisión, por la prensa escrita o por Internet, el caso es que desde Apple nos "venden" esta nueva característica de ios 5 como algo menos que "el mayor avance de todos los tiempos". Pero en realidad, Qué supone para nosotros, los desarrolladores esta nueva funcionalidad? A continuación explicaremos en qué casos podremos implementarla, cuales son los requerimientos y un ejemplo concreto desarrollado desde cero con el que podremos comprobar cómo funciona icloud en un entorno real. Vamos para allá! Definición y características de icloud icloud es una nueva funcionalidad disponible a partir de ios 5 en la que, mediante el uso de una API, podremos almacenar todo tipo de documentos y propiedades de nuestras aplicaciones en la nube. Todas las actualizaciones que se produzcan en icloud se transmitirá de forma inalámbrica, automática y sincronizada a cualquier dispositivo que lo soporte (idevice con ios 5 ó PC/Mac debidamente configurados). 46

47 icloud Cada usuario dispondrá de una cuenta que tendrá que configurar en su dispositivo y que será normalmente la misma que itunes. La configuración de icloud en los dispositivos con ios se realiza desde la aplicación de Ajustes, dentro del apartado icloud. Ahi deberemos especificar nuestro nombre de usuario y contraseña en el caso que dispongamos de ello, sino deberemos de crear un nuevo usuario. El almacenamiento de icloud es un conjunto de interfaces diseñadas para compartir datos a través de distintas instancias de la aplicación en distintos dispositivos. Los cambios que se realicen en estos datos se propagrán automáticamente por los distintos dispositivos que ejecuten la misma aplicación. Entre los grandes beneficios que esto ofrece a los desarrolladores están: Ya no hará falta en la mayoría de casos contratar un servicio externo que haga las funciones de servidor ya que usaremos el propio de Apple ahorrando, por tanto muchisimos costes adicionales. No hará falta escribir una API propia para el acceso a datos externos ya que la propia de icloud nos ofrece todo lo que necesitamos tanto para la recepción de documentos desde icloud como para el envio. También existen varios métodos referentes a la sincronización de los datos para evitar inconsistencias, algo que trataremos en los 47

48 siguientes puntos. Existen también una serie de condiciones que deberemos de tener en cuenta a la hora de incorporar este servicio en nuestras aplicaciones: Límite de capacidad: Cada usuario tiene como máximo en principio 5GB de almacenamiento en su cuenta icloud gratuita a repartir entre todas las aplicaciones que utilicen este servicio. En el caso que contrate una cuenta premium (de pago) este límite se aumentará hasta llegar a los 50GB. Los desarrolladores tendremos que tener en cuenta este límite y optimizar en la medida de lo posible los datos y/o documentos que nuestra aplicación comparta en la nube. Sincronizaciones: Las posibles incoherencias o conflictos que puedan aparecer en nuestra aplicación las debemos de gestionar nosotros de forma manual. La API de icloud nos proporciona una serie de métodos que nos ayudan a esta gestión pero debemos ser nosotros mismos los que la implementemos en nuestras aplicaciones. Autorizaciones (entitlements) necesarios: Para que icloud funcione deberemos de configurar previamente dentro del portal de desarrollador las autorizaciones necesarias y activar el servicio de icloud para la aplicación que desarrollemos. Esto deberemos hacerlo también desde la configuración del proyecto en XCode, aunque lo detallaremos más adelante en el ejemplo que realicemos desde cero. Funcionamiento sin icloud: Nuestra aplicación deberá funcionar correctamente en el caso de que icloud no esté configurado en el dispositivo en donde se esté ejecutando. icloud se debe tratar como una funcionalidad "extra" y nunca como "necesaria" para el funcionamiento correcto de nuestra aplicación, es por ello que deberemos de comprobar en nuestro código si el usuario dispone de una cuenta de icloud configurada en el dispositivo y en el caso de que no sea así no utilizaremos icloud pero sí el resto de funcionalidades. Apple ha establecido dos formas de incorporar icloud a nuestras aplicaciones, las cuales deberemos de tener en cuenta a la hora de implementarlo, son estas: Almacenamiento de documentos: Esta característica la utilizaremos para almacenar documentos (ficheros) de distintos tipos en la cuenta icloud. No existe límite de almacenamiento (el máximo disponible en la cuenta del usuario). Almacenamiento de datos tipo clave-valor: La utilizaremos para almacenar pequeñas cantidades de datos como configuraciones del usuario, datos de acceso a la aplicación, etc. El límite máximo de almacenamiento está en 64KB. 48

49 icloud Ejemplos de casos de uso de icloud icloud es una funcionalidad que se puede incorporar en gran parte de las aplicaciones ios que vemos en la actualidad, sin embargo hay muchas otras en la que su implementación no sería un acierto o simplemente no aportaría nada o casi nada a la mejora de la experiencia de usuario. A continuación comentaremos distintos tipos de aplicaciones en donde icloud puede ser de utilidad: Aplicaciones de gestión documental: Para compartir documentos entre varios dispositivos. Aplicaciones de fotografía: Para compartir fotografias que hagamos con el iphone / ipad entre varios dispositivos. Aplicaciones que hagan uso de un calendario: Compartir eventos del calendario. Aplicaciones de gestión de tareas (ToDos): Compartir tareas entre varios dispositivos. Aplicaciones con apartados de configuración: Compartir datos de la configuración de una aplicación entre dispositivos. Juegos de distintos tipos: Compartir datos de niveles alcanzados, puntuaciones, etc. Como podemos ver existen muchos tipos de aplicaciones en la que usar el servicio de icloud puede llegar a ser un acierto. A continuación veremos cómo implementar dicho servicio en nuestras aplicaciones ios mediante un sencillo ejemplo Desarrollando con icloud: Preparaciones iniciales Una vez vistas las características principales del uso de icloud así como distintos ejemplos de uso vamos a desarrollar desde cero nuestra primera aplicación con icloud. En el ejemplo que vamos a comentar implementaremos una sencilla aplicación en la que el usuario creará un documento de texto simple y este se gestionará a través de icloud. 49

50 También almacenaremos los datos de acceso a la aplicación en la nube. Como se puede deducir, haremos uso de los dos métodos de almacenamiento comentados en el primer punto: almacenamiento de documentos y almacenamiento de datos tipo clave-valor. Para empezar a desarrollar en icloud deberemos de configurar previamente una serie de datos y opciones en nuestra cuenta de desarrollador ( Comenzaremos configurando una nueva aplicación, para ello deberemos acceder a portal de desarrolladores ( utilizando nuestro nombre de usuario y contraseña. Una vez dentro accederemos al Provisioning Portal y crearemos un nuevo App ID que llamaremos, por ejemplo, ua.es.jtech.ejemploicloud. Atención Tenemos que tener en cuenta que el App ID que creemos debe de coincidir plenamente con el Bundle identifier que tendrá la aplicación que creemos posteriormente en XCode. Una vez creado el App ID nos aparecerá en la lista del Provisioning Portal tal y como aparece en la imagen siguiente: Provisioning Portal: icloud Como podemos ver, icloud no está configurado aún, para configurarlo deberemos pulsar sobre configure. En la ventana que nos aparece marcamos para activar icloud tal y como aparece en la imagen de a continuación: 50

51 Configuración app con icloud Ahora abrimos la pestaña de Provisioning y creamos un nuevo provisioning profile para la aplicación que contenga el App ID creado anteriormente, el certificado que queramos usar y los dispositivos con los que queramos probar la aplicación. Ahora nos descargamos el provisioning profile que acabamos de crear y haremos doble click sobre el para adjuntarlo a nuestra lista en XCode. Pruebas de icloud Para poder probar icloud deberemos de disponer de un dispositivo (iphone, ipad o ipod Touch) debidamente configurado desde el provisioning portal y con ios 5 instalado. icloud no funcionará en el simulador de XCode. Una vez que tenemos todos los preparativos previos para usar icloud ya podemos empezar a programar nuestra aplicación Desarrollando con icloud: Configuración del proyecto En este apartado comprobaremos lo sencillo que es hacer una aplicación compatible con icloud. Comenzaremos abriendo XCode y creando un nuevo proyecto de tipo Single View Aplication que será Universal, que llamaremos ejemploicloud y tendrá como Company Identifier: ua.es.jtech. Pulsamos sobre Next y ya tenemos el proyecto de XCode creado. Configuración proyecto XCode 51

52 Abrimos las propiedades del proyecto y nos dirigimos al apartado de Entitlements que se encuentra dentro de la pestaña de Summary, en el último apartado. Ahi marcamos la casilla de Enable Entitlements. Automáticamente nos aparecerá un nuevo archivo en el raiz del proyecto que se llamará ejemploidcloud.entitlements. Ahora deberemos modificar los campos de icloud Key-Value Store y icloud Containers con el Team-ID de los provisioning profile que hemos creado anteriormente. Para ver el Team-ID debemos acceder de nuevo a la sección de Apps IDs del ios Provisioning Portal y copiar la cadena de texto que aparece justo antes del nombre del profile, en nuestro caso es: 3S952AGH46. Ahora editamos los tres campos del apartado Entitlements del resumen del proyecto quedando de la siguiente manera: Entitlements Con esto último ya tenemos el proyecto debidamente configurado para usar icloud. Ahora deberemos de implementarlo en nuestro código, vamos a ello! Desarrollando con icloud: Programación de ficheros Comenzaremos programando la gestión de documentos en icloud, para ello deberemos de crear una clase que herede de UIDocument la cual personalizaremos e implementaremos toda la gestión dentro del AppDelegate. En la vista crearemos un cambo de tipo TextView que será el que contenga el texto que almacenaremos o cargaremos (según convenga) en el fichero que creemos dentro del almacenamiento icloud. Nota Realizar toda la implementación básica de gestión de icloud del modelo dentro de la clase AppDelegate no es lo recomendado ya que no se cumpliría de forma estricta la estructura MVC propuesta por Apple. Nosotros lo hemos realizado de esa manera para simplificar el ejemplo. Comenzamos creando la clase que gestionará el documento de icloud, para ello hacemos click sobre New > New File, seleccionamos Objective-C class y lo llamamos 52

53 MiDocumento. Dentro del fichero MiDocumento.h escribimos lo siguiente: #import <Foundation/Foundation.h> #import MiDocumento : UIDocument { NSString *documenttext; id (nonatomic, retain) NSString (nonatomic, assign) id Y en el fichero MiDocumento.m lo siguiente: #import documenttext = delegate = _delegate; // ** LECTURA ** - (BOOL)loadFromContents:(id)contents oftype:(nsstring *)typename error:(nserror **)outerror { NSLog(@"UIDocument: loadfromcontents: state = %d, typename=%@", self.documentstate, typename); if ([contents length] > 0) { self.documenttext = [[NSString alloc] initwithbytes:[contents bytes] length:[contents length] encoding:nsutf8stringencoding]; else { self.documenttext NSLog(@"UIDocument: Se ha cargado el siguiente texto desde icloud: %@", self.documenttext); return YES; // ** ESCRITURA ** -(id)contentsfortype:(nsstring *)typename error:(nserror **)outerror { if ([self.documenttext length] == 0) { self.documenttext nota para el curso especialista de moviles"; 53

54 Guardare el siguiente texto en icloud: self.documenttext); return [NSData datawithbytes:[self.documenttext UTF8String] length:[self.documenttext Como podemos ver, la clase MiDocumento hereda de UIDocument, una nueva clase disponible en ios 5, este tipo se encargará de encapsular todos los datos referidos a un documento de texto convencional. En icloud deberemos usar esta clase para gestionar los documentos que creemos. Dentro de nuestra clase MiDocumento hemos sobreescrito la propiedad de text y la delegate. Ahora la propiedad documenttext será la que contenga el texto. Hemos sobreescrito dos métodos de la clase UIDocument: loadfromcontents: Realiza la lectura del documento. Convierte los datos recibidos en bytes a una cadena de texto NSString codificada en UTF8, la cual almacenaremos dentro de la propiedad documenttext. contentsfortype: Realiza la escritura en el documento. Devuelve en forma de datos NSData la cadena de texto convertida a UTF8. Ahora abrimos el fichero AppDelegate.h y creamos las siguientes propiedades y métodos al final de este. Estos métodos se explicarán más (strong, nonatomic) UIWindow (strong, nonatomic) NSMetadataQuery (strong, nonatomic) MiDocumento *documento; - (void)cargadocumento; - (void) escribeendocumento:(nsstring *)texto; Abrimos el AppDelegate y añadimos el siguiente código dentro del método didfinishlaunchingwithoptions: // (1) Iniciamos icloud NSURL *ubiq = [[NSFileManager defaultmanager] URLForUbiquityContainerIdentifier:@"3S952AGH46.ua.es.jtech.ejemploicloud"]; if (ubiq) { NSLog(@"AppDelegate: Entra en icloud!"); [self cargadocumento]; else { NSLog(@"AppDelegate: No hay acceso a icloud (puede que estés en el simulador o que no esté configurado correctamente el dispositivo"); El el fragmento de código anterior generamos la dirección del contenedor de icloud correspondiente al identificador de nuestra aplicación mediante el método 54

55 del singleton NSFileManager. En el caso que encuentre esa dirección de icloud pasamos a cargar el documento, en caso contrario significará o que no existe ese contenedor de icloud o que no podamos acceder a el por cualquier otro motivo (no disponemos de conexión a internet, estamos probando el proyecto sobre el simulador o que el dispositivo no esté bien configurado para aceptar icloud). URLForUbiquityContainerIdentifier Ahora creamos el método cargadocumento que será el encargado de hacer la llamada a icloud para comprobar que existe el fichero que queremos cargar, en nuestro caso será text.txt: - (void)cargadocumento { // (2) icloud query: Busca a ver si hay un fichero llamado "text.txt" en icloud. NSMetadataQuery *query = [[NSMetadataQuery alloc] init]; _query = query; //Asignamos el scope [query setsearchscopes:[nsarray arraywithobject: NSMetadataQueryUbiquitousDocumentsScope]]; //Creamos un predicado y lo asignamos a la query NSPredicate *pred = [NSPredicate == %@", [query setpredicate:pred]; //Creamos una notificacion que se llame cuando la query haya terminado // (esta se ejecutará en segundo plano de forma asincrona) [[NSNotificationCenter defaultcenter] addobserver:self selector:@selector(querydidfinishgathering:) name:nsmetadataquerydidfinishgatheringnotification object:query]; [query startquery]; - (void)querydidfinishgathering:(nsnotification *)notification { // (3) Si la query ha terminado cargaremos los resultados de esta en el // siguiente metodo: cargaquery NSMetadataQuery *query = [notification object]; [query disableupdates]; [query stopquery]; [self cargaquery:query]; [[NSNotificationCenter defaultcenter] removeobserver:self name:nsmetadataquerydidfinishgatheringnotification object:query]; _query = nil; // ya no lo necesitaremos mas Ahora nos falta implementar el método encargado de gestionar la consistencia del documento. Comprobaremos que si existe dicho documento (la query devuelve un resultado) lo cargaremos en el campo de texto de la vista (esta la crearemos en el 55

56 siguiente paso). En el caso de que la query no devuelva ningún resultado crearemos un nuevo documento y lo almacenaremos en icloud. Para hacer esto crearemos el siguiente método: - (void)cargaquery:(nsmetadataquery *)query { // (4) cargaquery: Si el fichero existe lo abrimos y se lo asignamos al documento //de la clase. En caso contrario lo creamos, lo asignamos al documento de la clase. if ([query resultcount] == 1) { // Encontrado el archivo en icloud NSMetadataItem *item = [query resultatindex:0]; NSURL *url = [item valueforattribute:nsmetadataitemurlkey]; MiDocumento *doc = [[MiDocumento alloc] initwithfileurl:url]; _documento = doc; [doc openwithcompletionhandler:^(bool success) { if (success) { NSLog(@"AppDelegate: Abriendo documento existente de icloud"); NSLog(@"El documento contiene el texto: %@", doc.documenttext); [[NSNotificationCenter defaultcenter] postnotificationname:@"cargatextoicloud" object:nil]; else { NSLog(@"AppDelegate: El documente existente en icloud ha fallado al abrirse"); ]; else { // No existe el documento en icloud: lo creamos NSLog(@"AppDelegate: Documento no encontrado en icloud"); NSURL *ubiq = [[NSFileManager defaultmanager] URLForUbiquityContainerIdentifier:@"639M4BK859.com.theclashsoft.icloudtest"]; NSURL *ubiquitouspackage = [[ubiq URLByAppendingPathComponent:@"Documents"] URLByAppendingPathComponent:@"text.txt"]; MiDocumento *doc = [[MiDocumento alloc] initwithfileurl:ubiquitouspackage]; doc.documenttext inicial del documento en icloud..."; _documento = doc; [doc savetourl:[doc fileurl] forsaveoperation:uidocumentsaveforcreating completionhandler:^(bool success) { NSLog(@"AppDelegate: new document save to icloud"); [doc openwithcompletionhandler:^(bool success) { NSLog(@"AppDelegate: Nuevo documento creado en icloud"); [[NSNotificationCenter defaultcenter] postnotificationname:@"cargatextoicloud" object:nil]; 56

57 ]; ]; Como podemos ver en el método anterior enviamos un mensaje a una notificación cargatextoicloud que aún no hemos definido, esta vamos a implementarla dentro de la vista ViewController: - (void)cargatextoicloud:(nsnotification *)notification { AppDelegate *delegate = [[UIApplication sharedapplication] delegate]; self.textview.text = delegate.documento.documenttext; Ahora, dentro del fichero ViewController.m, en el método viewdidload definimos la notificación que se usará para indicar que el fichero se ha cargado de icloud y se puede mostrar su texto en el componente UITextView: - (void)viewdidload { [super viewdidload]; // Do any additional setup after loading the view, typically from a nib. [[NSNotificationCenter defaultcenter] addobserver:self selector:@selector(cargatextoicloud:) name:@"cargatextoicloud" object:nil]; En el fichero ViewController.h deberemos de crear un Outlet para el Text View y un Action para la acción del botón que guardará el nuevo fichero en icloud. // Añadimos lo siguiente debajo de las (strong, nonatomic) IBOutlet UITextView *textview; -(IBAction)clickBoton:(id)sender; //Añadimos en textview = _textview; //Creamos el siguiente método en ViewController.m que implementará la acción del botón -(IBAction)clickBoton:(id)sender { AppDelegate *delegate = [[UIApplication sharedapplication] delegate]; [delegate escribeendocumento:self.textview.text]; Por último nos queda diseñar la vista, para ello abrimos el fichero ViewController_iPhone.xib y ViewController_iPad.xib y añadimos en ambos un componente Text View y un Button. Nos queda enlazarlos con los Outlet de la clase y 57

58 quedaría de la siguiente manera para iphone: ViewController_iPhone.xib Una vez hecho esto ya podemos ejecutar nuestra aplicación sin antes acordarnos de 58

59 establecer los provisioning profiles adecuados en la pestaña de summary del proyecto para poder arrancarla en nuestros dispositivos Desarrollando con icloud: Pruebas de funcionamiento de ficheros Las pruebas se deberian de hacer en varios dispositivos ejecutando la aplicación en estos para comprobar que icloud funciona correctamente. Deberemos de comprobar que el documento recién creado se actualiza de forma automática en nuestros dispositivos. También podemos comprobar que dentro de los ajustes de icloud del dispositivo aparece el fichero creado text.txt. La primera vez que arrancamos la aplicación nos debe de aparecer lo siguiente en la consola de XCode: :22: icloudtest[3733:707] AppDelegate: Entra en icloud! :22: icloudtest[3733:707] AppDelegate: Documento no encontrado en icloud :22: icloudtest[3733:707] UIDocument: Guardare el siguiente texto en icloud: Texto inicial del documento en icloud... [Switching to process 8195 thread 0x2003] :22: icloudtest[3733:707] AppDelegate: Nuevo documento creado en icloud :22: icloudtest[3733:707] UIDocument: loadfromcontents: state = 0, typename=public.plain-text :22: icloudtest[3733:707] UIDocument: Se ha cargado el siguiente texto desde icloud: Nueva nota para el curso especialista de moviles :22: icloudtest[3733:707] AppDelegate: Abriendo documento existente de icloud Como podemos ver, al arrancar la aplicación por primera vez no se encuentra ningún documento en icloud por lo que se crea uno y se muestra el contenido en el TextView. Si ahora borramos la aplicación del dispositivo y la volvemos a ejecutar deberá de encontrar el fichero de icloud y cargar su contenido en el Text View. Aparecerá algo similar a lo siguiente en la consola de XCode: :30: icloudtest[3766:707] :31: icloudtest[3766:707] state = 1, typename=public.plain-text :31: icloudtest[3766:707] siguiente texto desde icloud: Nueva nota para el curso [Switching to process 8451 thread 0x2103] :31: icloudtest[3766:707] documento existente de icloud AppDelegate: Entra en icloud! UIDocument: loadfromcontents: UIDocument: Se ha cargado el especialista de moviles AppDelegate: Abriendo 59

60 :31: icloudtest[3766:707] El documento contiene el texto: Nueva nota para el curso especialista de moviles Como podemos ver se ha cargado el documento generado desde icloud de manera correcta. Para modificar el texto del documento simplemente deberemos escribirlo dentro del Text View y pulsar sobre el botón Enviar a icloud, si hacemos la prueba escribiendo el siguiente texto: Cambiando el texto del documento text.txt en icloud... veremos que aparece lo siguiente en la consola: :34: icloudtest[3766:707] UIDocument: Guardare el siguiente texto en icloud: Cambiando el texto del documento text.txt en icloud :34: icloudtest[3766:707] AppDelegate: Nuevo documento creado en icloud :34: icloudtest[3766:707] UIDocument: loadfromcontents: state = 0, typename=public.plain-text :34: icloudtest[3766:707] UIDocument: Se ha cargado el siguiente texto desde icloud: Cambiando el texto del documento text.txt en icloud :34: icloudtest[3766:707] AppDelegate: Abriendo documento existente de icloud Ahora podemos seguir realizando pruebas en distintos dispositivos seguir observando el proceso que realiza icloud Desarrollando con icloud: Programación de clave-valor La implementación de icloud para su uso en el modo clave-valor es mucho más sencillo que para ficheros. Lo único que debemos hacer es modificar el código dentro de la inicialización de icloud del método didfinishlaunchingwithoptions de la clase AppDelegate: // Iniciamos icloud NSURL *ubiq = [[NSFileManager defaultmanager] if (ubiq) { NSLog(@"AppDelegate: icloud access!"); // inicio clave-valor NSUbiquitousKeyValueStore *cloudstore = [NSUbiquitousKeyValueStore defaultstore]; [cloudstore setstring:[ubiq absolutestring] forkey:@"icloudurl"]; [cloudstore synchronize]; // Sincroniza los datos locales con los de icloud NSLog(@"Valor encontrado en icloud: %@",[cloudstore stringforkey:@"icloudurl"]); // fin de clave-valor [self cargadocumento]; else { NSLog(@"AppDelegate: No icloud access (either you are using simulator or, if you are on your phone, you should check settings"); 60

61 Como podemos ver, el método clave-valor de icloud es muy similar usar NSUserDefaults para persistencia de datos dentro de un mismo dispositivo. En icloud se almacena un diccionario con todos los datos clave-valor que deseemos. En este caso únicamente almacenamos una clave llamada icloudurl que contendrá la dirección URL de almacenamiento de icloud. Este método es muy útil para almacenar propiedades, configuraciones, datos de usuario, etc en la nube y tener acceso de este modo en todos nuestros dispositivos de manera instantánea. Comentar que además de poder almacenar valores de tipo String se pueden almacenar de otros tipos como numéricos e incluso objetos completos Notificaciones push Las aplicaciones ios no pueden realizar (o no deben al menos) muchos de sus procesos en segundo plano por cuestiones de bateria. Sabiendo esto, cómo podemos hacer para avisar al usuario de que algo interesante está sucediendo? Por ejemplo, imaginemonos que un usuario se descarga una aplicación de una bliblioteca en un momento dado y un mes después sale un libro a la venta que le puede interesar... cómo podemos avisar a ese usuario que el libro x le puede interesar? Ahi es donde entran en acción las famosas notificaciones push. 61

62 Notificación Push Para evitar tener uno o varios procesos corriendo en nuestro dispositivo que estén comprobando cada cierto tiempo si algún evento aparece Apple ha creado las notificaciones push. Estas notificaciones necesitarán de una configuración en un servidor que correrá por nuestra cuenta y por muy poca programación en la aplicación. 62

63 Las notificaciones push pueden enviar los siguientes tipos de mensaje o una combinación de estos: Mensajes de texto cortos Reproducir un sonido Mostrar un número en el icono de la aplicación (badge) Podremos enviar por ejemplo un mensaje de texto junto con un sonido para conseguir una mayor atención del usuario. Las notificaciones push son un muy buen método para realizar campañas de marketing ya que podremos avisar a todos nuestros usuarios de algún evento o producto en cualquier momento y sin resultar ser demasiado intrusivos. Además todas las notificaciones que nuestros usuarios reciban tendrán la opción de ejecutar la aplicación en el caso de que esta se encuentre en segundo plano o cerrada. Conviene tener en cuenta que el uso desmesurado de notificaciones push por parte del desarrollador puede provocar el efecto contrario, que el usuario se borre la aplicación del dispositivo para dejar de recibir este tipo de avisos Funcionamiento Como hemos comentado anteriormente, el uso de notificaciones push en nuestras aplicaciones implica que tengamos que configurar un servidor que sea el que envie estas notificaciones mediante mensajes con formato JSON al servidor de notificaciones de Apple (APNS Server). Este servidor de Apple será el que envie la notificación al dispositivo del usuario. En el siguiente gráfico podemos ver cómo funciona el servicio de notificaciones push de una manera más clara: 63

64 Esquema funcionamiento push 1. Registramos el ID del dispositivo en nuestro servidor. Al usuario le aparecerá una ventana de confirmación preguntando si desea que nuestra aplicación le pueda enviar notificaciones. 2. Nuestro servidor almacenará el ID del dispositivo en una base de datos para posteriormente usarlo para enviar notificaciones. 3. Enviamos una notificación desde nuestro servidor al APNS (Servidor de Apple). Necesitaremos haber configurado previamente un certificado SSL junto con una clave privada. La notificación será un mensaje con estructura JSON. 4. El APNS enviará la notificación al usuario del dispositivo. Cuando el usuario recibe la notificación se mostrará una alerta, desde la cual podrá abrir la aplicación (importante tener en cuenta para temas de marketing). Las notificaciones push se mostrarán al usuario aunque la aplicación esté apagada o incluso el dispositivo en reposo. Qué necesitaremos para poder implementar este sistema en mis aplicaciones? Necesitaremos lo siguiente: Un dispositivo (iphone o ipad). Las notificaciones push en el simulador de XCode no funcionan. Una cuenta activa de desarrollador Apple. Necesitaremos crear un App ID en el portal de Apple Developer y configurar las notificaciones push para este App ID. También tendremos que generar un certificado SSL especial. 64

65 Un servidor conectado a Internet. Será en encargado de enviar las notificaciones push al servidor de Apple (APNS). Problema: el servidor tendrá que ser capaz de ejecutar procesos en segundo plano, instalar certificados SSL y hacer conexiones TLS a ciertos puertos, por lo que necesitaremos contratar un servidor privado (VPS) o buscar soluciones alternativas de pago. El tercer requerimiento es algo complicado de solucionar ya que necesitaríamos contratar un servidor privado virtual o, en cualquier caso, implementarlo nosotros configurando una serie de procesos, instalar un certificado, etc. Para simplificar este punto vamos a usar un servicio online complementario el cual nos proporcionará todo lo necesario para incoporar notificaciones push a nuestras aplicaciones sin preocuparnos por el servidor: Urban Airship ( Urban Airship es un sitio online para desarrolladores de plataformas móviles (ios, Android, Blackberry, etc) que ofrece distintos servicios para estas plataformas entre los que se encuentran el de notificaciones push e in-apps entre otros. El servicio de notificaciones push es bastante bueno y funciona muy bien. Empresas como Fox, Accenture, Macworld, Tapulous, Warner Bros o Yahoo lo utilizan en sus aplicaciones. Urban Airship Urban Airship ofrece distintas tarifas según nuestras necesidades. Por suerte disponen de una tarifa gratuita con limitaciones, nosotros escogeremos esa tarifa para realizar una aplicación de ejemplo Registro en Urban Airship y configuración en ios Provisioning Portal Antes de empezar a implementar nuestra aplicación de ejemplo vamos a registrarnos en el 65

66 site de Urban Airship, para ello abrimos un navegador y entramos en Una vez dentro deberemos rellenar todos los campos del formulario para abrir una cuenta básica (gratuita) la cual nos permitirá enviar hasta un millón de mensajes push al mes (después veremos algunas limitaciones). Una vez que nos hayamos registrado y confirmado la cuenta podremos acceder al panel de control desde donde podremos revisar todos los datos de nuestra cuenta, el tipo de cuenta (básica), el número de mensajes push enviados en total, etc. Ahora deberemos crear una nueva app, pero antes tendremos que generar el certificado SSL de Apple que permitirá a Urban Airship enviar las notificaciones push a los dispositivos. Datos app en Urban Airship Para crear el certificado SSL de Apple accederemos al portal de desarrolladores usando nuestro nombre de usuario y contraseña. ( Una vez dentro abrimos la pestaña de Apps IDs y crearemos una nueva App ID para la aplicación de ejemplo que vamos a desarrollar. Completaremos el formulario con los datos que se muestran en la siguiente captura: 66

67 Create App ID Una vez creado el App ID lo configuramos para activar las notificaciones push, para ello pulsamos sobre el link de "configure" y marcamos la casilla Enable for Apple Push Notification service tal y como se muestra a continuación: Configuración para push Ahora pulsamos sobre el botón que pone Configure en el certificado SSL de desarrollo (Development Push SSL Certificate). Al pulsar sobre el botón nos aparecerá un 67

68 asistente que tenemos que seguir para generar el certificado, el cual después utilizaremos para el servidor, o en nuestro caso, Urban Airship. Por tanto simplemente seguimos los pasos que nos indica el asistente... Certificado SSL Una vez que nos hayamos descargado el certificado SSL generado en el asistente (aps_development.cer) lo agregamos a nuestro llavero simplemente pulsando sobre el. Una vez hecho esto ya podemos "subirlo" a la cuenta de Urban Airship, pero primero tenemos que crear una app, para ello debemos de pulsar sobre Select an application > Create an app. Una vez dentro rellenamos todo el formulario adjuntando la exportación del certificado de Apple Developer ios Push Services: es.ua.jtech.ejemplopush desde la aplicación de llaveros del Mac (este fichero debe de tener extensión p12). 68

69 Certificado SSL en el llavero del Mac Completamos el formulario de nueva aplicación: Configuración push en Urban Airship Ya tenemos la aplicación creada en los servidores de Urban Airship!. Sin cerrar el panel de control de Urban Airship podemos empezar a programar lo que es el código de las notificaciones push en nuestra aplicación de ejemplo. 69

70 Notificaciones push en Urban Airship Programación de la aplicación de ejemplo En los puntos anteriores hemos realizado toda la preparación necesaria tanto en el portal de desarrolladores de Apple como en el sitio Urban Airship (nuestro servidor) para la implementación de las notificaciones push. Ahora vamos a programar una aplicación muy 70

71 sencilla que reciba las notificaciones que enviamos desde el servidor de Urban Airship. Vamos a por ello! Nota Las notificaciones push sólo funcionarán en dispositivos reales (iphone o ipad), no en el simulador de XCode. Comenzamos creando una nueva aplicación en XCode usando la plantilla Single View Application. Los datos de la aplicación serán los siguientes: Product name: ejemplopush Company Identifier: es.ua.jtech Class prefix: UA Device family: iphone Seleccionar sólo "Use Automatic Reference Counting", el resto de opciones las dejamos desmarcadas. Atención El valor del campo Product Name debe de ser exactamente igual que el "appname" del Bundle Identifier que hemos especificado en al crear el App ID en el ios Provisioning Portal. Modificamos la vista principal UAViewController.xib añadiéndole un fondo y un Label. Una vez hecho esto vamos a abrir el fichero UAAppDelegate.m y añadiremos el siguiente código al principio del método didfinishlaunchingwithoptions: [[UIApplication sharedapplication] registerforremotenotificationtypes:(uiremotenotificationtypebadge UIRemoteNotificationTypeSound UIRemoteNotificationTypeAlert)]; Mediante el código anterior estamos indicando al dispositivo que queremos registrarlo en los servidores de Apple para que permita recibir notificaciones push de los tres tipos (un número en el icono de la app, un sonido o un texto de alerta). Si el usuario acepta podremos obtener un token de su dispositivo el cual utilizaremos para enviarle las notificaciones push, por tanto ese token deberemos de almacenarlo en algún sitio: base de datos de nuestro servidor o en nuestro caso, en Urban Airship. El código para obtener el token del dispositivo deberemos de escribirlo dentro del método didregisterforremotenotificationswithdevicetokendel protocolo de UIApplication: - (void)application:(uiapplication *)application didregisterforremotenotificationswithdevicetoken:(nsdata *)devicetoken { NSString *devicetokenstr = [[[[devicetoken description] 71

72 " devicetokenstr); // Este token deberemos de enviarlo a nuestro servidor o a Urban Airship usando su // API... Esto es lo único que deberemos de programar para que nuestra aplicación reciba notificaciones push. Ahora podemos probarlo para comprobar que funciona correctamente, para ello seguiremos los siguientes pasos: Nota Deberemos tener configurado un perfil adecuado asociado al certificado de push que hemos generado. Deberemos de compilar nuestra aplicación en el dispositivo usando este perfil, si no, no aperecerán las notificaciones push. 1. Arrancamos la aplicación y nos aparecerá una alerta preguntando si aceptamos recibir notificaciones. Aceptamos. Confirmación recepción de notificaciones push 72

73 2. Una vez que hemos aceptado recibir notifiaciones push nos aparecerá el token del dispositivo en la consola. Lo copiamos en el portapapeles porque lo necesitaremos para el siguiente paso. Token del dispositivo 3. Ahora vamos a crear una notificación push y a enviarla desde el panel de control de Urban Airship. Para ello accedemos al panel de control, entramos en nuestra aplicación de ejemplo y seleccionamos desde el menu de la izquierda Push > Test Push Notifications. Completamos el formulario con los siguientes datos y pulsamos en "Send it!": Crear notificación en Urban Airship Funciona! En aproximadamente un segundo nos aparecerá la notificación push en la pantalla del dispositivo. 73

74 Con esto ya tenemos el funcionamiento básico de las notificaciones push haciendo uso de un servidor de pago como Urban Airship. Este servidor además ofrece una API que nos permite acceder a todos sus servicios desde otra plataforma como podría ser un servidor propio en PHP, lo cual facilita mucho el trabajo. Es conveniente leerse la documentación de Urban Airship ( la cual nos aclará muchas dudas y nos proporcionará nuevas ideas y mejoras de funcionamiento en nuestra aplicación. 74

75 4. icloud y notifications push - Ejercicios 4.1. Compartiendo datos en la nube: icloud (1.5 puntos) Para realizar este ejercicio debemos usar la hoja de respuestas con el nombre RespuestasSesion2.rtf. icloud es un servicio relativamente nuevo creado por Apple con el que podremos compartir documentos, bases de datos, cadenas de texto, etc. en la nube de una forma totalmente transparente para el usuario que se descarga nuestra aplicación. Contesta a las siguientes preguntas sobre icloud: a) Qué aporta icloud de cara a un usuario de una aplicación ios? b) Cuál es el límite de almacenamiento (en GB) para una cuenta gratuita de icloud? c) De qué dos formas podemos usar icloud en nuestras aplicaciones? d) Necesitaremos una cuenta de desarrollador para configurar icloud? e) En dónde configuraremos la aplicación para que esta soporte icloud? 4.2. Notificaciones push (1.5 puntos) Para realizar este ejercicio debemos continuar usando la hoja de respuestas con el nombre RespuestasSesion2.rtf. En esta sesión hemos estudiado en profundidad el uso de las notificaciones push en aplicaciones ios. Contesta brevemente a las siguientes cuestiones: a) Podrías explicar con tus palabras qué son las notificaciones push y cuál es el proceso que se sigue desde que el usuario acepta recibir las notificaciones hasta que las recibe en su dispositivo? b) Qué ventajas o desventajas crees que puede tener el uso de las notificaciones push para su uso en campañas de marketing? Podrías comentar brevemente un ejemplo de una aplicación en donde podríamos usarlas? 75

76 5. Background e hilos En alguna ocasión tendremos que ejecutar ciertos procesos de forma paralela en nuestras aplicaciones, a esto lo llamamos concurrencia y lo haremos mediante el uso de hilos o threads. La implementación de hilos en aplicaciones para móviles es muy común ya que nos permite continuar con la ejecución mientras realizamos varios procesos de forma simultánea, por ejemplo la carga de imágenes desde un servidor. Estos hilos se pueden ejecutar en segundo plano o background. Las aplicaciones ios arrancarán con un único hilo de ejecución (main) y nosotros, mediante código, podremos crear y eliminar hilos según decidamos. Siempre tendremos que tener presente que los hilos que creemos debemos de cerrarlos en algún momento durante la ejecución, sino estos permanecerán ejecutándose y pueden incrementar la carga de procesamiento, CPU, del dispositivo Gestión de hilos en ios La implementación de hilos siempre ha sido una tarea complicada en el desarrollo software ya que implica poseer conceptos complejos a muy bajo nivel de programación. Gracias al SDK de ios esta tarea se simplifica bastante y sólo tendremos que "preocuparnos" de un par de clases: NSThread y NSOperation. Mediante el uso de NSThread gestionaremos los hilos a un nivel algo más bajo que con NSOperation. El la mayoría de casos nos sobraría con utilizar esta última Creando un hilo En este apartado aprenderemos como crear un hilo de ejecución usando las clases NSOperationQueue y NSInvocationOperation. El proceso que debemos de seguir para creación de un hilo es el siguiente: Instanciamos un objeto de la clase NSOperationQueue Instanciamos un objeto de la clase NSInvocationOperation indicando un selector (método que se ejecutará en el hilo) y un parámetro del método. Añadimos la operación (objeto de la clase NSInvocationOperation) a la cola que hemos definido en el primer paso. La implementación quedaría como sigue: NSOperationQueue *queue = [[NSOperationQueue alloc] init]; NSInvocationOperation *operation = [[NSInvocationOperation alloc] initwithtarget:self selector:@selector(metodoenhilo:) object:objecttopasstomethod]; [queue addoperation:operation]; 76

77 La clase NSOperationQueue es la encargada de ejecutar las operaciones que le indiquemos. Esta actúa como una cola de operaciones y puede realizar más de una operación de forma concurrente. El número de operaciones concurrentes que deseamos que se realicen se indica con el parámetro maxconcurrentoperationcount. Si indicamos que sólo realice una operación concurrente la clase NSOperationQueue actuará como un servicio de cola estricto, es decir, sólo se ejecutará un proceso si el anterior ha finalizado. Por defecto, el máximo número de operaciones concurrentes está definido en el máximo permitido y lo gestionará el sistema. La clase NSInvocationOperation es una subclase de NSOperation y es la encargada de gestionar una tarea en concreto, un método. Existe otra subclase de NSOperation que está diseñada para ejecutar bloques o blocks. Los blocks en Objective-C son porciones de código similares a funciones o métodos que realizan alguna tarea determinada. Son muy útiles a la hora de implementar callbacks, es decir, código después de la ejecución de alguna tarea asíncrona como por ejemplo llamadas a un servicio web. En el siguiente apartado vamos a realizar un ejemplo concreto que implemente el uso de hilos en una aplicación ios Ejemplo: Carga de datos usando hilos Con el fin de consolidar los conceptos estudiados sobre el uso de hilos en Objective-C vamos a realizar un pequeño ejemplo en el que cargaremos el código html de una serie de páginas web de forma asíncrona y lo mostraremos por consola. Después de crear un proyecto en XCode usando la plantilla Single View Application abrimos el fichero de la vista principal, en nuestro caso es UAViewController.m. Ahí vamos a rellenar un array con un listado de al menos diez sitios web que más adelante cargaremos de forma asíncrona usando hilos. Primero implementamos el método encargado de cargar una página web, obtener todo su código html y mostrarlo por consola: -(void) obtienehtmlsitioweb:(nsstring *)url { NSString *webpagestring = [NSString stringwithcontentsofurl:[nsurl URLWithString:url] encoding:nsutf8stringencoding error:nil]; NSLog(@"HTML WEB: %@", url); NSLog(@"%@", webpagestring); Ahora en el método viewdidload rellenamos un array con las url de los sitios web: 77

78 // Rellenamos un array de sitios web de prueba NSMutableArray *arraysitiosweb = [[NSMutableArray alloc] init]; [arraysitiosweb addobject:@" [arraysitiosweb addobject:@" [arraysitiosweb addobject:@" [arraysitiosweb addobject:@" [arraysitiosweb addobject:@" [arraysitiosweb addobject:@" [arraysitiosweb addobject:@" [arraysitiosweb addobject:@" [arraysitiosweb addobject:@" [arraysitiosweb addobject:@" Por último tenemos que implementar el sistema de hilos y colas estudiado en el apartado anterior. Esto lo realizaremos al final del método viewdidload tal y como se puede ver en el fragmento de código siguiente: // Creamos una cola NSOperationQueue *queue = [[NSOperationQueue alloc] init]; // Recorremos el array creando una operación para cada item y añadiendolo a la cola for (NSString *sitioweb in arraysitiosweb) { // Creamos una operacion para cargar la web NSInvocationOperation *operation = [[NSInvocationOperation alloc] initwithtarget:self selector:@selector(obtienehtmlsitioweb:) object:sitioweb]; // Añadimos la operacion a la cola [queue addoperation:operation]; Con esto ya tenemos implementado nuestro sistema de hilos concurrentes. Si ejecutamos la aplicación veremos que aparecerán por consola, y de una forma desordenada, las cargas de las páginas web (código html) sin bloquear la interfaz de usuario. Bloqueo de interfaz Para comprobar que la interfaz no se bloquea durante la carga de los sitios web podemos incluir una vista de tabla (TableView) en la vista principal. Si podemos hacer scroll en la tabla mientras se están cargando las páginas web significa que estamos usando los hilos de forma correcta Ejecución de métodos entre distintos hilos En el apartado anterior hemos estudiado como crear hilos y ejecutarlos de forma que no bloqueen la interfaz principal. Este bloqueo lo evitamos porque mantenemos en todo momento, precisamente mediante el uso de hilos, la ejecución principal (hilo principal) 78

79 libre de carga. Si queremos devolver un resultado desde un hilo secundario al hilo principal podemos usar el método de la clase NSObject: performselectoronmainthread:(sel)aselector withobject:(id)arg waituntildone:(bool)wait, por ejemplo: // Después de realizar una carga de datos para mostrar en una tabla // recargamos la tabla [self.tableview withobject:nil waituntildone:yes]; Además del método anterior existen otros también bastante útiles que podemos encontrar en la documentación oficial de Apple Modo background El modo background o multitarea fue introducido por Apple a partir de la versión 4.0 de ios. Gracias a el podemos ejecutar ciertos procesos una vez que la aplicación se encuentre en segundo plano. En este apartado estudiaremos más detenidamente cómo funciona el modo background en ios, así como la forma en la que podemos hacer uso de el en nuestras aplicaciones y sus restricciones Estados de ejecución en ios A la hora de desarrollar para ios debemos de conocer los diferentes estados de ejecución que puede adoptar nuestra aplicación. Concretamente, tendremos que controlar si la aplicación está funcionando en un momento dado en segundo plano (background) o en primer plano (foreground). Si la aplicación se encuentra activa en primer plano, esta será capaz de gestionar todas las interacciones con la interfaz de usuario, todos los controles UIKit así como el resto de procesos que implementemos. Por otro lado, si la aplicación se encuentra en segundo plano, la mayoría de procesos dejarán de ejecutarse (controles UIKit, procesos internos...) y tendremos que definir cuales queremos que continuen ejecutándose y por cuanto tiempo. Debemos de tener en cuenta que la ejecución de procesos en segundo plano tiene una serie de limitaciones que analizaremos más adelante. En el gráfico siguiente podemos ver claramente el flujo de los diferentes estados por los que pasa una aplicación ios desde que empieza a ejecutarse hasta que se detiene: 79

80 Estados de ejecución en ios Como desarrolladores tendremos que tener muy en cuenta los estados de background y de foreground y gestionarlos correctamente desde nuestro código Detectando si nuestra aplicación entra en background o foreground Como se ha comentado anteriormente es importante que gestionemos en nuestras aplicaciones los procesos que se van a ejecutar (si es que se ejecuta alguno) en modo background o segundo plano. Detectar si la ejecución entra en background es muy sencillo gracias a los métodos del protocolo UIApplicationDelegate, los cuales se definen en la clase delegada AppDelegate. Para detectar la entrada en background debemos de implementar el siguiente método: - (void)applicationdidenterbackground:(uiapplication *)application { // TODO Si por otro lado queremos detectar la entrada en foreground (primer plano) debemos de implementar este otro método: - (void)applicationwillenterforeground:(uiapplication *)application { // TODO Estos dos métodos son los que deberemos completar si nuestra aplicación lo requiere. En los apartados siguientes estudiaremos como ejecutar procesos en background y cuales de ellos podemos ejecutarlos de manera indefinida Ejecutando procesos con tiempo determinado en background Las aplicaciones pueden ejecutar (o seguir ejecutando) ciertos procesos durante un tiempo muy limitado cuando estos entran en background. Esto se debe de usar para tareas "importantes" y que necesitan algo más de tiempo para finalizar su ejecución, como por 80

81 ejemplo procesos de descargas de datos que no se pueden interrumpir. Para solicitar un tiempo "extra" de ejecución en background haremos uso del método beginbackgroundtaskwithexpirationhandler: perteneciente a la clase UIApplication. Mediante el uso del método beginbackgroundtaskwithexpirationhandler: conseguimos algo más de tiempo antes de que la aplicación entre en suspensión (modo no activo). El tiempo extra que se consigue no es siempre el mismo y depende de la carga de procesos que se estén ejecutando en ese momento en el dispositivo. Aproximadamente el sistema ios admite como máximo 10 minutos de ejecución de procesos determinados en background. A continuación podemos ver la estructura básica del método applicationdidenterbackground: que ejecuta uno o varios procesos determinados en background: - (void)applicationdidenterbackground:(uiapplication *)application { bgtask = [application beginbackgroundtaskwithexpirationhandler:^{ // Terminamos de forma definitiva los procesos pendientes [application endbackgroundtask:bgtask]; bgtask = UIBackgroundTaskInvalid; ]; // Implementamos las tareas determinadas dispatch_async(dispatch_get_global_queue(dispatch_queue_priority_default, 0), ^{ // Realizamos las tareas background [application endbackgroundtask:bgtask]; bgtask = UIBackgroundTaskInvalid; ); Ejecutando procesos con tiempo indeterminado en background Apple permite ejecutar ciertos procesos en segundo plano de forma ilimitada. Estos procesos son los siguientes: Audio: Reproducción de sonidos, música, sistema Airplay... Ej.: Apps de música, Apps que ofrezcan video en background a través de Airplay, etc... Servicios de localización: obtención de datos de la posición actual del usuario. Framework CoreLocation. Voz ip: realizar llamadas voip en background Contenido del newsstand: si la app es de tipo newsstand se permite la descarga de contenidos en background Accesorios externos: se permite la comunicación con hardware externo usando el framework ExternalAccesory Comunicación entre disposivos bluetooth: envio de mensajes entre dispositivos con 81

82 bluetooth usando el framework CoreBluetooth Si necesitamos que nuestra aplicación pueda ejecutar alguno de los procesos anteriores deberemos de indicarlo en el fichero Info.plist del proyecto mediante la clave UIBackgroundModes e indicando como valor un array con al menos un valor de entre los siguientes: audio, location, voip, newsstand-content, external-accessory, bluetooth-central, bluetooth-peripheral. En el caso de que implementemos alguna de las funciones anteriores pero no lo indiquemos en el fichero Info.plist, el proceso automáticamente se detendrá cuando esta pase a segundo plano Notificaciones locales Las notificaciones locales sirven para captar la atención del usuario de nuestra aplicación cuando esta se encuentra en modo background o incluso cerrada. A diferencia de las notificaciones push, estas no se crean ni se lanzan desde servidores externos. Las notificaciones locales se crean desde nuestra propia aplicación y se pueden programar para que aparezcan en una fecha concreta. Estas notificaciones pueden aparecer en forma de texto, sonido, badge en el icono de la aplicación o una combinación de las tres. Podemos usar las notificaciones locales para avisar al usuario de que es la hora de levantarse para ir al trabajo, usándolas como alarmas, por ejemplo. Otro ejemplo de uso muy extendido es en el ámbito de los juegos, usadas para avisar al usuario de ciertas acciones del juego o simplemente para recordarle que tiene que volver a jugar... Notificación local Es importante recordar que no se debe de abusar de las notificaciones (tampoco de las notificaciones push), ya que esto provocaría el efecto opuesto que queremos al usuario. Para implementar las notificaciones locales en nuestras aplicaciones ios tendremos que usar la clase UILocalNotification. Un ejemplo sencillo de su uso podría ser el 82

83 siguiente: UIApplication* app = [UIApplication sharedapplication]; UILocalNotification* alarm = [[UILocalNotification alloc] init]; if (alarm) { alarm.firedate = fechanotificacion; alarm.timezone = [NSTimeZone defaulttimezone]; alarm.soundname alarm.alertbody de despertarse!"; [app schedulelocalnotification:alarm]; En el código anterior creamos una instancia de la clase UILocalNotification y la configuramos a nuestro gusto para que se ejecute en una fecha determinada (objeto de la clase NSDate) según un calendario por defecto (el del propio dispositivo). También estamos indicando que cuando esta se ejecute active un sonido determinado (este sonido debe de estar en el bundle de nuestra aplicación) y muestre un mensaje determinado. La notificación local aparecerá automáticamente en la fecha indicada. Si queremos cancelar alguna o todas las notificaciones que nuestra aplicación tiene programadas debemos de hacer uso del método cancelalllocalnotifications de la clase UIApplication tal y como se puede ver en el código siguiente: UIApplication* app = [UIApplication sharedapplication]; NSArray *notificacionesprogramadas = [app scheduledlocalnotifications]; // Cancelo todas las notificaciones programadas if ([notificacionesprogramadas count] > 0) [app cancelalllocalnotifications]; Si se recibe una notifiación local cuando la aplicación está en un estado activo de foreground, se ejecutará el método application:didreceivelocalnotification: de la clase AppDelegate Limitaciones y recomendaciones La ejecución en background es extremadamente útil para muchos casos, incluso se puede decir que es muchas veces imprescindible. En la App Store existen en la actualidad una gran cantidad de aplicaciones que hacen uso de esta funcionalidad. Para su correcto funcionamiento Apple ha publicado una serie de recomendaciones que debemos de tener en cuenta a la hora de implementar estas funcionalidades: No hacer llamadas OpenGL desde código. A tener en cuenta sobre todo en el desarrollo de juegos. Cancelar cualquier servicio relacionado con Bonjour. Cerrar sockets abiertos, etc. Implementar código para contemplar posibles fallos de conexión relacionados con internet en background. 83

84 Guardar el estado de la aplicación justo antes de entrar en modo background. Eliminar referencias strong, retain antes de entrar en modo background. Especiamente imagenes que se mantienen en caché. No se deben de usar servicios como la Agenda o calendarios en background. No se deben de actualizar vistas ya que estas no se ven en modo background. Responder a la conexión o desconexión de dispositivos externos en background, si nuestra aplicación los usa. No mostrar ventanas de alerta (Alert View, Action Sheet) cuando la aplicación esté en background. Eliminar de la vista información sensible (contraseñas, nombres de usuario, etc...) antes de entrar en background ya que el sistema realiza una captura del estado de la aplicación justo antes de entrar a background y toda esta información se almacenaría sin nuestro permiso en el dispositivo. Hacer el mínimo trabajo de procesamiento mientras la aplicación se encuentre en background. Sólo realizar el trabajo imprescindible. Teniendo en cuenta estas recomendaciones y haciendo un uso moderado del modo background se comportará bien nuestra aplicación y no se consumirán recursos innecesarios del sistema. 84

85 6. Background e hilos - Ejercicios 6.1. Usando los hilos (1 punto) Para realizar el ejercicio debemos usar la plantilla con el nombre EjercicioHilos. En este primer ejercicio vamos a probar el uso de hilos y colas de ejecución usando las clases NSOperationQueue y NSInvocationOperation que hemos estudiado en la primera parte de la sesión. El ejercicio consiste en completar el código de una aplicación que realiza un número de operaciones en segundo plano que duran un tiempo determinado. a) Definir una cola usando la clase NSOperationQueue. b) Definir una operación para cada iteración del bucle que ejecute el método tareaquetardaenejecutarse: en segundo plano y enviando como parámetro un objeto diccionario (NSDictionary) que contenga el número de tarea (tipo NSNumber) con la clave numtarea (tipo NSString) y el número de segundos que tarda en realizarse (tipo NSNumber) con clave segundos (tipo NSString). c) Añadir la operación a la cola usando el método addoperation: de la clase NSOperationQueue d) Comprobamos que las operaciones se van ejecutando en segundo plano y no bloquean la interfaz de usuario Entrando en segundo plano y en primer plano (0.5 puntos) Para realizar este ejercicio debemos usar la plantilla con el nombre SegundoPlano. El objetivo de este ejercicio es identificar qué métodos de la clase AppDelegate se ejecutan cuando una aplicación entra en modo background o segundo plano y en modo foreground o primer plano. Cuando la aplicación entra en segundo plano deberemos de mostrar por el log de la consola: "La aplicación ha entrado en segundo plano", y cuando esta esté de nuevo activa debemos de mostrar "La aplicación ya está activa" Programando una alarma con Notificaciones locales (1.5 puntos) Para realizar este ejercicio debemos usar la plantilla con el nombre AlarmaJtech. En este ejercicio terminaremos de implementar una aplicación con la que podremos programar una alarma para que suene dentro del tiempo (en segundos) que indiquemos. También podremos especificar un texto para el mensaje de la alarma y tendremos una opción de cancelar todas las alarmas programadas. Todo esto lo implementaremos usando las notificaciones locales estudiadas en la sesión. a) Terminar de implementar el método tapbutton: con el código necesario para 85

86 crear una notificación local con los parámetros necesarios. b) Implementar el método tapcancelaralarmas: con el código necesario para cancelar todas las notificaciones locales que están pendientes. Nota La fecha en la que debe de aparecer la notificación se debe de crear sumándole los segundos indicados a la fecha actual. Esto lo hacemos usando los métodos de la clase NSDate y sería de la siguiente forma: [[NSDate date] datebyaddingtimeinterval:segundosparasonar]; 86

87 7. Acceso a la agenda 7.1. Introducción La agenda es un servicio disponible en ios mediante el cual el usuario de un dispositivo puede almacenar de una manera centralizada toda la información de sus contactos. Cada contacto puede contener sus datos personales (nombre y apellidos), una o varias direcciones postales, uno o varios teléfonos, una o varias direcciones de , información adicional de redes sociales, etc. El SDK de ios nos ofrece una API bastante completa con la que podremos acceder a todos los datos de los contactos, tanto en modo lectura como escritura, por lo que tendremos acceso a realizar modificaciones. A lo largo de esta sesión aprenderemos como acceder a la agenda del usuario desde nuestras aplicaciones. Estudiaremos los distintos frameworks que disponemos para programar esto así como distintas funcionalidades que podemos ofrecer implementando este servicio. La Agenda en ios 7.2. Posibles usos El servicio de la agenda de contactos nos proporciona una variedad bastante interesante sobre posibles usos que podemos ofrecer en una aplicación. Entre los usos más destacados está el de ofrecer al usuario de nuestra aplicación la posibilidad de acceder a sus agenda para obtener unos datos concretos de un contacto y usar estos datos en la aplicación. Otra posible utilidad sería la de mostrar en un mapa mediante marcadores las direcciones postales de los contactos que seleccione el usuario y de esta forma visualizar de una manera más atractiva donde viven esos contactos. Existen muchos más usos de la agenda como por ejemplo dar la posibilidad, en una aplicación de gestión, de modificar los datos de un contacto determinado. 87

88 7.3. Implementando el acceso a la agenda El SDK de ios ofrece un conjunto de librerías y frameworks que podemos usar para implementar los servicios de la agenda: Framework de la agenda: proporciona acceso a la información de los contactos. Framework de la interfaz de la agenda: proporciona la interfaz de usuario para mostrar la información de contactos Base de datos de la agenda: en donde se almacena toda la información Aplicación Agenda: ofrece una interfaz intuitiva para el acceso a datos de la agenda. Esta aplicación viene incluida con ios. Pantallas de la Agenda Pantallas de la Agenda Obteniendo datos de la agenda Para obtener datos de la agenda podemos hacer uso del framework Address Book UI el cual nos proporciona tres controladoras muy útiles que nos facilitarán el acceso a los datos. Para acceder al listado de contactos de la agenda del usuario mediante este framework deberemos de usar la controladora ABPeoplePickerNavigationController. Si queremos mostrar los datos de un contacto al igual que hace la aplicación de contactos nativa de ios deberemos usar la controladora ABPersonViewController. Si por otro lado nuestra intención es que el usuario introduzca datos de un contacto determinado podemos usar la controladora diseñada para ello: ABNewPersonViewController. En este apartado estudiarmos como hacer uso de la primera controladora comentada: ABPeoplePickerNavigationController. Implementarla y obtener los datos del contacto que el usuario seleccione. Para mostrar todos los contactos del usuario del dispositivo y que este pueda seleccionar 88

89 uno para luego obtener sus datos debemos de programarlo de la siguiente manera: ABPeoplePickerNavigationController *picker = [[ABPeoplePickerNavigationController alloc] init]; picker.peoplepickerdelegate = self; [self presentviewcontroller:picker animated:yes completion:nil]; En el código anterior instanciamos un objeto de la clase ABPeoplePickerNavigationController, indicamos que la controladora actual implementará los métodos del protocolo ABPeoplePickerNavigationControllerDelegate y por último mostramos la vista en forma modal. Pantalla de selección de contacto Para obtener los datos del contacto que el usuario seleccione en la vista anterior deberemos de implementar algunos métodos del protocolo ABPeoplePickerNavigationControllerDelegate y, obviamente, deberemos de indicar que la controladora actual implementa dicho protocolo. Los métodos que tenemos que implementar son los siguientes: #pragma mark - ABPicker Delegate (void)peoplepickernavigationcontrollerdidcancel:(abpeoplepickernavigationcontroller *)peoplepicker { [self dismissviewcontrolleranimated:yes completion:nil]; - (BOOL)peoplePickerNavigationController: (ABPeoplePickerNavigationController *)peoplepicker shouldcontinueafterselectingperson:(abrecordref)person { 89

90 //TODO: Obtener los datos que deseemos del contacto (person) [self dismissviewcontrolleranimated:yes completion:nil]; return NO; - (BOOL)peoplePickerNavigationController: (ABPeoplePickerNavigationController *)peoplepicker shouldcontinueafterselectingperson:(abrecordref)person property:(abpropertyid)property identifier:(abmultivalueidentifier)identifier { return NO; Mediante el uso de los tres métodos implementados podemos gestionar la obtención de datos de la agenda del usuario. El segundo método peoplepickernavigationcontroller:shouldcontinueafterselectingperson: es el más importante ya que mediante el obtenemos los datos del contacto seleccionado por el usuario (variable person del tipo ABRecordRef). El tipo ABRecordRef contiene todos los atributos de un contacto (nombre, apellidos, direcciones postales, teléfonos, datos de redes sociales, etc...). Para acceder a esos atributos deberemos de usar uno de los métodos disponibles: ABRecordGetRecordID: devuelve el identificador del contacto (record) ABRecordCopyValue: devuelve un atributo en concreto. El tipo devuelto puede ser un string o un array (si es un atributo multivalor como telefonos o direcciones). A continuación podemos ver un ejemplo anteriormente descrito: sencillo del uso del método ABRecordCopyValue() // Obtenemos el nombre del contacto NSString* name = ( bridge_transfer NSString*) ABRecordCopyValue(person, kabpersonfirstnameproperty); self.nametextfield.text = name; //************************************************* // Obtenemos los teléfonos del contacto NSString* phone = nil; ABMultiValueRef phonenumbers = ABRecordCopyValue(person, kabpersonphoneproperty); if (ABMultiValueGetCount(phoneNumbers) > 0) { phone = ( bridge_transfer NSString*) ABMultiValueCopyValueAtIndex(phoneNumbers, 0); else { phone self.phonenumber.text = phone; CFRelease(phoneNumbers); //************************************************* // Obtenemos las direcciones postales del contacto NSDictionary* address = nil; ABMultiValueRef addresses = ABRecordCopyValue(person, 90

91 kabpersonaddressproperty); if (ABMultiValueGetCount(addresses) > 0) { address = ( bridge_transfer NSDictionary*) ABMultiValueCopyValueAtIndex(addresses, 0); else { address = nil; self.address.text = [address description]; CFRelease(addresses); Como podemos ver en el fragmento de código anterior los atributos del tipo ABRecordRef los obtenemos mediante el método ABRecordCopyValue la cual recibe como parámetros el objeto de tipo ABRecordRef y el tipo de atributo que queremos obtener, en este caso: kabpersonfirstnameproperty para el nombre, kabpersonphoneproperty para los teléfonos y kabpersonaddressproperty para las direcciones postales. El método ABRecordCopyValue devuelve según el atributo que obtengamos un valor de tipo simple CFTypeRef o un valor multivalor ABMultiValueRef. En el caso de que obtengamos un valor simle, este tendremos que convertirlo en NSString, NSDictionary o cualquier otro. En el caso de que el tipo de atributo sea multivalor (teléfonos, direcciones postales, etc...) podemos obtener el total de items que contiene mediante el método ABMultiValueGetCount(). A la hora de programar el acceso a la agenda tendremos que tener en cuenta el tipo de atributo que queremos obtener y/o acceder para implementarlo de forma adecuada en nuestra aplicación Creando datos en la agenda En el apartado anterior hemos estudiado como obtener ciertos datos de la agenda mediante el uso de la controladora ABPeoplePickerNavigationControllerDelegate y ciertos métodos para la gestión de estos datos. Ahora vamos a aprender como crear o modificar ciertos atributos de un contacto o incluso crear un contacto desde cero en la agenda del usuario. Si queremos ofrecer al usuario una interfaz clara y sencilla para modificar los datos de un contacto en concreto de la agenda podemos usar la controladora ABPersonViewController del framework Address Book UI. Un ejemplo de uso de esta controladora puede ser el siguiente: ABPersonViewController *view = [[ABPersonViewController alloc] init]; view.personviewdelegate = self; view.displayedperson = persona; // El objeto persona es de tipo ABRecordRef [self.navigationcontroller pushviewcontroller:view animated:yes]; Usando el código anterior mostraremos la vista mediante la cual el usuario puede modificar los datos de un contacto: 91

92 Pantalla de nuevo contacto Al igual que realizamos para obtener los datos de un contacto nuestra controladora deberá de implementar los métodos del protocolo ABPeoplePickerNavigationControllerDelegate, en concreto el siguiente método: personviewcontroller:shouldperformdefaultactionforperson:property:identifier:. Si queremos crear un nuevo contacto en la agenda mediante código deberemos de escribir algo como sigue: ABRecordRef arecord = ABPersonCreate(); CFErrorRef anerror = NULL; bool setok; // Nombre setok = ABRecordSetValue(aRecord, kabpersonfirstnameproperty, CFSTR("Javier"), &anerror); if (!didset) { NSLog(@"Se ha producido un error..."); // Apellidos setok = ABRecordSetValue(aRecord, kabpersonlastnameproperty, CFSTR("Aznar"), &anerror); if (!didset) { NSLog(@"Se ha producido un error..."); Mediante el código anterior creamos un nuevo contacto en la agenda usando el método ABPersonCreate. Después asignamos un valor para el nombre (kabpersonfirstnameproperty) y otro para los apellidos (kabpersonlastnameproperty) usando el método ABRecordSetValue. Como podemos ver estamos asignando valores simples, en el caso de queramos asignar items multivalor deberemos hacerlo de la siguiente forma: ABMutableMultiValueRef multi = ABMultiValueCreateMutable(kABMultiStringPropertyType); CFErrorRef anerror = NULL; 92

93 ABMultiValueIdentifier multivalueidentifier; bool addok, setok; // Telefono 1 addok = ", kabpersonphonemobilelabel, &multivalueidentifier); if (!addok) { NSLog(@"Se ha producido un error..."); // Telefono 2 addok = ", kabpersonphonemainlabel, &multivalueidentifier); if (!addok) { NSLog(@"Se ha producido un error..."); // Añadimos los telefonos (multivalue) al contacto ABRecordRef arecord = ABPersonCreate(); //la persona o contacto setok = ABRecordSetValue(aRecord, kabpersonphoneproperty, multi, &anerror); if (!setok) { NSLog(@"Se ha producido un error..."); CFRelease(multi); En el fragmento de código anterior creamos un valor multivaluado de tipo String. Añadimos dos valores distintos, en este caso son números de teléfono (tipo kabpersonphonemobilelabel y kabpersonphonemainlabel). Después añadimos ese valor multivaluado (variable multi) a los datos del contacto, esto lo hacemos mediante el método ABRecordSetValue pasando como parámetro el tipo de valor multivaluado que estamos actualizando o añadiendo (kabpersonphoneproperty). Como hemos podido ver en los ejemplos anteriores, el uso de las librerias del framework AddressBook.framework no es trivial. La recomendación que hace Apple es que si podemos usar las vistas y controladoras propias del framework AddressBookUI.framework mejor, ya que nos ahorramos mucho tiempo en la implementación de las funcionalidades de la agenda y de las vistas. Nota Como siempre, podemos acceder a la documentación oficial de la API para profundizar más en la implementación del acceso a la agenda. La documentación de Apple se encuentra en esta url. 93

94 8. Acceso a la agenda - Ejercicios 8.1. Obteniendo datos de la agenda: nombre y apellidos (2 puntos) Para realizar el ejercicio debemos usar la plantilla con el nombre EjercicioAgenda. En este ejercicio probaremos parte de lo aprendido en la sesión. Tendremos que mostrar un listado con los contactos de nuestra agenda usando las clases del framework AddressBookUI y cuando seleccionemos un contacto deberemos de mostrar su nombre y apellidos en forma de alerta (usando la clase UIAlertView). Estos son los puntos que debemos de completar: a) Implementar el método tapseleccionacontacto: de forma que cuando se ejecute la aplicación debe de mostrar una ventana con todos los contactos de la agenda del usuario. b) Terminar de implementar el método peoplepickernavigationcontroller:shouldcontinueafterselectingperson: el protocolo ABPeoplePickerNavigationControllerDelegate. En este método deberemos de obtener el nombre y los apellidos del contacto que el usuario seleccione y posteriormente debe de ejecutar el método diholanombre:yapellidos: c) Por último tendremos que implementar el método diholanombre:yapellidos: de forma que se muestre un texto similar a: "Hola [nombre] [apellidos]" dentro de una alerta (objeto de la clase UIAlertView) Obteniendo datos de la agenda: dirección (1 punto) Para realizar el ejercicio debemos continuar usando la plantilla con el nombre EjercicioAgenda. En esta segunda parte vamos a probar el uso de los atributos multivaluados de la agenda, para ello tendremos que obtener las direcciones postales (puede tener más de una) del contacto que el usuario seleccione. El código necesario para obtener la dirección/direcciones del usuario lo escribiremos al final del método peoplepickernavigationcontroller:shouldcontinueafterselectingperson:. 94

95 9. Técnicas de márketing y casos de éxito Gran parte del éxito de una aplicación para móvil se debe a la promoción que se le haga a esta. El márketing en las aplicaciones móviles es en la actualidad practicamente esencial si nuestra intención es que accedan a ella el mayor número de usuarios posible. Uno de los grandes problemas que los desarrolladores encuentran a la hora de acceder al mercado de las aplicaciones móviles es conseguir usuarios reales de su aplicación. Existen una gran cantidad de técnicas de promoción o márketing las cuales son diferentes según el modelo de negocio que escojamos. En esta sesión estudiaremos algunos puntos importantes a tener en cuenta cuando publiquemos alguna aplicación en la App Store Análisis del mercado actual Antes de comenzar con el desarrollo de una aplicación deberemos de hacer un estudio en detalle del mercado actual al que se enfrentaría nuestra aplicación cuando esta se lance. Este es un punto muy importante a tener en cuenta ya que de el dependerá la cantidad de usuarios potenciales que pueda tener la aplicación. En general deberemos de contestar una serie de preguntas: Es nuestra aplicación realmente útil?. Analizar si realmente sirve para algo la aplicación. Existen usuarios potenciales de nuestra aplicación? A qué tipo de usuarios va dirigida nuestra aplicación?, adultos, niños, cocineros, viajeros, etc. En el caso de que exista ya algo similar publicado Qué aportamos nosotros con la aplicación? Si tenemos pensado obtener beneficios económicos, Existe alguna forma de rentabilizar la aplicación? Por lo general el trabajo de análisis del mercado no lo realizarán los propios desarrolladores, ya que para ello suele existir un departamento de márketing que será el que realice este tipo de tareas. En cualquier caso siempre es conveniente conocer los conceptos más básicos por si tenemos que hacer uso de ellos en un futuro Es nuestra aplicación realmente útil? Es la primera cuestión que debemos de contestar antes de programar nada. Puede que para nosotros la aplicación sólo sea de utilidad para nosotros. En este caso no deberemos de seguir con el proceso de desarrollo si lo que queremos es sacar rentabilidad económica. En el caso de que la respuesta a la pregunta sea "sí, la aplicación será útil" podremos continuar con su desarrollo. Deberemos de analizar en qué puntos la aplicación es útil y qué beneficios proporcionará esta a los usuarios que la utilicen. En preguntas posteriores 95

96 analizaremos a qué cantidad de usuarios potenciales será de utilidad la aplicación Existen usuarios potenciales? Una vez que hemos visto que la aplicación es realmente útil tendremos que analizar si existen usuarios que se vean con la necesidad de descargarse la aplicación. Esto lo podremos averiguar preguntando a conocidos o en redes sociales y en foros. La idea es realizar una encuesta a "pequeña" escala con el fin de obtener conclusiones que nos permitan contestar a la cuestión. A parte de averiguar si pueden existir usuarios que les interese nuestra futura aplicación deberemos de analizar cuantos de estos usuarios estarían dispuestos a descargarse la aplicación y cuanto estarían dispuestos a pagar por ella. Las respuestas que obtengamos de estas últimas preguntas nos ofrecerán datos bastantes útiles para añadir al estudio del modelo de negocio que usar en la aplicación. También tendremos que analizar la cantidad en términos generales de usuarios potenciales de la aplicación, esto es si hay pocos o muchos en relación al total de usuarios de aplicaciones ios. Podemos incluso fragmentar la respuesta en usuarios según dispositivo (iphone o ipad) para de esta forma ver si conviene implementar una aplicación universal o sólo para un tipo de dispositivo en concreto. También convendría obtener resultados para otros mercados móviles como Android o Blackberry con el fin de analizar si nuestra aplicación encajaría más en estos otros mercados A qué tipo de usuarios va dirigida nuestra aplicación? Una vez que hemos llegado a la conclusión de que la aplicación tendrá usuarios potenciales nos toca averiguar a qué tipo de usuarios queremos enfocarla. La respuesta a esta cuestión nos ayudará a realizar la consecuente promoción así como a diseñar las interfaces de usuario de acuerdo al tipo o tipos de usuarios que usarán la aplicación. Por ejemplo, si vamos a publicar una aplicación para el mercado infantil (niños de 3 a 5 años), la interfaz debe de ser clara, con letras grandes y palabras sencillas. También debe de contener dibujos, colores bien definidos y unos objetivos claros en donde los usuarios (en este caso niños) no se pierdan y puedan hacer uso de la aplicación de una forma eficiente. Este punto es uno de los más importantes y de ello dependerá en gran parte la programación e implementación de funcionalidades de nuestra aplicación. En el caso de que exista un departamento de diseño, estos tendrán mucho que "decir" con respecto a este punto, ya que el diseño de las interfaces es de los puntos más importantes y críticos en el proceso de desarrollo de una aplicación móvil. Averiguar la categoría o categorías en donde nuestra futura aplicación puede "encajar" mejor es otro de los objetivos que debemos alcanzar mediante el análisis de la respuesta a esta cuestión. Estudiar a qué categoría puede pertenecer la aplicación es uno de los puntos más dificiles a los que podemos enfrentarnos en el proceso del análisis del mercado actual. El número y el tipo de usuarios potenciales que tendrá la aplicación dependerá en 96

97 gran medida de la categoría en donde se encuentre dentro de la App Store, por ejemplo, los usuarios de juegos no son los mismos que los usuarios de educación, por lo que tendremos que enfocar la aplicación a ese tipo de usuarios de la categoría. Gráfico de categorías Qué aportamos nosotros con la aplicación? Esta pregunta la podemos realizar junto con la primera que hemos planteado. Nuestra aplicación debe de proporcionar algo nuevo o mejorar algo que exista dentro de todo el conjunto de aplicaciones de la App Store. No siempre la mejor opción es innovar con algún tipo de funcionalidad desconocida hasta la fecha, muchas veces tendremos que mejorar funcionalidades existentes en otras aplicaciones ya publicadas. A menudo esta segunda opción es la más factible y realizada. Si accedemos a menudo a la App Store podemos ver que cada cierto tiempo aparece una aplicación totalmente innovadora, ya sea porque su interfaz o modo de uso es totalmente nuevo en un tipo concreto de aplicaciones o porque es un juego que hace uso de una tecnología existente pero añadiendo nuevas funcionalidades. A continuación se detallan dos ejemplos de aplicaciones que aportan algo: En el primer caso tenemos el ejemplo de la aplicación Clear (video), un gestor de tareas con todas las funcionalidades de un gestor de este estilo y que utiliza la funcionalidad de gestos que permite ios de una forma totalmente original. Sólo tenemos que ver el video para darnos cuenta de lo bien que los desarrolladores han aprovechado las tecnologías que nos ofrece ios para dar otra vuelta de tuerca a este tipo de aplicaciones, las cuales por otro lado hay un gran número de ellas publicadas. En el segundo caso encontramos la aplicación The One - Survive The Game (video). En este caso estamos hablando de un juego en el que nuestro iphone se transforma en una espada virtual mediante la cual debemos de combatir con otros usuarios reales a lo largo del globo terráqueo. El juego hace uso de la tecnología GPS que incorporan los dispositivos ios para situar al jugador y ver todos los jugadores y objetos que se encuentran a su alrededor. Cuando el jugador se acerca a uno de estos objetos o jugadores puede interactuar con ellos de forma que se obtiene puntos de experiencia, monedas, etc... La interfaz de usuario es 3D y el juego en sí dispone de muy pocas opciones. Con esta idea, totalmente innovadora, el equipo de The One consiguió alcanzar muy altas 97

98 posiciones en los rankings de medio mundo. Es claramente otro ejemplo más de aportación de ideas a la App Store. Existen multitud de ejemplos de aplicaciones que innovan o mejoran ciertas funcionalidades de otras en la App Store. Sólo necesitaremos una idea original e implementarla. En este punto conviene tener en cuenta también el tipo de competencia que tendrá la aplicación una vez que esta salga publicada. Deberemos de analizar si la compentencia más directa son empresas grandes o desarrolladores independientes. Obviamente, si vamos a competir con grandes empresas multinacionales va a ser más díficil conseguir que sus usuarios se interesen por nuestra aplicación que si competimos con pequeños desarrolladores. Las empresas grandes disponen de más capacidad para publicidad, campañas de promoción, etc Existe alguna forma de rentabilizar la aplicación? Una vez que hemos llegado a la conclusión de que nuestra futura aplicación tendrá una cantidad de usuarios potenciales suficiente como para rentabilizar el gasto que hagamos implementándola tenemos que analizar si podremos rentabilizarla. Lo primero que debemos de analizar es el tiempo de vamos a consumir para realizar toda la implementación. Esto es complicado de estimar para los primeros desarrollos porque no disponemos de ninguna referencia clara en término de tiempo, pero a medida que desarrollamos un número mínimo de aplicaciones (a partir de 2 ó 3), si hemos realizado las tareas bien, podremos realizar una estimación de tiempo más exacta. Existen varias maneras de medir nuestro tiempo, la forma más común es usando una aplicación de escritorio que guarde el número de horas que dedicamos a trabajar en la aplicación. En Mac existen varias como por ejemplo TicToc (itunes link) o Task Timer (itunes link) entre muchas otras. Para sistemas Windows disponemos de Allnetic Working Time Tracker (sitio web). A partir de la estimación de tiempo que le dedicaremos a la aplicación podemos hacer un cálculo bastante preciso del gasto total que deberemos de recuperar cuando la aplicación se ponga a la venta. Por ejemplo, si nuestra hora como programador cuesta 25 euros y hemos estimado que vamos a dedicar 3 meses a jornada completa (8 horas) en implementar la aplicación completa, invertiremos un total de 480 horas, esto son euros que deberemos de recuperar en un tiempo determinado a partir de que la aplicación salga a la venta. No siempre tendremos que obtener rentabilidad monetaria a una aplicación, la rentabilidad puede ser de otro tipo, como por ejemplo en términos de publicidad. Por ejemplo si publicamos una aplicación que promocione algún producto determinado (un modelo de coches, un sitio web.. o cualquier otro producto). En estos casos la aplicación suele ser totalmente gratuita y no recibirá rentabilidad directa, pero sí indirecta. 98

99 Llegados a este punto tenemos que plantearnos si la aplicación que vamos a desarrollar va a alcanzar en un periodo de tiempo limitado (un año, por ejemplo) la rentabilidad deseada. En el caso de obtener una respuesta negativa debemos de analizar qué podemos hacer para mejorar esto, por ejemplo implementando menos funcionalidades y dejar el resto para más adelante Estudio de los modelos de negocio A la pregunta de Cómo vamos a rentabilizar nuestra aplicación? debemos de dar una respuesta clara y concisa. Para conseguir rentabilizar una aplicación móvil tendremos que escoger uno de los modelos de negocio disponibles en el mercado de las aplicaciones móviles, a saber: Gratis. La aplicación es totalmente gratuita, sin publicidad ni micropagos. Pago. La aplicación es de pago. Existen distintas tarifas en la App Store de Apple, desde 0,89 euros hasta 999,99 euros In-app o micropagos. Son compras que se realizan dentro de la aplicación. Publicidad. La aplicación contiene algún tipo de sistema de publicidad (banner rotatorio, ventana emergente, etc...) En los próximos apartados vamos a estudiar cada uno de los modelos de negocio anteriores analizando sus posibles uso en determinadas aplicaciones así como el sistema de obtención de beneficios Modelo de negocio: Gratis Aunque a priori lanzar una aplicación totalmente gratuita parece una "locura", puede ser que si lo pensamos detenidamente nos demos cuenta de que no es así. Con las aplicaciones gratuitas no obtendremos beneficios en términos monetarios de forma directa aunque sí en indirecta, por ejemplo, si la aplicación en cuestión es una opción más dentro de una campaña de promoción determinada. En este caso, si la aplicación obtiene un cierto número de usuarios, el producto que se está promocionando con ella podría conseguir clientes. Existen una gran cantidad de aplicaciones totalmente gratuitas (sin usar micropagos ni publicidad) actualmente en la App Store y esta cantidad va aumentando a diario. Un claro ejemplo de este tipo de apliaciones son por ejemplo la de las marcas de vehículos o las que proporcionan una facilidad extra a usuarios de sitios web. Existen otro tipo de aplicaciones también gratuitas en su totalidad que simplemente el desarrollador ha preferido hacerla gratuita por algún otro motivo. Un ejemplo de aplicaciones gratuitas con fines promocionales son: Kayak (itunes link), BMW (itunes link), Idealista.com (itunes link), Ikea (itunes link) o MARQ (itunes link). Qué obtiene el desarrollador o la empresa contratante con este tipo de aplicaciones? La 99

100 respuesta es sencilla, si la aplicación promociona algún producto, se obtiene promoción web y potenciales clientes. Si no se promociona nada pero se da un servicio adicional, la empresa gana una cierta reputación. Otro uso muy extendido de este modelo de negocio es con el objetivo de promocionar ciertas aplicaciones "hermanas" de pago. La aplicación gratutita corresponde a la versión "lite" de la versión completa, que sería de pago Modelo de negocio: Pago Las aplicaciones de pago son aquellas que tienen un precio establecido determinado y el usuario que esté interesado en ella tendrá que pagar por descargársela. Este modelo de negocio es justamente el opuesto al anterior y normalmente se utiliza para aplicaciones que ofrecen ciertas funcionalidades exclusivas que ninguna otra ofrece. Mediante este modelo obtenemos beneficios económicos desde la primera compra. El modelo de las aplicaciones de pago se encuentra cada vez más en desuso, esto tiene sus razones de peso: Cada vez existen más aplicaciones en la App Store y, por tanto, más competencia. Si existen otras aplicaciones con funcionalidades muy similares a la nuestra y estas son gratutitas nosotros probablemente tendremos que rebajar el precio para adaptarnos al mercado. Es infinitamente más fácil atraer usuarios a una aplicación gratuita que a una de pago. Si nuestra intención está más enfocada a obtener descargas, este no es nuestro modelo de negocio. En el sistema de la App Store de Apple el desarrollador recibe un 70% de cada una de sus ventas, el resto lo recibe Apple en concepto de gastos por la gestión de toda su plataforma, servidores, etc. Esto tendremos que tenerlo en cuenta a la hora de establecer una tarifa de precio para nuestra aplicación. Entre todas las tarifas que existen en la App Store, la más común es la tarifa 1 (0,89 euros), es la tarifa más baja que existe y supone un gasto muy reducido para el usuario, el cual normalmente accederá a comprar la aplicación en el caso de que se encuentre minimanente interesado en ella. Las aplicaciones de pago verán reducido el número de clientes potenciales, esto es un dato lógico, ya que los usuarios acceden mucho más facilemente a aplicaciones gratutitas que de pago. La reducción en el número de clientes tiene como consecuencia directa la reducción en cantidad de descargas, lo que provoca una poca visibilidad en la App Store. Este modelo de negocio es el utilizado para las aplicaciones premium, estas son las que ofrecen una versión completa de la misma aplicación pero reducida o lite. Esta técnica de promoción es muy usada en juegos, por ejemplo: Cut The Rope FREE (itunes link) Cut The Rope (itunes link). 100

101 A continuación podemos ver un gráfico bastante interesante en el que se compara la cantidad de aplicaciones gratutitos y de pago. Gráfico de tarifas En definitiva, el modelo de negocio de pago es sin duda un modelo con riesgo ya que en el caso de que nuestra aplicación no consiga una mínima promoción por nuestra parte o por parte de Apple (promoción como aplicación de la semana, sección de destacados, rankings...) la aplicación puede acabar por no venderse o por obtener un número muy pequeño de ventas Modelo de negocio: In-app o micropagos Los in-apps o micropagos son compras dentro de la aplicación. Este modelo de negocio se utiliza casi únicamente en aplicaciones para dispositivos móviles y es un modelo relativamente nuevo. Desde que Apple lo anunció en una conferencia de desarrolladores ios ha tenido (y sigue teniendo) una gran acogida. Es tanto el éxito que está teniendo entre los desarrolladores que muchas aplicaciones que anteriormente eran de pago han cambiado de modelo de negocio a este ya que les proporciona mayor beneficios a largo plazo. Ejemplo de in-app Uno de los usos más frecuentes que podemos ver en la App Store es la combinación del modelo gratutito con el modelo de micropagos. Este es claramente el modelo más recomendado ya que se consigue que la aplicación alcance un alto número de usuarios potenciales por ser la aplicación gratuita y esto posteriormente repercutirá en las ventas de los micropagos. Vamos a analizar esto con algo más de detalle. En el caso concreto de los juegos este modelo es muy usado ya que el hecho de competición implícito en los juegos favorece la compra de productos "virtuales" para superar a los contrarios o para satisfacer una necesidad de juego. Un claro ejemplo de 101

102 juegos que utilizan el modelo de micropagos como modelo de negocio son los juegos sociales, los cuales actualemente se encuentran entre los que más ingresos obtienen en la App Store. Este tipo de juegos tienen más experiencia en este modelo de negocio porque ya se utilizaba (y se sigue utilizando) en los juegos de Facebook flash. Pero no todo son ventajas directas en este modelo de negocio. Debemos de estudiar en detalle los micropagos que va a tener nuestra aplicación con el fin de que el usuario tenga la necesidad de acceder a ellos sin que esto suponga ningún tipo de abuso. Para que este modelo tenga éxito, la aplicación debe de ser descargada por una cantidad notable de usuarios ya que sólo unos pocos accederaán a comprar mediante micropagos. Dado el altísimo apadrinamiento de este tipo de modelo de negocio en tan poco tiempo, Apple se ha tenido que poner las pilas y ha publicado una normativa que todo desarrollador debe de cumplir con el objetivo de evitar abusos y malos usos de los micropagos. La norma más destacable es que la aplicación debe de indicar en un lugar visible que contiene compras dentro de la aplicación y estas deben de estar claras, con el precio en un lugar visible y sin distracciones extra. Tampoco se debe de forzar al usuario que realice una compra para seguir usando la aplicación o juego. En el caso de que no se cumpla alguna de estas normas o cualquier otra relacionada con los micropagos, la aplicación será inmediatamente eliminada de la App Store o rechazada en el proceso de revisión. A la hora de configurar los in-apps dentro de nuestro panel de configuración de itunes Connect tendremos que escoger entre dos tipo de in-apps: Consumibles: se pueden adquirir infinitas veces. Usado en juegos sociales, compra de objetos virutales, etc... No consumibles: se pueden adquirir sólo una vez. Usado en aplicaciones para añadir funcionalidades extra o en juegos para desbloquear niveles, por ejemplo. Es recomendable que implementemos un sistema para evitar compras falsas. Esto lo tendremos que realizar mediante la obtención del recibo de pago de la compra por parte de Apple Modelo de negocio: Publicidad El modelo de negocio de publicidad es junto al de micropagos de los que más en periodo en expansión están dentro del mercado de las aplicaciones móviles. El modelo de publicidad como modelo de negocio en sí es de los más antiguos que existen ya que se lleva usando en radio, televisión y web durante muchos años. En las aplicaciones móviles es relativamente nuevo, por lo que aún hay mucho que explorar y estudiar. Este modelo de negocio se suele usar en conjunto con el modelo gratutito ya que de este modo se consigue acceder a un alto número de usuarios potenciales y, por tanto, una alta posibilidad de que estos hagan uso de la publicidad que nuestra aplicación ofrece. Existen varias formas de implementar los sistemas de publicidad en móviles, los más 102

103 usados son los dos siguientes: Banner horizontal o vertical: Es el más común. El banner de publicidad puede aparecer en la parte superior de la vista o en la parte inferior y debe de modificar su tamaño dependiendo del dispositivo en donde se muestre (iphone o ipad). Podemos implementarlo de forma nativa en nuestras aplicaciones. Ventana emergente: Es menos común que el anterior. Este tipo es algo más intrusivo que el banner horizontal y, por lo tanto, menos recomendado. Suele aparecer cada cierto tiempo en mitad de la pantalla y ocupando la mayor parte de esta. Podemos comparar este tipo de publicidad con el de los popups en web. En el modelo de negocio basado en pubicidad el desarrollador obtiene ganancias directas pero a un ritmo más lento que en otros modelos como el de pago, las cantidades de beneficios que se obtienen de publicidad suelen ser menores que con otros modelos de negocio, aunque constantes. En este modelo intervienen normalmente varios actores: las empresas anunciantes, las redes de servicios de publicidad (iad, AdMob, Mobclix, etc...) y los propios editores (los desarrolladores de las aplicaciones). Si decidimos utilizar este modelo de negocio deberemos de analizar en detalle donde vamos a mostrar el banner de publicidad así como el posible impacto que este puede llegar a tener. También tendremos que decidir qué sistema de publicidad usar. Existen varios sistemas disponibles para ios, estos son los más utilizados: iad: Es el sistema nativo de Apple y el más sencillo de implementar. La empresa anunciante es Apple (en realidad son intermediarios de otras empresas anunciantes que invierten para aparecer en iad). AdMob: Es el sistema de Google, dispone de una librería para ios. Actualmente es el más usado, después de iad. iad es la red de publicidad recomendada por Apple, dispone de una API muy bien documentada y es sencilla de implementar. Podemos gestionarla dentro del propio portal de desarrolladores de Apple y toda su publicidad es no intrusiva (basada en banners) y programada con HTML5, lo que no incrementa la carga de la aplicación. Aún con estos puntos a favor, iad tiene en la actualidad algún punto en contra: actualemnte está disponible en pocos paises y su variedad de anunciantes es reducida en comparación con otras redes. 103

104 Ejemplo iad Repartiendo las ganancias de publicidad El modo de repartir las ganancias en el modelo de negocio de publicidad varía según qué red de publicidad estemos empleando en nuestra aplicación. En un sistema clásico de publicidad en web, por ejemplo, se comparten los beneficios entre las propias redes de publicidad y los editores. En los sistemas clásicos se obtiene un cálculo de pago teniendo en cuenta dos factores principales: CPM (impresiones por banner) y CPC (clics por banner). En el sistema de iad Apple paga por los dos factores: CPM y CPC. Además los editores reciben directamente un 70% de las ganancias generadas con la publicidad. En líneas generales, el sistema iad aparece como el más rentable y el que más beneficios produce para los desarrolladores ios aunque tiene algunos puntos que no les favorece iad: Consideraciones en la implementación Debemos de tener en cuenta una serie de consideraciones a la hora de incorporar la publicidad de Apple en nuestra aplicación con el fin de mantener la buena experiencia de usuario e intentar que la aplicación siga teniendo buena calidad a pesar de incorporar publicidad en ella. El punto clave es conseguir nivelar la experiencia de usuario con el sistema de publicidad. No debemos de olvidar este punto, ya que esto puede provocar que el usuario deje de usar la aplicación. Estas son algunas consideraciones que tenemos que tener en cuenta: Posición del banner: Deberemos de analizar en detalle la posición en donde vamos a posicionar el banner: vertical superior o inferior (480x32) o vertical (300x500) además tendremos que tener en cuenta la rotación del dispositivo (si este rota, el banner también debe de hacerlo). Disponibilidad del banner: No es recomendable que el banner aparezca en todas las pantallas de la aplicación. Es recomendable planificar una buena disponibilidad del 104

105 banner con el fin de atraer la atención del usuario lo máximo posible. Planificar una alternativa: iad no siempre puede estar disponible, sobre todo en paises que no son Estados Unidos. Es por ello que es altamente recomendable usar alguna alternativa cuando este no se muestre como por ejemplo mostrar un banner de nuestra empresa (ideal para el caso de no haber conexión a Internet) o hacer uso de otras redes de publicidad como AdMob. Podemos hacer uso del sistema que propone AdWhirl (link) Promocionando una app La promoción en las aplicaciones ios es un factor en la actualidad casi determinante a la hora de conseguir audiencia. Nuestro objetivo principal será alcanzar puestos altos en los rankings de la App Store. Debemos de tener en cuenta que a partir de la posición #100 en cualquier categoría ya dejamos de existir, aunque no todo está perdido. En este apartado vamos a analizar una serie de recomendaciones que si se realizan se tendrá más éxito en el proceso de publicación en la App Store. Desarrollo de una app sin bugs y con opciones de marketing. Esencial para tener posibilidades de éxito en la App Store. La app debe de estar testeada lo máximo posible, para ello podemos "contratar" beta testers y, por supuesto, emplear las herramientas de desarrollo que nos ofrece el propio XCode. Escoger un buen título para la aplicación. Este es uno de los puntos más importantes. El título debe de ser determinante, simple, corto y que exprese lo más importante que realiza nuestra aplicación. El título que aparecerá en itunes puede ser distinto del que aparece en el dispositivo justo debajo del icono. Diseñar un buen arte. El icono y las capturas de la aplicación deben de ser atractivas y que comuniquen los puntos más importantes y que queremos destacar de nuestra aplicación. Deben de tener un diseño elegante y claro. Redactar una buena descripción para itunes. La descripción de la aplicación debe de ser directa, no debe de ocupar más de 4 párrafos. Es recomendable hacer un listado de los puntos más importantes de nuestra aplicación y atraer de alguna manera al usuario utilizando alguna frase impactante. También es recomendable que los textos de itunes estén traducidos en la mayor cantidad de idiomas posibles. Escoger las palabras clave adecuadas. Es muy importante para alcanzar buenos resultados en las búsquedas, que las palabras clave sean las adecuadas. Podemos usar herramientas gratuitas como Google Adwords para encontrar palabras clave que encajen con nuestra aplicación. Escoger las dos categorías que más se adaptan a la aplicación. Esto no suele ser complicado, pero no podemos despistarnos y pensar muy bien en qué categoría queremos que nuestra aplicación aparezca. En el caso de los juegos deberemos de escoger dos subcategorías. Programar una fecha determinada de lanzamiento. Aunque Apple da la opción de lanzar la aplicación cuando esta es aceptada (estado "Ready for sale") es recomendable programar una fecha determinada de lanzamiento, normalmente son los 105

106 viernes, aunque esto no es fijo. Si la aplicación es de pago, ofrecer una versión gratuita lite. Sólo en el caso de que la aplicación sea de pago, es recomendable lanzar una versión al mismo tiempo que sea gratuita y limitada con el fin de que esta haga la función de "gancho" y atraiga a clientes a la de pago. Escribir una nota de prensa en inglés y distribuirla. Hoy en dia es casi imprescindible escribir una buena nota de prensa, bien redactada y siguiendo los estándares que existen para ello (podemos buscar ejemplos en Internet). Esta nota de prensa la enviaremos a todos los portales relacionados que encontremos. Muchos de ellos nos ofrecerán una "review" de la aplicación si hacemos un pago y otros ni siquiera nos contestarán al , pero siempre debemos de intentarlo ( nunca se sabe!). "Free for a day". Esta táctica se está haciendo desde relativamente poco tiempo y consiste en poner la aplicación gratis durante uno o dos dias aproximadamente, de esta forma conseguimos un impacto importante en todos los portales que se harán eco de esta bajada de precio y conseguiremos nuevos usuarios de una forma rápida. En este periodo corto de tiempo subiremos posiciones en los rankings que después, al volver la aplicación a ser de pago, puede que mantengamos. En cualquier caso obtendremos nuevos usuarios y un cierto "buzz" por parte de la prensa. Jugar con los cambios de precio. Al igual que en el punto anterior, es conveniente que cada cierto tiempo realicemos algún tipo de rebaja en los precios con el fin de movernos en los rankings. Redes sociales. Es recomendable hacer la máxima promoción en redes sociales (Twitter, Facebook...). Podemos crear una página en Facebook para promocionar la aplicación. Enlazar las redes sociales que empleemos desde la web oficial promocional. Hacer un sitio web promocional atractivo. Aunque no es esencial, siempre es recomendable desarrollar un pequeño sitio web promocional en el que mostremos capturas de la aplicación/juego, así como un vídeo, formulario de contacto, etc. Este sitio web es recomendable que esté hecho al menos un mes antes del lanzamiento de la aplicación. Publicar un video promocional. Los usuarios agradecen más ver un video que leer un texto o ver imágenes. Podemos realizar un video semi-profesional usando las herramientas que existen de escritorio. También existe la posibilidad de encargarlo a una empresa externa. Existen varias herramientas que podemos usar para generar estadísticas de ventas, algunas son de pago y otras gratis. Las más importantes son las siguientes: App Annie (gratis). Aplicación web, proporciona rankings, posiciones en destacados, ventas, reseñas en todos los paises. Modalidad premium con más estadísticas. sitio web App Figures (pago por aplicación). Aplicación web, proporciona rankings, destacados, ventas, reseñas, estadísticas muy completas y de calidad, sistemas externos de publicidad como AdMob, etc. 106

107 AppViz (pago único). Aplicación de escritorio, proporciona rankings, ventas, reseñas y algunas estadísticas. App Figures AppViz 9.4. Casos de éxito En este apartado analizaremos con algo más de detalle dos casos de éxito que pueden servir de ejemplo para cuando vayamos a publicar alguna aplicación en la App Store. Los casos de éxito que se han escogido son dos juegos: Trainyard (Rix) y Cow Balloon (Peggy Games) Trainyard (Rix) Trainyard es un juego de puzzle desarrollado por Matt Rix lanzado en junio de 2010 que consiste en enlazar las salidas y llegadas de unas locomotoras de colores mediante el movimiento de fragmentos de las vías de tren. Matt optó por el modelo de negocio premium+lite lanzando al mismo tiempo una versión completa del juego de pago (con todas las funcionalidades activadas) y otra versión limitada gratuita con limitación en el número de niveles. Estos son los puntos claves que hacen de este juego un claro caso de éxito: Al segundo dia de estar disponible, un portal italiano realizó una reseña destacando la gran calidad del juego. Al tercer dia la versión lite del juego alcanzó la posición #1 en la App Store italiana dentro del ranking de todas las apps gratis. Poco a poco la versión lite empezó a hacer el efecto "gancho" y la versión de pago comenzó a subir puestos en los rankings de pago italianos. A los pocos dias del lanzamiento la versión de pago llegó a alcanzar unos beneficios netos de $240 por dia. Unos pocos dias después la versión de pago alcanzó el puesto #1 en la App Store UK, con sus consecuentes ingresos. Dado el éxito de la aplicación, un mes después de su lanzamiento, un editor de Apple 107

108 contactó con el desarrollador con el fin de destacar la aplicación en el portal de itunes, lo que supone un aumento bastante considerable en descargas. Actualmente, casi 3 años después, Trainyard se encuentra en posiciones nada despreciables en la App Store y con una puntuación de 5 estrellas de media. Trainyard Cow Balloon (Peggy Games) Cow Balloon es un juego de puzzle en el que nuestra misión será guiar una vaca algo "hinchada" (la protagonista) hasta el granero consiguiendo esquivar distintos tipos de obstáculos. El juego salió publicado en la App Store en octubre de 2011 usando un modelo de negocio que más adelante cambió y precisamente ese cambio fue el que hizo que alcanzara un éxito destacable. Estos son los puntos más importantes de Cow Balloon a lo largo de su paso por la App Store Cow Balloon apareció en la App Store dentro de la categoría de juegos de puzzle el 26 de octubre de 2011 usando el modelo de negocio de pago ($0,99). Los primeros dias de venta alcanzó un máximo de 10 descargas diarias. Sólo pasaron dos semanas cuando esta empezó a desaparecer de casi todos los rankings llegándose a situarse en posiciones muy bajas. Llegados a este punto, las ventas prácticamente se detuvieron Al poco tiempo el desarrollador cambió el modelo de negocio y optó por establecer el precio a gratis y añadir publicidad. El sistema de publicidad empleado consistía en una combinación de iad+admob+banner propio. Se aprovechó el lanzamiento de esta nueva versión para crear nuevos niveles y lanzarlo también en formato universal (iphone+ipad) Se hizo una inversión muy pequeña en publicidad de Facebook (50 euros aprox.) A los pocos dias de lanzar esta versión el juego alcanzó el #1 en el ranking global de juegos de Italia superando al "todopoderoso" Angry Birds. Durante una semana aproximadamente se mantuvo dentro del Top 10 en juegos consiguiendo unas descargas diarias sólo en Italia, país en el que tuvo una aceptación muy buena. 108

109 Las ganancias por publicidad se dispararon llegando a alcanzar casi los $300 diarios. Pocos dias después el juego alcanzó el #1 en juegos de iphone en los rankings de UK y Francia. En la actualidad el juego ha bajado en los rankings pero mantiene su modelo de negocio basado en publicidad. El desarrollador ha anunciado una segunda versión de Cow Balloon para el año 2013 Cow Balloon 109

110 10. Técnicas de márketing y casos de éxito - Ejercicios Técnicas de márketing y casos de éxito 110

111 11. Publicación en App Store y distribución Ad Hoc A la hora de distribuir una aplicación debemos de conocer muy bien como funciona todo el sistema que rodea la App Store, su sistema de categorización, itunes, búsquedas por palabras clave, opciones de internacionalización, etc. Antes de lanzar una aplicación a producción deberemos de preparar los certificados correspondientes, comprobar que las imágenes de los iconos, capturas, etc.. son las adecuadas, tendremos que preparar toda la información (metadata) que necesita itunes (descripción de la aplicación, palabras clave, descripción de in-apps, información personal de contacto, etc...). En esta sesión estudiaremos cómo preparar nuestra aplicación para lanzarla a la App Store. Analizaremos qué es la distribución en App Store y qué es la distribución Ad Hoc y por último veremos qué certificados necesitaremos y cómo podemos obteneros. Comenzamos! La App Store La App Store de Apple es el único canal de oficial que existe para distribuir aplicaciones. Las aplicaciones que incorporemos a la App Store se descargarán alrededor del mundo en casi todos los paises en los que Apple distribuye. Actualmente la App Store dispone de más de aplicaciones activas repartidas en 25 categorías, alguna de las cuales tienen más importancia que otras, como por ejemplo las categorías de juegos o utilidades. La categoría de juegos tiene a su vez 19 subcategorías (acción, aventura, cartas, educación, etc...). itunes App Store Algunos datos interesantes La App Store abrió el 10 de julio de 2008 mediante una actualización de itunes. En ese momento se lanzó el iphone 3G con la versión del sistema operativo ios. El segundo dia de su lanzamiento la App Store tenía 500 aplicaciones para iphone (el ipad aún no existía) disponibles. Pocos meses después, en septiembre de ese mismo año la App Store alcanzaba un total de 3000 apps. El crecimiento en número de aplicaciones a partir de ese momento fue casi exponencial, al igual que en número de descargas, el cual fue aumentando casi al mismo ritmo. El éxito que alcanzó este sistema de distribución y venta de aplicaciones fue tal que desde casi el primer dia de la existencia de la App Store aparecieron nuevas empresas o estudios de programación en los que únicamente se 111

112 dedicaban a realizar aplicaciones para este mercado, hasta el dia de hoy. En la actualidad hay muchas empresas en donde todos sus ingresos provienen de la App Store. Un claro ejemplo es la empresa finlandesa Super Cell, los cuales declararon en diciembre de 2012 alcanzar unos ingresos de más de dólares diarios obtenidos con sólo dos juegos. Al igual que esta empresa de Finlandia existen muchas otras (grandes o pequeñas) que han encontrado en la App Store una fuente a tomar muy en cuenta a la hora de diseñar su modelo de negocio. A la tienda de Apple podemos acceder mediante dos "sitios" distintos: la aplicación de escritorio itunes y la aplicación App Store incluida de forma nativa en todos los dispositivos ios. itunes se puede descargar de forma gratuita desde la web oficial de Apple y tradicionalmente se ha usado para organizar la música que tengamos en el ordenador aunque en la actualidad tiene alguna funcionalidad más como el poder acceder a la tienda de Apple (itunes Store para música y App Store para aplicaciones) para realizar compras. itunes se encuentra disponible para Windows y Mac. La aplicación de App Store, a diferencia de itunes, sólo está disponible en dispositivos ios (iphone e ipad). Desde ella podemos navegar por todas las categorías, ver los rankings de ventas y comprar aplicaciones. La simplicidad de uso es uno de los puntos más fuertes que tiene la App Store, ya que mediante dos clics o dos "toques" de pantalla podemos comprar, sin necesidad de introducir el número de cuenta de la tarjeta cada vez. Dentro de la gran cantidad de aplicaciones disponibles podemos distinguir dos grandes grupos, las aplicaciones de pago y las gratis. Actualmente existen casi el mismo número de aplicaciones de pago que gratuitas aunque se tiende a ir aumentando el número de aplicaciones gratuitas. La categoría con más aplicaciones es la de juegos, con un total de juegos (datos de febrero 2013) Requerimientos mínimos para distribuir en la App Store Distribuir nuestras aplicaciones en la App Store de Apple requiere que de una cuenta de pago de desarrollador. Existen tres tipos de cuenta de desarrollador ios: Cuenta standard individual (80 euros/año). Es la cuenta más común, para desarrolladores independientes o pequeños/medianos estudios (de hasta 50 empleados). Cuenta standard de empresa (80 euros/año). Igual que la anterior pero enfocada a empresas más grandes. Se necesitan datos de la empresa para abrir este tipo de cuenta. Cuenta empresa (225 euros/año). Es la cuenta apropiada para empresas que deseen crear aplicaciones para sus empleados (aplicaciones in-house). Mediante esta cuenta no se puede distribuir en la App Store, sólo Ad-Hoc. Cuenta universidad (gratis). Esta cuenta está enfocada a instituciones educativas y permite generar ciertos certificados para testeo en dispositivos. No permite la distribución en la App Store. 112

113 Todas las cuentas anteriores permiten el testeo de en dispositivos reales, cierto soporte (depende de cada tipo de cuenta), el acceso a foros restringidos de desarrolladores de Apple y a descargas de versiones beta de ios y XCode. La cuenta se debe de renovar cada año, de no ser así las aplicaciones publicadas se eliminaran de la App Store en el momento en que se de de baja la cuenta. Las cuentas de desarrollador de ios no son compatibles con las de Mac (aplicaciones de escritorio). Si disponemos una cuenta de desarrollador ios no podremos acceder a los recursos que ofrecen las cuentas de desarrollador de Mac y viceversa. Si tenemos la intención de crear aplicaciones para ambas plataformas deberemos que abrir dos cuentas distintas. Siempre tenemos la posibilidad de contactar con el servicio de soporte de Apple con el fin de conservar el mismo nombre de usuario/empresa/desarrollador para las cuentas. Se puede acceder a toda la información necesaría así como al formulario para crear la cuenta de desarrollador ios desde el portal de desarrolladores de Apple: Preparación de la aplicación para distribuir en App Store Una vez que tenemos la cuenta de desarrollador ios de Apple podemos ponermos manos a la obra con nuestra aplicación. En este momento tendremos que preparar la aplicación para su distribución, deberemos de realizar las siguientes tareas: Revisar nuestro código. Debe de estar libre de errores, bien probado (podemos implementar pruebas de unidad, unit testing). Nuestra aplicación debe de cumplir con las normas de estilo de Apple. Debemos de revisar muy detenidamente que la aplicación cumple las "sugerencias" de estilo de Apple. Hay muchas de esas sugerencias que son imprescindible para que no tengamos problemas en la fase de revisión de Apple. Completar toda la configuración del proyecto: nombre del bundle, internacionalización, requerimientos de dispositivo, versión de ios mínima requerida, etc... Preparar todo el arte: imágenes de iconos, capturas, etc. Comprobar que tenemos los tamaños de imágenes recomendados por Apple. Completar todos los datos sobre la aplicación en itunes Connect: debemos de rellenar todos los campos necesarios para poder publicar la aplicación. Estos campos son principalmente la descripción de la aplicación, palabras clave, datos de contacto, descripción de in-apps (si las hubiera), direcciones de soporte, , sitio web promocional, etc... Completar las traducciones (si las hubiera) de los textos de itunes. Siempre es recomendable traducir al menos al inglés y establecer este idioma por defecto. Pulsar en el botón Ready to upload. Este se encuentra en la configuración de la aplicación dentro del portal itunes Connect 113

114 Los puntos anteriores debemos de tenerlos muy en cuenta antes de proceder a enviar la aplicación al proceso de revisión de la App Store. Distribución en App Store Enviando la aplicación para revisión a la App Store Una vez que hemos terminado de repasar los puntos del apartado anterior, necesarios para que nuestra aplicación pueda pasar sin problemas por el proceso de revisión de la App Store debemos de compilarla, generar el binario y enviarlo a Apple. Anteriormente este proceso teníamos que hacerlo de forma casi manual (generando el fichero binario ipa, navegar hasta el portal de desarrolladores de Apple y adjuntarlo mediante un formulario), ahora el proceso es mucho más sencillo e intuitivo. La generación del binario y su posterior envío para comenzar el proceso de revisión se realiza de forma completa mediante XCode. Deberemos de seleccionar la opción Product > Archive del menu superior para compilar el proyecto de XCode usando los certificados de distribución. Una vez que la compilación ha terminado y ha generado el binario nos aparecerá una pantalla en la que tendremos que seleccionar de un desplegable la aplicación que hemos creado en itunes Connect y queremos enviar el binario. Seleccionamos la aplicación y pulsamos en el botón de Accept, en este momento el binario comenzará a enviarse a los servidores de Apple en donde, una vez terminado y confirmado el envío, se procederá a comenzar el proceso de revisión. Nota Para poder compilar la aplicación para distribución nos tenemos que asegurar que hemos seleccionado un dispositivo (ios Device) en el desplegable que se encuentra justo al lado del esquema. Si lo preferimos, podemos usar la aplicación de escritorio de Apple Application Loader para enviar el binario de nuestra app a la App Store. La aplicación Application Loader tiene otras funcionalidades más como la configuración de los in-apps de nuestras aplicaciones. 114

115 Estados de ejecución en ios En este momento, y si todo hay ido bien (no falta ningún dato básico y el certificado está bien) la aplicación pasará automáticamente al estado Waiting for review. A partir de ahora los equipos de revisión de aplicaciones de Apple tardarán aproximadamente una semana en revisar nuestra aplicación. Debemos de esperar pacientemente. En el caso de que cancelemos el binario volveremos a la cola de revisión y el proceso empezará desde 0. Durante el estado Waiting for review podremos realizar cambios en los textos e imágenes (metadatos) de itunes sin ningún problema. Después de aproximadamente una semana, y si todo ha ido bien, tendremos noticias de Apple indicándonos que la aplicación está lista para publicar a la App Store. Nuestra aplicación habrá cambiado al siguiente estado Ready for sale. En ese momento puede ocurrir uno de los dos casos siguientes: Si no hemos indicado fecha de salida: La aplicación comenzará a distribuirse poco a poco por todos los servidores de Apple en todos los paises. Si hemos indicado una fecha de salida: La aplicación se mantendrá en standby hasta que sea la fecha de salida indicada. En este caso aparecerá en cada país según su franja horario. Este método es ideal si se ha realizado algún tipo de campaña de promoción/marketing. En el caso de que después de la semana de espera (esto siempre es aproximado) recibamos un mensaje de Apple indicándonos que nuestra aplicación no ha superado el proceso de revisión y ha sido rechazada deberemos de leer con detenimiento el motivo que el revisor de Apple ha encontrado para rechazar la aplicación e intentar solucionarlo si es posible. Si el problema que ha encontrado el revisor de Apple tiene que ver con el binario tendremos que volver a enviarlo y comenzar de nuevo todo el proceso de revisión. En el caso de que el problema sea debido a los metadatos de itunes, tendremos que solucionar dichos problemas y ya está (la aplicación pasará al estado Ready for sale en pocas horas). Documentación Podemos acceder a una amplia documentación sobre el uso del portal de desarrolladores itunes Connect desde esta dirección Enviando una actualización de nuestra aplicación El ecosistema de la App Store permite que los desarrolladores envíen cuando ellos crean 115

116 necesario actualizaciones de su aplicación. Es recomendable actualizar las aplicaciones una vez cada dos meses aproximadamente con el fin de mantener la aplicación al dia. El objetivo de las actualizaciones es mejorar la aplicación ofreciendo nuevas funcionalidades o solucionando pequeños errores (bugs). El proceso de envío de una actualización a la App Store es muy similar al explicado en el apartado anterior para enviar una nueva aplicación. Antes de enviar el binario para comenzar el proceso de revisión de la App Store deberemos de comprobar lo siguiente: Configurar una nueva versión de la aplicación en el portal desarrolladores itunes Connect. El número de versión debe de ser superior al actual, ej: , etc. Asegurarse de que el número de versión que aparece en la configuración del proyecto de XCode coincide con el indicado en el portal itunes Connect. Comprobar que la aplicación no contiene errores y que no van a haber problemas de compatibilidad con versiones anteriores. Comprobar especialmente si usamos Core Data o algún otro sistema de base de datos. Los estados del proceso de revisión son los mismos que cuando se envia la aplicación por primera vez. En este caso podemos especificar desde la configuración de itunes Connect si preferimos que la actualización se publique de forma automática cuando se apruebe o si queremos tener la opción de publicarla cuando nosotros deseemos. En ningún caso se puede especificar una fecha concreta de publicación Proceso de distribución en la App Store y Ad Hoc Si optamos por distribuir nuestra aplicación en la App Store deberemos de generar el certificado de distribución desde el portal de ios Provisioning Portal. El proceso de obtención de este certificado es muy similar al del certificado de desarrollador. A parte del certificado de distribución necesitaremos un perfil de distribución (distribution provisioning profile). Certificado de distribución: Es un certificado que se instala en la aplicación "llavero" del Mac e incluye la clave privada del equipo de desarrollo. La clave pública se encuentra en el distribution provisioning profile. Perfil de distribución (Distribution provisioning profile): Incluye el certificado de distribución y el ID de la aplicación (app ID). En el caso de que el perfil de distribución se creara para distribución "Ad Hoc", también incluiría los dispositivos en los que la aplicación tendría permiso de instalación. Deberemos de realizar los siguientes pasos cuando tengamos que distribuir una aplicación a la App Store: 1) Obtener el certificado de distribución 2) En el caso de no disponer del distribution profile para la aplicación, se debe de 116

117 crear uno. 3) Descargar el distribution profile e instalarlo en XCode Paso 1: Obtener el certificado de distribución El certificado de distribución, al igual que ocurre con el certificado de desarrollo, sólo debemos generarlo una vez al año. Este caduca cuando termina nuestro contrato con el programa de desarrolladores de Apple. La generación de un certificado de distribución es muy sencillo, únicamente tenemos que abrir XCode y entrar en Organizer (Window > Organizer). Estados de generación de certificados y perfiles Dentro de Organizer seleccionamos la pestaña Devices y pulsamos en el botón Refresh. En ese momento se descargarán de forma automática los nuevos perfiles de desarrollo y distrbución que no estén instalados en XCode y en el caso de que no encuentre ningún certificado de distribución instalado en el llavero del Mac, se procederá a crear uno de forma automática. También podemos crear el certificado desde el llavero, solicitando el certificado de una autoridad de certificación (Acceso a llaveros > Asistente para Certificados > Solicitar un certificado de una autoridad de certificación). Podemos comprobar que se ha instalado el nuevo certificado de forma correcta entrando al llavero, pulsando en Mis Certificados y ahi deberemos ver el certificado de distribución junto con otros. Este certificado debe de incluir la clave privada tal y como podemos ver en la imagen siguiente: Certificados en el llavero Si hemos generado el certificado en un ordenador y queremos ahora realizar todo el proceso de distribución desde otro ordenador tendremos que exportar el certificado con su clave privada e importarlo en el otro ordenador. Esto lo haremos pulsando con el clic derecho sobre el certificado y seleccionando Exportar. Nos creará un fichero con extensión.p Paso 2: Crear un perfil de distribución El perfil de distribución identifica la aplicación que queremos distribuir (tanto en la App 117

118 Store como Ad Hoc) y debemos de crear uno por aplicación. Crear un perfil de distribución es muy sencillo y lo haremos desde el portal de desarrolladores ios Provisioning Portal siguiendo estos pasos: Paso 1: Entrar en el portal ios Provisioning Portal y abrir la pestaña Distribution Paso 2: Pulsar en New Profile Paso 3: Seleccionar el método de distribución (App Store o Ad Hoc) y escribir un nombre para el perfil Paso 4: Revisar que el certificado de distribución asociado es el correcto Paso 5: Elegir el App ID correspondiente a la aplicación. En el caso de que no lo hayamos creado, lo deberemos de crear antes. Paso 6: Si hemos seleccionado el método de distribución Ad Hoc deberemos de seleccionar hasta 100 dispositivos ios en donde queremos distribuir nuestra aplicación. Paso 7: Pulsar en Submit para generar el perfil de distribución. Creando un perfil de distribución Debemos de tener en cuenta que el perfil de distribución es válido sólo durante un año y sólo lo pueden generar los administradores del equipo de desarrollo. Si se configura el App ID para trabajar con notificaciones Push después de generar el perfil de distribución, deberemos de volver a generarlo con el fin de que este se actualice y funcione con el APNS (Servidor de Notificaciones Push de Apple) Paso 3: Instalar el perfil de distribución Una vez que se ha generado el perfil de distribución tenemos que descargarlo e instalarlo en XCode y en los dispositivos. Para descargar el perfil de distribución debemos de acceder al ios Provisioning Portal, pulsar en Provisioning del menú de la izquierda y ahi pulsar en el botón Download del perfil que acabamos de crear. Si el botón de Download no está aún activo tendremos que esperar unos segundos para que termine de generarse el perfil. El fichero que se descargará tendrá la extensión.mobileprovision. 118

119 Instalando un perfil de distribución Una vez descargado el fichero deberemos hacer doble clic sobre el y este se instalará de forma automática en XCode. Cuando conectemos nuestro dispositivo al Mac, automáticamente se copiará el perfil de distribución (al igual que ocurre con el resto de perfiles) y se instalará. Nota Para poder testear aplicaciones deberemos de activar el modo desarrollo en todos los dispositivos que vayamos a utilizar. Esto se hace accediendo al Organizer de XCode con el dispositivo contectado al Mac y pulsando en el botón Use this device for development. Automáticamente se descargarán todos los perfiles de distribución y de desarrollo y se instalarán en el dispositivo. 119