¿Qué podemos esperar de Omnis Studio 6.1?

64 bits

El ejecutable Omnis ha sido rediseñado para funcionar con procesadores de 64 bits, aún así deberemos esperar un poco, pues inicialmente sólo estará disponible en la modalidad servidor. Estaremos atentos desde éste blog al anuncio sobre su disponibilidad en la modalidad SDK. 

 

Componentes JavaScript

Los controles JavaScript tendrán una apariencia "nativa" es decir, mostraran el aspecto que corresponda a la plataforma en que se estén ejecutando. Su estilo vendrá determinado por las reglas CSS correspondientes. Estos componentes estarán localizados como un nuevo grupo dentro del "Component Store". Además de esto, todos los componentes han sido optimizados para mejorar su rendimiento, siendo posible alternar entre diferentes tamaños de pantalla ($screensize) soportados por un "remote-form", mediante simplemente pulsar las teclas Ctrl-N/Cmnd-N o bien seleccionando la opción correspondiente del menu contextual.
 

Nueva herramienta para la sincronización de componentes

Permite la configuración automática de los componentes ya utilizados en los "remote-form" según los diferentes diseños, lo que se traducirá en un considerable ahorro de tiempo a la hora de hacer que nuestras aplicaciones ofrezcan un mejor aspecto.
 

Servicios Web

Se añade soporte para servicios web "RESTful": permite tanto la creación de la interfaz de usuario necesaria para el uso de servicios web RESTful, como el hacer disponible el código  para el acceso a clientes externos. Además, de esto se ha añadido un nuevo componente externo denominado OJSON para permitir el uso de objetos basados en​JSON con RESTful.

Vista previa de impresión

Se ha rediseñado la ventana de vista previa, permitiendo al usuario seleccionar el texto de las páginas en pantalla, además de poder navegar por ellas mediante un índice conteniendo una miniatura de las mismas, situado al margen de la ventana.
 

Tarea inicial de la librería (Library Startup Task)

Una nueva preferencia denominada $clibstartuptask nos permitirá indicar cual será la tarea de inicio para la lbrería en ejecución.
 

Número máxima de líneas de código permitidas en un sólo método

¿Habías pensado alguna vez en escribir una aplicación Omnis en un sólo método? ;-)
El número máximo de líneas en un método ha sido aumentado de 1.024 a 256.000.
 

Comparar variables

Ahora es posible establecer comparaciones entre variables binarias, variables de objeto y  variables de referencia a objetos, con la única precaución de que las usadas en cada lado del operador sean del mismo tipo.
 

Separadores multi-hilo

Cada hilo (en un servidor de aplicaciones Omnis multi-hilo) puede tener sus propios identificadores de separación para el punto decimal, indicador de miles y forma decimal usada en importaciones, almacenados bajo la propiedad $separators.
 

Eliminación automática de "Object references" (referencias a objetos)

Las referencias a objetos se borran automáticamente cuando ya no sean necesarias con el fin de liberar memoria.

jsClient: Uso del wrapper JavaScript

Cuando nuestra aplicación no requiera de una bases de datos

Si la aplicación de cliente remoto no requiere del apoyo de una base de datos, la aplicación deberá unirse con la librería dbNoSQL. Esta proporciona el código auxiliar necesario para el correcto funcionamiento de cualesquiera otras funciones del dispositivo. En éste caso, cualquier intento de usar el "objeto SQL" del jsClient fallará.

 

El Wrapper y JavaScript

La wrapper incluye un WebView, que a su vez, aloja una aplicación JavaScript. La aplicación se inicializa mediante el archivo config.xml suministrado y que informa a al wrapper sobre cual es la página HTML desde donde cargar la aplicación.

El wrapper puede ser configurado para que se conecte a Omnis sólo con propósitos de testeo. Esto se logra a través de la opción de menú “Test Form” de Omnis Developer. El wrapper también proporciona acceso independiente al dispositivo remoto, con funciones específicas para el control del GPS, la cámara o la interfaz de audio (consulte el manual para obtener más información sobre cómo acceder a las funciones del dispositivo).

Para permitir el uso de éstas operaciones sin necesidad de conexión alguna con un servidor, el WebView deberá ejecuta secuencias de comandos locales, es decir que deberán estar contenidas en métodos que sólo pueden ser ejecutados del lado del cliente. Antes de compilar su aplicación, tendremos que personalizar el archivo config.xml de modo que pueda cumplir con éste propósito.

Cuando el cliente opera en el modo “on-line” se hará uso del parámetro URL del archivo de configuración, para cargar el “remote-form”, pero cuando es ejecutado en modo sin conexión, (modo “off-line”) los parámetros de configuración son utilizados únicamente para (si así se desea) actualizar su copia local de la aplicación o bien para ejecutar localmente los “remote-form”.

 

