Probar aplicaciones en un dispositivo iOS

O como comenzar a programar sin pasar por el AppStore

¿Cuál es el problema?

Este artículo tiene la intención única de explicar una posibilidad “desconocida” al menos para mí relacionada con el desarrollo de aplicaciones para dispositivos iOS. Lo vi en varios sitios que no voy a indicar aquí por si acaso.

Las versiones utilizadas en esos artículos eran las siguientes:

Mac OS X 10.6.6

Xcode 3.2.5

 

En principio, cuando desarrollamos una aplicación para dispositivos iOS, la única opción “gratuita” que tenemos es probar dicha aplicación en el simulador integrado en el sistema. Esto es más que suficiente en la mayoría de los casos, pero existen situaciones en las que se queda un poco corto (por ejemplo, interactuar con el GPS)

En condiciones normales, cuando comenzamos el desarrollo de este tipo de aplicaciones, tenemos que ‘comprar’ una licencia a Apple, que nos puede dar derecho tanto a publicar nuestra aplicación en el AppStore como a configurar hasta 100 (me suena que eran 100) dispositivos ‘autorizados’ para realizar pruebas. ¿Qué sucede si no tenemos esa licencia?

La licencia es una suscripción anual y puede ser que únicamente queramos realizar pruebas antes de comenzar el desarrollo ‘en serio’, pero necesitando poder probar ‘en vivo’ las aplicaciones.

¡OJO! Reconozco que no tengo ni idea de si este procedimiento es legal o no, cada cual que haga lo que quiera, yo sólo he visto que existe esta posibilidad y quería recogerla en el lenguaje de Cervantes. Si alguien me advierte de que esto es ilegal, lo elimino y aquí paz y después gloria, que aquí estamos para aprender!

Proceso

Lo primero que se indica es que el dispositivo que queremos utilizar para realizar pruebas tiene que tener hecho el proceso de Jailbreak. Esto ya puede suponer un problema, ya que en función de la versión de iOS del dispositivo, es posible que no se pueda hacer jailbreak. Además del Jailbreak, es dispositivo por lo visto necesita tener instalada la aplicación “AppSync”

Una vez que cumplimos con esos requisitos, arrancamos nuestro MAC

Al turrón

Mediante el “Acceso a Llaveros” generamos un nuevo certificado:

1. Acceso a Llaveros
2. Asistente para certificados
3. Crear un certificado
4. El certificado a crear tiene que ser de tipo “Raíz autofirmada”.

Una vez generado el certificado, tenemos que realizar una modificación a un archivo de configuración de Xcode:

1. Finder
2. Developer
3. Platforms

