28 octubre 2014

Aplicaciones para iOS (el "wrapper") (Parte 1 de 9)

Primeros pasos


  • Primero, descargue la última versión del proyecto “iOS Wrapper Project”, desde la web de Omnis Studio.
  • Descomprima el fichero zip del “wrapper” sobre una carpeta y asegúrese de no dejar espacios intermedios en la ruta hacia la carpeta extraída.
  • Haga doble-clic sobre el fichero “OmnisJSWrapper.xcodeproj”, para abrir el proyecto con xCode. 

Personalización de aplicaciones iOS


Una vez importado el “wrapper project” sobre xCode, deberá personalizarlo para su aplicación en particular. Este proceso comprende los siguientes pasos:

  1. Renombrar el proyecto
  2. Editar el fichero “config.xml”
  3. Cambiar el identificador (Identifier)
  4. Cambiar el nombre visible de la aplicación (App Name)
  5. Añadir iconos y pantallas de transición personalizadas
  6. Localizar su aplicación
  7. Eliminar elementos no requeridos
  8. Agregar SCAFs (sólo para aplicaciones “off-line”)
  9. Agregar bases de datos para funcionamiento “off-line”

Renombrar el proyecto


Una vez abierto el proyecto “wrapper” en xCode, es probable que desee cambiar su nombre por otro, que designe de modo más apropiado a su aplicación en particular.

La modificación del nombre del proyecto no ejerce efecto alguno sobre la aplicación resultante, pero si le permitirá registrar sus proyectos del modo más apropiado, especialmente si pretende crear diferentes aplicaciones ya que deberá usar proyectos independientes para cada una de ellas.

  • Escoja la vista “Project Navigator”, desde la barra lateral del proyecto (podrá hacerlo mediante hacer clic sobre el icono en forma de carpeta situado sobre la barra de herramientas).
  • Seleccione el nombre del proyecto, situándose sobre el nivel superior de la vista, y luego pulse la tecla “Entre” para cambiar su nombre.
  • Cambie el nombre y presione de nuevo “Enter”. Se le preguntará si también desea cambiar el resto de lugares donde también es usado. Deberá seleccionar la opción “rename all” para cambiar todas sus apariciones.
  • La versión actual de xCode (en el momento de escribir esto) parece omitir el cambio del los “Prefix Header” en los “targets”. De modo que deberá hacerlo manualmente:
    • Sitúese sobre el nivel raíz del proyecto en el “Project Navigator” – para que pueda ver la configuración del proyecto sobre el panel principal.
    • Seleccione uno de los “Targets”, para ver sus “Build Settings”.
    • Localice el ajuste “Prefix Header” (si lo desea puede usar para ello la caja de búsqueda) y asegúrese de que el nombre del archivo con extensión .pch figure con el formato -Prefix.pch.
    • Repita el paso anterior para los 3 “Targets”.

Aplicaciones para iOS (requerimientos, instalación y configuración de xCode)

Requerimientos iOS


Para construir y desplegar aplicaciones iOS necesitará lo siguiente:

  • Mac OS X 10.7 o superior
  • xCode 4.5 o superior
  • $99 - $299 (cuota anual)

Instalación de xCode


Para la construcción de aplicaciones iOS, es imprescindible instalar xCode. Si lo desea puede descargarlo (para OS X 10.7 o posterior) a través de Mac App Store.

Configuración como desarrollador autorizado


Para la correcta creación de aplicaciones iOS, es necesario que su código esté firmado y hacerlo en el momento de su compilación. El primer paso del proceso será inscribirse en uno de los programas para desarrolladores de Apple iOS.

Apple ofrece 3 diferentes opciones de inscripción en el “iOS Developer Program”:

  • Free - Permite descargar el SDK de iOS y probar las aplicaciones sobre el simulador, pero no podrá instalarlas sobre un dispositivo real.
  • Standard ($99 anuales) - Permite subir aplicaciones en la tienda “AppStore”, he impone un máximo de 100 dispositivos "Ad-Hoc" (modo test). 
  • Enterprise ($299 anuales) - Esta es la opción para compañías grandes, las cuales dispondrán de un “Dan & Broadstreet Number” (DUNS). Al igual que en el caso anterior, se permite la distribución de aplicaciones a través de la AppStore, y no impone límite en el número de dispositivos "Ad-Hoc".

Seguramente la gran mayoría de los desarrolladores Omnis se inscribirán en el programa “Standard”, las indicaciones incluidas a continuación suponen el uso de ésta modalidad.