El wrapper para iOS

El wrapper iOS, incorpora tres modos de uso, para según la base de datos local a soportar. Estos son:  

OmnisJSWrapper            No hay soporte para base de datos local.
OmnisJSWrapper_SQLite     Se utiliza SQLite como soporte de base de datos local.
                          Sincronización con un servidor Omnis.
OmnisJSWrapper_UltraLite  Se utiliza UltraLite como soporte de base de datos local.
                          Sincronización con un servidor MobiLink.

 

 

Un apunte sobre UltraLite 

Deberá tenerse en cuenta que debido a restricciones de licencia, no es posible incluir como tal, el archivo "libulrt.a" del que depende UltraLite, lo que significa que cada vez que se desee incluir una nueva versión de UltraLite, tendremos que incluir este archivo manualmente. Para hacer esto, deberemos primero instalar SQLAnywhere 12, después y sobre el directorio ultralite/iphone de la instalación SQLAnywhere12, podremos encontrar el código fuente, etc., y un archivo léeme que nos guiará a través del proceso de construcción. (TigerLogic no proporciona ningún tipo de soporte sobre la compilación de este archivo).

Una vez construido el fichero "libulrt.a" (bien sea para su uso con el dispositivo o con un simulador), tendremos que situarlo sobre la carpeta correspondiente (-iphoneos o -iphonesimulator) bajo el directorio dbInterface del wrapper.

Los ficheros del wrapper

El código fuente de los diferentes wrapper's ya no se incluye junto con Omnis. Deberán descargarse desde el sitio web de Omnis: www.tigerlogic.com/omnis. Los archivos ZIP contienen los ficheros config.xml, junto con el resto de archivos que lo conforman. Existen diferentes notas técnicas disponibles en el sitio web Omnis, sobre el uso y la personalización de los wrapper's, como, por ejemplo las siguientes:

• TNJS0001: “Building & Customizing the Android Wrapper App
”
• TNJS0002: “Building & Customizing the iOS Wrapper App”

• TNJS0004: “Building & Customizing the BlackBerry Wrapper App”

El proceso de compilación para cada plataforma se describe en la respectivas notas técnicas.

jsClient: El objeto SQL (Sincronización con SQLite)

Si queremos hacer uso de SQLite en modo “off-line” y sincronizar una base de datos SQLite desde el dispositivo del cliente en lugar de usar Sybase UltraLite. Tendremos que tener en cuenta que dicha  sincronización está apoyada en bases de datos SQLite creadas al efecto e instaladas en el dispositivo cliente, estas guardan las tablas del usuario, así como información sobre el estado de la sincronización. El “SQLite Synchronization Server” utiliza estas tablas para pasar los datos a/de cada sincronización y para reenviar las solicitudes de sincronización. El proceso de sincronización SQLite es descrito en el manual “SQLite Synchronization Server”, puede ser descargado desde el sitio web Omnis: http://www.tigerlogic.com/omnis/download

Para poder utilizar el objeto de base de datos SQLite, en lugar del objeto UltraLite, la aplicación del dispositivo móvil, deberá estar unida a la librería dbSQLite en lugar de la dbUltraLite.

Aparte de esto, el funcionamiento y uso del objeto de SQL es esencialmente el mismo. Ta sólo los parámetros de inicialización difieren ligeramente, tal y como se muestra a continuación.

$syncinit()

Do oSQL.$syncinit(syncParams) Returns id

El módulo de SQLite actualmente reconoce los siguientes parámetros:

Username    Nombre de usuario de sincronización

            (definido en el servidor de sincronización)

Password    Contraseña de usuario de sincronización

            (definido en el servidor de sincronización)

HostString  URL del servidor de sincronización SQLite Omnis Web.

Timeout     Tiempo de espera en segundos para las operaciones

            de sincronización.

Al finalizar, se invocará el método $sqldone() pasando los siguientes parámetros:

• El ID de la solicitud (el mismo que retornó el $syncinit()).

Ejemplo: 

Do config.$define(Username,Password,HostString,Timeout)
             ;; se define mediante el uso de variables locales
Do config.$assigncols('Usuario1','xxxxxx','http://192.168.0.10:7001/ultra?OmnisClass=rtSync&OmnisLibrary=SyncServer',5)
Do oSQL.$syncinit(config) Returns id

Consulte el manual de la "SQLite Synchronization Server" para obtener más información sobre el diseño, implementación y uso del servidor de sincronización. Si lo desa podrá descargar su manual desde la página web Omnis (www.tigerlogic.com/omnis).