Una vez en la carpeta “Platforms” elegimos con qué plataforma de las disponibles queremos trabajar (por ejemplo “iPhoneOS.platform”

¡OJO! En los artículos que he visto no mencionaban si alguna de las plataformas es incompatible con este método, supongo que si no funciona habrá que googlear un poco.

Editamos el archivo “Info.plist” (abridlo mejor con “TextEdit” y, lógicamente, guardad antes una copia del archivo)

Localizamos una de las secciones <dict>, concretamente la que comienza con la línea:

<key>ARCHS</key>

A continuación de las líneas:

<key>PLIST_FILE_OUTPUT_FORMAT</key>

<string>binary</string>

Introducimos las siguientes líneas:

<key>PROVISIONING_PROFILE_ALLOWED</key>

<string>NO</string>

<key>PROVISIONING_PROFILE_REQUIRED</key>

<string>NO</string>

A continuación, ejecutamos Xcode y abrimos el proyecto que queremos depurar.

¡OJO! Estos pasos hay que repetirlos en todos los proyectos que queramos depurar en un dispositivo físico, recordad que por regla general es suficiente con el simulador integrado.

1. Menú Project
2. Edit Project Settings
3. Pestaña Build
4. Sección Code Signing

En las propiedades “Code Signing Identity” y “Any iOS” establecemos el certificado local que creamos en su momento para montar todo este tinglado.

Y para acabar, en el desplegable del proyecto, elegimos el dispositivo en lugar del simulador y a jugar!!!

Consideraciones finales

Otra vez quiero indicar que desconozco si esta práctica es 100% legal, en principio realizar un Jailbreak a un dispositivo iOS es legal, aunque se pierde la garantía del aparato. El resto de pasos son cambios a archivos de configuración, con lo que entiendo que no debería suponer ningún problema.

Seguiré vigilando el tema y en el momento en el que tenga sospechas de la legalidad del mismo, actualizaré el artículo en consecuencia.

Ahora sí, para terminar, una ‘pequeña’ justificación, no he podido / querido utilizar capturas de pantalla, ya que yo no he probado el procedimiento y tampoco quería utilizar capturas de terceros.

Generar builds en TFS para proyectos de Sharepoint

O cómo compilarlos automáticamente sin morir en el intento.

Los últimos días he retomado el desarrollo de componentes para Sharepoint, que tenía bastante “oxidado” y como no podía ser de otra manera, he integrado el proceso de desarrollo dentro del TFS 2010. La situación que tenía (para tener claro de qué estoy hablando) era la siguiente:

• Equipo de desarrollo: Windows 2008 R2 de 64 Bits.
• Sharepoint Server 2010 instalado en el equipo de desarrollo.
• Visual Studio 2010.
• Servidor de fuentes: Team Foundation Server 2010.

 

Pasos Previos

Lógicamente antes de nada, hay que realizar las operaciones clásicas cuando utilizamos TFS (creación del Team Project, rama Main, etc.)

Hasta aquí nada nuevo bajo el sol, estuve realizando el componente (en este caso una WebPart) y llegó la hora de probarlo en el entorno de Preproducción.

Para la instalación en ese entorno, únicamente utilicé el WSP que genera Visual Studio al ‘empaquetar’ el proyecto de Sharepoint, pero se me ocurrió que tenía que ser posible utilizar las Builds de TFS para que ese paquete WSP se genere automáticamente, como el resto de productos alojados en TFS.

La verdad es que no resultó tan sencillo como yo esperaba, aunque los problemas y pasos para solucionarlos tienen mucho sentido.

Primer intento

Lo primero que intenté fue lo típico, generé una nueva Build Definition, y la ejecuté… Resultado:

Como vemos, al realizar la compilación el agente detecta que en el proyecto hay referencias que no le gustan, o que no conoce, vamos, que no existen en el servidor…

Esto es normal, ya que ni Visual Studio ni, por supuesto, Sharepoint están instalados en el servidor de compilación.

Segundo intento

Como no funcionó, tocó “googlear” un rato, y lo primero que encontré fue un “apunte” en el que indicaba que con una Build Definition ”normal” no se conseguía generar el WSP para el componente. Para solucionar ese problema, es suficiente con añadir el parámetro “/p:IsPackaging=True” en la sección de “MSBuild Arguments” de la Build Definition:

Pero aún hay más, encontré una pequeña ‘maravilla’ que en principio simplifica el proceso. Dicha maravilla es un script de Powershell que en un primer paso permite coger los ensamblados de Sharepoint de la máquina de desarrollo, y en una segunda pasada los copia y registra en el servidor de compilación. No voy aquí a repetir los pasos de ejecución de dicho script, ya que está suficientemente explicado aquí, pero baste una captura para ver el resultado de la compilación una vez ejecutado el script tanto en la máquina de desarrollo como en el servidor de compilación:

Bueno, tampoco íbamos a esperar que funcionase a la primera no?

Lo que ha pasado es que el script que hemos ejecutado sólo coge los ensamblados básicos de Sharepoint:

"Microsoft.SharePoint.dll"
"Microsoft.SharePoint.Security.dll"
"Microsoft.SharePoint.WorkflowActions.dll"

Como nuestro proyecto es una Web Part que hereda de un tipo de "Microsoft.Office.Server.Search.dll", tendremos que añadir dicho ensamblado en la sección “$Script:SharePoint14ReferenceAssemblies” del script que hemos ejecutado.

NOTA: Al ejecutar el nuevo script en la máquina de desarrollo es posible que nos dé un error de que ese ensamblado no se puede localizar, si es el caso, basta con copiarlo desde la carpeta ISAPI de Sharepoint a la carpeta “Files” que se genera al ejecutar el script (si no sabes dónde está la carpeta ISAPI, creo que te has equivocado de post)

Al final, después de pruebas y error, llegamos al…

Tercer intento

En el script mágico tuve que añadir los siguientes ensamblados en la sección que indicaba antes:

"Microsoft.Office.Server.dll"
"Microsoft.Office.Server.Search.dll"
"System.Web.DataVisualization.dll"

Tras ejecutarlo en el servidor de compilación, lanzamos la Build y:

¡Por fin! ya tenemos compilaciones automáticas desde TFS 2010 de proyectos para Sharepoint; además, podemos observar en la carpeta de los Drops que la compilación ha generado el paquete WSP:

Nota final

Como podemos ver en la última captura, la Build no sólo genera el paquete WSP, sino que también está llevando a la carpeta de Drops los ensamblados que hemos añadido durante el proceso. He investigado un poquillo y parece ser que se podrían eliminar de dicha carpeta en uno de los pasos del Workflow de la Build Definition, pero reconozco que no he ahondado más en el tema. Si por lo que sea llegamos a tener problemas de espacio, podemos borrar todos esos ensamblados de las distintas compilaciones. Oye, aunque tengamos que borrarlos a mano, sigue siendo mejor que lo que teníamos antes no?