Independientemente de la modalidad elegida, podrá registrarse como empresa o como individuo. La inscripción como empresa le ofrece la posibilidad de agregar miembros al equipo, mientras que la inscripción como individuo no lo permite.

Una vez registrado como desarrollador iOS, deberá iniciar una sesión en el “iOS De Center” y seguir los pasos que le mostramos a continuación:

Certificados


  • Abra la sección “Certificates” de su cuenta “iOS Dev Center” y seleccione el tipo “Production”.
  • Pulse sobre el botón + para abrir el asistente que le guiará durante la creación del certificado.

  • Cuando se le pida que seleccione el tipo de certificado, deberá elegir dentro de “Production” el tipo “App Store and Ad Hoc”.
    • En caso de que no tenerlo ya instalado, use el enlace que aparece en esta misma página para descargar e instalar el “Intermediate Certificates” (Worldwide Developer Relations Certificate Authority).
  • El asistente le guiará a través del resto del proceso de creación.
  • Una vez creado el certificado (y asociada su clave privada), es importante que guarde una copia del mismo en un lugar seguro.
    • Abra el “Keychain Access” localizado en “Applications/Utilities/”.
    • Pulse sobre la categoría “Certificates” localizada en la barra lateral y después sobre el certificado que acaba de crear.
    • Pulse botón-derecho sobre el certificado y escoja la opción “Export”.
    • Manténgalo en lugar seguro - si cambia de hardware o por cualquier otra razón pierde el certificado, podrá importarlo de nuevo desde esta copia de seguridad. Cualquier actualización posterior de sus aplicaciones, deberá ser firmada con el mismo certificado, de modo que esto es muy importante.

Identificadores


Un “App ID” (identificador de aplicación) determina los que podrán ser usados para realizar firmas mediante su perfil.
  • Abra la sección “Identifiers” de su cuenta “iOS Dev Center” y seleccione “App IDs”.
  • Pulse sobre el botón + para abrir el asistente que le guiará durante la creación del “App ID”.
  • Puede optar por crear un “Explicit App ID” (permite firmar un único identificador de aplicación) o un “Wildcard App ID” (permite firmar cualquier aplicación cuyo identificador coincida con el formato especificado).
    El formato para los identificadores de aplicación consiste en un nombre de dominio inverso. Por ejemplo “com.entidad.aplicacion”. De modo que deberá crear el identificador siguiendo éste patrón, tanto si está creando un “Explicit App ID”, como un “Wildcard App ID”. Está permitido el uso del carácter “*”, para indicar que se usará cualquier nombre, por ejemplo “com.entidad.*”.
    Sea cual sea el nombre elegido, téngalo siempre a mano, ya que tendrá que hacer uso de él más tarde, cuando tenga que asignar un identificador a su aplicación.
  • Las aplicaciones o “wrapper’s” Omnis, no requieren “App Services”.

Dispositivos


Si va a desplegar sus aplicaciones directamente (Ad-Hoc) y no a través de la “App Store”, deberá registrar cada dispositivo susceptible de ejecutar su aplicación.

  • Abra la sección “Divices” de su cuenta “iOS Dev Center”.
  • Pulse sobre el botón + para abrir la página que le permitirá añadir el dispositivo.

  • Los diferentes dispositivos deberán ser añadidos con su UDID (Ónique Device Identifier). Podrá localizar el UDID del dispositivo mediante conectarlo a iTunes y hacer clic sobre su número de serie. En la dirección http://whatsmyudid.com/ podrá encontrar una práctica explicación sobre como hacer esto.

Aprovisionamiento de perfiles (Provisioning Profile)


Un “Provisioning Profile” posibilita la unión de un Certificado (Certificate) con un “App ID” (también la de un grupo de dispositivos (Devices) con un “Ad Hoc Provisioning Profiles”). Es mediante el “Profile” resultante, con el que podrá firmar su aplicación (combinado con el “certificate/private key” almacenada en su llavero).

  • Abra la sección “Provisioning Profiles” de su cuenta “iOS Dev Center” y seleccione “Distribution”.
  • Pulse sobre el botón + para abrir el asistente que le guiará durante la creación de un nuevo “Provisioning Pofile”.

  • Podrá crear un “Distribution Provisioning Profile” de tipo “Ad Hoc” (despliegue directo) o bien de tipo “App store”.
    Deberá seleccionar en cada momento el que coincida con el modo de distribución elegido. Asegúrese de crear perfiles de tipo “Distribution”  y no del tipo “Development”.
    Es posible la creación de varios “Provisioning Profiles”, a fin de poder hacer uso de uno o más tipos, si así lo desea.
  • Siga los pasos del asistente. Una vez completado, podrá descargar el “Provisioning Profile”, para después hacer doble-clic desde el Finder sobre el archivo descargado, haciendo posible su incorporación a xCode.


09 octubre 2014

Construcción de aplicaciones para iOS, Android y BlackBerry con Omnis Studio

Además de utilizar la nueva tecnología “JavaScript Client” en la construcción de aplicaciones ejecutables sobre el navegador de cualquier ordenador, tablet o dispositivo móvil, podemos usarla en la creación de aplicaciones totalmente terminadas para dispositivos iOS, Android y BlackBerry. Dichas aplicaciones podrán incluso operar completamente “off-line”, es decir, sin necesidad de conexión a ningún tipo de servidor, en éste caso tan sólo requerirá de un número de serie especial instalado en su SDK Omnis, el “Serverless Client Serial”.

Para la construcción de dichas aplicaciones terminadas, disponemos de tres aplicaciones "esqueleto" construidas a medida de cada sistema, denominadas “wrapper” y presentadas en la forma de proyectos JavaScript: una para iOS, una para BlackBerry10 y otra para Android.

Dichos proyectos posibilitarán la creación de aplicaciones personalizadas, mediante una sencilla integración de clases “remote-form”, que permitirán a su vez el acceso a gran parte de las funcionalidades implementadas de modo nativo en el dispositivo, tales como la lista de contactos, función GPS y cámara de fotos.

Mediante las sucesivas entregas que iré publicando en éste blog, comprenderemos los diferentes pasos necesarios para crear y desplegar aplicaciones personalizadas para cada una de las plataformas móviles mencionadas. Estudiaremos paso a paso, todo lo que necesitaremos saber, tanto para la creación de la aplicación, como para su despliegue a los usuarios finales, ya sea que se haga a través de la tienda de aplicaciones del propio dispositivo o de manera autónoma.

Les sugiero que se suscriban a "Aula Omnis" a  través de cualquiera de las redes disponibles Facebook, Twitter, Linkedin, Google+, RSS FeedBurner o como seguidores de éste blog, a fin de no perderse las sucesivas entregas.

Reciban un cordial saludo.

08 octubre 2014

Creación automática de tablas en el servidor

En algunos casos, puede tener sentido la ejecución de un proceso, que cree las tablas que falten en el servidor automáticamente tras iniciar la sesión con la base de datos, la intención sería, causar que las tablas necesarias para el correcto funcionamiento de la aplicación existan. Dicho proceso podría lanzarse cuando la aplicación es ejecutada por primera vez, cuando se entrega una nueva versión de la base de datos, cuando se cambie a un nuevo servidor de base de datos o a una base de datos diferente.

Puesto que estamos haciendo uso de clases "schema" durante el desarrollo de nuestra aplicación, es posible compararlas con las tablas correspondientes en el servidor, para saber si existen realmente y en caso necesario crearlas.

Partiendo de la base de que tenemos una variable "task" denominada "tSessObj" con una conexión válida a una base de datos. Crearemos un "statementobject" que más tarde utilizaremos para enviar las sentencias SQL necesarias a la base de datos, lo haremos sobre la variable local "lStatObj" (de tipo "Object" y sin subtipo).

Do tSessObj.$newstatement(#CT) Returns lStatObj

La variable "Object" "lStatObj" ahora dispone de los métodos y propiedades necesarios y que pueden ser localizados mediante el "Interface Manager" (opción disponible, mediante pulsar el botón derecho del ratón sobre la variable) si lo deseamos.

A continuación, utilizaríamos el código que mostramos más abajo para obtener las tablas alojadas en el servidor de base de datos, recogiéndolas sobre la variable de tipo lista "lDBTableList", tal como sigue:

Do lStatObj.$tables(kStatementServerTable)

Tenga en cuenta que sólo podrá ejecutar éste código mientras disponga de una instancia activa, es decir, mientras exista una conexión válida con la base de datos. Por lo que, si desea depurar el código, deberá marcar un punto de interrupción en el lugar que desee de la "Startup_Task", para cargar sobre la lista el resultado del método anterior, escriba:

Do lStatObj.$fetch(lDBTableList,kFetchAll)

El segundo paso será crear otra lista, que contenga las clases "schema" existentes en nuestra librería. Para ello usaremos también dos variables locales que la definirán, tal y como sigue:

Do lTablesForAppList.$define(lTableName,lSchemaClassName)
Do $schemas.$appendlist(lTablesForAppList,$ref.$servertablename,$ref.$name)

Ahora tendremos que ejecutar un bucle "For" que ira recorriendo la lista de clases "schema" y creando las nuevas tablas en el servidor según sea necesario:


For lTablesForAppList.$line from 1 to lTablesForAppList.$linecount() step 1
   Do lTablesForAppList.$loadcols()
   ; carga la línea actual en los campos correspondientes lTableName y lSchemaClassName
   Do lDBTableList.$search(lDBTableList.TableOrViewName=lTableName,kTrue,kFalse,kFalse,kFalse)
   If not(lDBTableList.$line) ;; cuando no existe la tabla
      Do lRow.$definefromsqlclass(lSchemaClassName)
      ; define una variable local de tipo "row" con el nombre del "schema" que se acaba de cargar
      Do lRow.$sessionobject.$assign(tSessObj) ;; ¡importante! hace que $createnames funcionen correctamente
      ; crea la nueva tabla en el servidor:
      Do lStatObj.$execdirect(con('CREATE TABLE ',lRow.$servertablenames(),'
(',lRow.$createnames(),') ')) Returns lStatus
      If not(lStatus)
         Breakpoint -> implementar aquí el controlador de errores
      End If
   End If
End For

Naturalmente este código deberá ejecutarse después de abrir la sesión con la base de datos sobre el método $construct de la "Startup_Task", cómo puede observar, se comprueba si existe la tabla en el servidor en correspondencia con lo definido en su clase "schema" y si no existe será automáticamente creada.

01 octubre 2014

Uso de las clases "table"

Los desarrolladores a menudo nos preguntamos si no sería mejor utilizar clases "object" en lugar de clases "table" a la hora de construir código SQL, ya que al fin y al cabo, es posible programar en modo orientado a objetos, aún sin utilizar clases "table".

A primera vista, esto parece una propuesta razonable, ya que al utilizar las clases "object", disponemos de acceso directo al código y no será necesario escribir métodos con el código SQL sobre la clase "table", sino que podremos hacerlo en cualquier lugar.

De hecho, (según me consta) es un práctica extendida entre los programadores el hacer uso de las clases "schema" directamente, en lugar usar clases "table" conectadas a clases "schema". Seguramente debido a que con las clases "table", el programador debe decidir si introducir el código SQL a ejecutar dentro de la propia clase o simplemente hacer uso de los métodos y propiedades predefinidos, además de que, en cierto modo, las clases "table" son similares a clases "object".

Esencialmente la diferencia está, en que las clases "table" tienen propiedades adicionales. Por ejemplo; cuando una instancia, de una clases "table" ha sido definida con las columnas de una variable de tipo "list" o "row" y añadido a ella los métodos SQL que deseemos. Debemos tener en cuenta que dicha instancia es también un objeto de datos, es decir, una variable "list" o "row". Esto significa que en realidad estamos incluyendo métodos dentro de objetos de datos. El ejemplo siguiente, muestra un método en una clase "table", del cual obtenemos su valor de retorno:

If myRow.$checkFields()
   Do myRow.$insert()
Else
   OK message "El campo name esta vacío"
Endif


El método $checkFields() en la clase "table" podría ser:

If len($cinst.name) = 0 ;;name está vacío
   Quit method kFalse
Else
   Quit method kTrue
Endif

En nuestro ejemplo $cinst hace referencia a la fila actual de la variable "list" utiliza al definir la clase "table".

Algunos podrían argumentar que puede lograrse el mismo resultado usando una clase "object". Pero, esto no sería estrictamente cierto ya que requeriría del uso de otra capa de código, además del necesario uso de la clase "object" para acceder a la variable "list" o "row", mientras que en la clase "table" se aúnan ambas cosas.

Además (como en el caso de las clases "object") se puede hacer uso de los métodos predefinidos a la hora de gestionar la "list" o "row" de datos ya que, como tal, las clases "table" son autónomas. Esto nos permite además hacer uso de las propiedades y métodos de uso general, al mismo tiempo que decidir si haremos uso o no, de los definidos por nosotros, al actuar como super-clase de la clase "table". Atendiendo a nuestro ejemplo, colocaríamos el método $checkFields() en la super-clase, con lo que tendríamos la opción de anular este método desde la clase "table" derivada en caso necesario, para ello simplemente colocaríamos el comando siguiente en el método en la super-clase:

Quit method kTrue

En otras palabras, si no se hereda el método checkFields() de la clase "table", siempre devolverá kTrue.

Por supuesto usted es libre de usar clases "object" o "table", o ambas a la vez según lo considere oportuno, a la hora de incorporar el código SQL a su aplicación. La única cosa que deberá tener siempre en cuenta es, que la definición que hagamos mediante el método $definefromsqlclass() sobre la variable "list" o "row", será quien determine, donde deberá añadirse el código SQL. Por ejemplo:

Do myList.$definefromsqlclass($tables.T_Address,'Name','Firstname','City','ADDRESS_ID')

En éste ejemplo, "myList" es definida mediante la clase "table" "T_Address" y con las columnas; "Name", "Firstname", "City" y "ADDRESS_ID".

Cuando desee escribir su propio código SQL con estos nombres de columna, deberá hacerlo mediante la implementación de un método dentro de la propia clase "table" y que hará uso de su propio "statementobject" al ejecutarse. Tenga en cuenta que para que esto funcione, el objeto de sesión (sessionobject) deberá haber sido asignado a la clase "table", cosa que (dicho sea de paso) habremos hecho en el método $construct() de la super-clase.

Método: $loadExample()

Begin Statement
    STA: SELECT [$cinst.$selectnames()]
    STA FROM ... (su propio SQL)
End Statement
Do $cinst.$statementobject().$prepare()
Do $cinst.$statementobject().$execute() Returns Ok
If not(Ok)
    Do $cinst.$sqlerror()
    Quit method kFalse
Else
    Do $cinst.$fetch(kFetchAll) ;; Cargas todos los registros en el propio objeto
    Quit method kTrue
Endif

Note que $cinst.$selectnames() devolverá los datos de las columnas de la variable "list" o "row" utilizada en el momento de definir el instancia para la clase "table".

El método sería invocado desde la clase "table", del modo siguiente:

If myList.$loadExample()
   Do $cinst.$redraw()
Else
   Ok message "No se encontraron datos: [myList.$getErrorText()]
Endif

Utilizando este enfoque, el objeto cargará sus datos de forma independiente. al mismo tiempo que nos permite obtener el mensaje de error que pudiera producirse, lo cual también podría ser implementado en la super-clase si optáramos por un control de errores más generalizado, algo así como:

Método: $getErrorText()

Quit method $cinst.$statementobject().$nativeerrortext()

Esto completaría el círculo, ya que ahora estaríamos accediendo directamente las propiedades del "statementobject" ubicado dentro del propio objeto de datos. El método $getErrorText() devuelve el texto nativo del error, para ser mostrado el mensaje.

Pensemos ahora en otra ventaja al usar las clases "table", cuando hacemos uso de nuestros propios métodos para insertar datos solemos hacer uso de variables "bind" (ya hemos hablado de ellas en un artículo anterior de éste blog). Las variables "bind" hacen uso de caracteres especiales, con el fin de ahorrarnos la necesidad de poner comillas para encerrar textos. Pero en el caso de las clases "table", y si hacemos uso del método $insert() por defecto, (es decir no personalizado) el objeto utilizará automáticamente las variables tomándolas directamente de la variable "list" o "row" por lo que no tendremos que preocuparnos de nada en absoluto.

Además, el uso de clases "table", no impide el control sobre el código SQL que enviamos al servidor. Para ejemplo:

Calculate mySQLText as $cinst.$statementobject().$sqltext

Si decidiéramos no pasar ciertas columnas, podríamos excluirlas de los $insert() desde el método $construct() de la super-clase "table", del modo siguiente:

Do $cinst.$cols.ident.$excludefrominsert.$assign(kTrue)

En este ejemplo, la columna "ident" sería excluida de la inserción.

Por cierto, el método integrado $sqlerror() en una clase "table" es ejecutado automáticamente, cuando cualquiera de los métodos incluidos tales como $insert(), $update(), $delete() o $select() falla por cualquier razón. Por lo que, podría tener sentido anular este método también de la super-clase "table", creando un controlador de errores SQL más genérico en nuestra aplicación, en el manual Omnis Studio en Castellano podrá encontrar más información al respecto.