Bases para el desarrollo de una aplicación móvil de punto a punto con IBM Worklight y Dojo Mobile

Este artículo describe cosas que aprendimos a través de nuestra experiencia en el uso de IBM Worklight Studio y Dojo Mobile para desarrollar una aplicación móvil de punto a punto para la banca minorista. Junto con algo de información fundamental sobre estas herramientas de desarrollo y sobre aplicaciones móviles en general, el código de origen de muestra es incluido para ilustrarle y ayudarle a aplicar estos consejos en su propio desarrollo de aplicaciones móviles.

Denzil Menezes, Specialista IT Coop, IBM

Denzil Menezes tiene más de 5 años de experiencia en desarrollo e integración de sistemas de J2EE. Actualmente trabaja en soluciones de aplicaciones móviles en IBM Global Solution Center, principalmente utilizando IBM Worklight y Dojo Mobile.



Karl Bishop, Ingeniero de software sénior, IBM

Karl Bishop es un Ingeniero en Software Sénior en el equipo IBM Web Enablement and Support. Trabaja desde el bosque de Carolina del Norte. Karl trabaja en diversas aplicaciones internas y externas de web 2.0 y móviles. Se especializa en soluciones basadas en Dojo, Dojo Mobile y Worklight.



Biao Hao, Arquitecto de TI sénior, IBM

Biao Hao es un Arquitecto de TI Sénior Certificado en IBM Global Solution Center en Dallas. Actualmente lidera el desarrollo de soluciones y demostraciones móviles, utilizando tecnología de IBM Mobile Foundation. Tiene más de 15 años de experiencia con middleware y herramientas de integración utilizando productos de WebSphere y arquitectura y desarrollo de soluciones para la industria de la banca y los seguros.



26-11-2012

Introducción

Obtenga Worklight ahora

¡Descargue IBM Worklight Developer Edition 5.0 ahora, sin costo y sin fecha de vencimiento!

El equipo de IBM Global Solution Center en Dallas desarrolló una aplicación móvil para la industria bancaria. La aplicación incluyó muchas funciones de banca minorista, tales como sucursal y ubicación del cajero automático, contacto, balances de cuenta y actividades, transferencia de fondos y más. Diseñada y desplegada en teléfonos inteligentes de iOS y Android, la aplicación fue compilada utilizando IBM Worklight Studio con un enfoque híbrido. Dojo Mobile, una infraestructura de JavaScript para desarrollar aplicaciones web móviles entre plataformas, fue utilizada como el kit de herramientas primario para implementar la interfaz de usuario móvil, junto con widgets de Worklight.

El artículo describe aspectos técnicos clave en el diseño y desarrollo de la aplicación móvil, incluyendo el diseño e implementación de la interfaz de usuario móvil utilizando Dojo Mobile, la optimización de estructura y entorno de proyecto de Worklight, el uso de Dojo para reducir el esfuerzo de desarrollar artefactos específicos del entorno y las etapas en el desarrollo de un adaptador de Worklight - un componente esencial para integrar la aplicación con sistemas empresariales. La integración con sistemas empresariales está ilustrada en el código de muestra incluido utilizando un servicio REST que simule la información de cuenta en un sistema bancario. La implementación de un mecanismo de seguridad utilizando autentificación de Worklight para proteger recursos (como adaptadores de Worklight) también es discutida. El código de muestra (desarrollado y probado en Worklight Studio Developer Edition v5.0.0.0), como un subconjunto de la aplicación móvil general, está incluido para propósitos de ilustración.

Aquí está incluida la información para ayudarle a iniciarse:


Implementando una interfaz de usuario móvil utilizando Dojo Mobile

La Figura 1 muestra la pantalla de inicio en la aplicación bancaria de un iPhone. Desde aquí, el usuario puede acceder a la información de cuenta e iniciar transacciones, ubicar un cajero automático o una sucursal e iniciar un contacto para recibir ayuda.

Existen dos enfoques de diseño de IU que puede considerar para habilitar a un usuario para que navegue entre funciones:

  • El enfoque de barra de pestañas utiliza una lista de funciones comunes, cada una mostrada como un botón en la barra de pestañas que está disponible en la mayoría de las pantallas. El usuario utiliza un botón para navegar hacia una función específica. Este enfoque proporciona una navegación rápida y de un solo clic para funciones comunes. La desventaja es el espacio de pantalla adicional utilizado para la barra de pestañas, reduciendo el espacio de pantalla disponible para el área funcional.
  • El enfoque de lista de funciones lista la mayoría (o todas) las funciones como botones en la pantalla. La ventaja aquí es que cada función tiene más espacio de pantalla para trabajar. La principal desventaja es que se requieren clics adicionales para navegar, incluso para funciones utilizadas comúnmente.

Ambos enfoques son utilizados en la aplicación móvil de muestra descrita aquí. El enfoque de lista de funciones es mostrado en la Figura 1, en la cual tres funciones principales (My Accounts, Locations y Contact) están listadas como botones. Cuando el usuario navegue hacia My Accounts después de la autentificación, las funciones comunes como Accounts, Cash y Transfer son listadas como botones en la barra de pestañas del fondo, mostrada en la Figura 2. Las funciones adicionales son mostradas al hacer clic en More .

Figura 1. Figura 1. Pantalla de inicio
Figure 1. Home screen
Figura 2. Figure 2. Pantalla Accounts
Figure 2. Accounts screen

Dojo Mobile es una infraestructura de JavaScript móvil de HTML 5™ que permite el desarrollo rápido de aplicaciones web móviles con una sensación nativa en dispositivos móviles modernos como iPhone, iPod Touch, iPad y en teléfonos inteligentes y tabletas de Android y RIM. Utilizando un enfoque híbrido, una aplicación de Dojo Mobile puede hacer uso de APIs de dispositivo nativas, como ubicación de GPS o lectura de códigos de barras, y puede ser fácilmente empaquetada como una aplicación nativa utilizando IBM Worklight Studio.

La Figura 3 muestra la pantalla Accounts implementada utilizando Dojo Mobile (todos los widgets anotados en esta sección son parte del paquete de dojox.mobile):

  • La vista general (no mostrada) es dojox.mobile.View, la cual contiene una ScrollableView en la parte superior y una TabBar en la parte de abajo.
  • La ScrollableView superior muestra una lista de desplazamiento de cuentas, con una Cabecera en la parte superior y una EdgeToEdgeList en la parte de abajo.
  • La Cabecera muestra el título "Accounts" y contiene un botón Back y un ToolBarButton, "Logout".
  • La EdgeToEdgeList contiene una lista de ListItem, cada uno mostrando un resumen de cuenta.
  • La TabBar del fondo contiene una lista de TabBarButton, cada uno representando una función común como Accounts, Cash, Transfer.
Figura 3. Figura 3. Pantalla Account con widgets de Dojo Mobile
Figure 3. Account screen with Dojo Mobile widgets

El Listado 1 muestra el código utilizado para implementar estos widgets en esta pantalla.

Listado 1. Listado 1. Código para la pantalla Accounts en la Figura 3
<div data-dojo-type="dojox.mobile.View" id="LoggedInView" class="mobileClass"  
 style="height: 100%;">
 <div id="AccountsView" data-dojo-type="dojox.mobile.ScrollableView"
  data-dojo-props="selected:true" class="mobileClass">
  <h2 data-dojo-type="dojox.mobile.Heading"
   data-dojo-props="fixed:'top', back:'Back', moveTo:'IndexView', fixed:'top'"
   style="font-size: 19px;" align="center">Accounts
    <div id="logoutBtn" data-dojo-type="dojox.mobile.ToolBarButton"
     data-dojo-props="label:'Logout', moveTo:'IndexView',  
     transition:'slide',transitionDir:'-1'"
     style="width: 45px; float: right;" class="mblColorBlue"></div>
  </h2>
  <ul id="accountContainer" style="margin-top: 40px;"
   data-dojo-type="dojox.mobile.EdgeToEdgeList" class="indexListStyle">
   <!-- List of Accounts will be populated at runtime using the custom widget template
    defined under folder 'custom/AccountWidget' -->
  </ul>
</div>
 <ul data-dojo-type="dojox.mobile.TabBar" data-dojo-props="fixed:'bottom'" style="height:
   11%; overflow-x: hidden;">
  <li data-dojo-type="dojox.mobile.TabBarButton" id="accountsTab" style="width: 20%"
   data-dojo-props="icon1:'./images/tabs/icon_128x128_accounts.png', 
   icon2:'./images/tabs/icon_128x128_accounts_blue.png', selected:'true'">Accounts</li>
  <li data-dojo-type="dojox.mobile.TabBarButton" style="width: 20%"
   data-dojo-props="icon1:'./images/tabs/icon_128x128_cash_gradient.png', 
   icon2:'./images/tabs/icon_128x128_cash_blue.png'">Cash</li>
  <li data-dojo-type="dojox.mobile.TabBarButton" style="width: 20%"
   data-dojo-props="icon1:'./images/tabs/icon_128x128_transfer_solid.png', 
   icon2:'./images/tabs/icon_128x128_transfer_solid_blue.png'">Transfer</li>
  <li data-dojo-type="dojox.mobile.TabBarButton" style="width: 20%"
   data-dojo-props=" icon1:'./images/tabs/icon_128x128_billPay.png', 
   icon2:'./images/tabs/icon_128x128_billPay_blue.png'">Bill Pay</li>
  <li data-dojo-type="dojox.mobile.TabBarButton" style="width: 20%"
   data-dojo-props="icon1:'./images/tabs/icon_128x128_more.png', 
   icon2:'./images/tabs/icon_128x128_more_blue.png'">More</li>
 </ul>
</div>

Estructura de proyecto de Worklight utilizando Dojo

Worklight Studio proporciona un entorno de desarrollo integrado para aplicaciones móviles entre plataformas. La estructura de proyecto de Worklight contiene una carpeta apps que puede contener una o más aplicaciones. Una aplicación puede tener múltiples entornos de Worklight, dependiendo de las plataformas a ser soportadas por la aplicación. OpenFNApp en la Figura 4 contiene una carpeta common y entornos de android y iphone para crear aplicaciones a ser desplegadas en dispositivos de Android y iPhone. La carpeta dojo es automáticamente incluida cuando crea una aplicación habilitada para Dojo en Worklight.

Figura 4. Figura 4. Estructura de proyecto de Worklight
Figure 4. Worklight project structure

La carpeta común en la Figura 5 contiene artefactos que serán compartidos por todos los entornos. Contiene un archivo HTML principal (OpenFNApp.html) que es cargado en la inicialización de la aplicación y otras carpetas de recursos web típicos como js, css e imágenes.

Figura 5. Figura 5. Estructura de carpeta común
Figure 5. Common folder structure

Los archivos específicos del entorno deben ser incluidos en la carpeta de iphone o android, según sea apropiado. Estas carpetas tienen la misma estructura de carpetas que la carpeta común. Por ejemplo, si hay ciertos estilos que necesitan ser aplicados a un entorno de un dispositivo específico, entonces un archivo CSS puede ser creado bajo la carpeta apropiada con el mismo nombre que el archivo correspondiente en la carpeta common/css. Cuando el proyecto nativo es compilado, Worklight añadirá archivos css específicos del entorno a los archivos css comunes con los mismos nombres al generar el código nativo. Los estilos específicos del entorno tendrán precedencia sobre los estilos incluidos en la carpeta común. En forma similar, si el archivo de HTML principal es colocado en la carpeta de android o iphone, este archivo de HTML sustituirá el archivo de HTML principal en la carpeta común y será utilizado por Worklight para desarrollar la aplicación nativa. Los archivos de JavaScript específicos del entorno con los mismos nombres serán añadidos unos a otros. En la aplicación descrita aquí, debido a la posibilidad entre plataformas en Dojo, la mayoría del código está en la carpeta común y compartido en los entornos de iphone y android. El código específico del entorno es añadido sólo cuando es necesario. Por ejemplo, los archivos OpenFN.css en los entornos de android y iphone contienen distintas normas de altura para AccountsView (Listado 1), mientras que todos los estilos de aplicaciones comunes están definidos en el archivo common/css/OpenFN.css.

Figura 6. Figura 6. Archivo específico del entorno
Figure 6. Environment-specific file

Un widget personalizado, AccountWidget, es utilizado para mostrar información de cuenta dentro de la aplicación. Este widget está incluido en la carpeta common/custom (vea Resources para obtener detalles sobre la implementación de widgets personalizados). El Listado 2 muestra el código de JavaScript para cargar el widget personalizado.

Listado 2. Listado 2. Código para cargar el widget personalizado
<script>
 var base = location.href.split("/");
 base.pop();
 base = base.join("/");
 var dojoConfig = {
 isDebug : false,
 async : true,
 parseOnLoad : false,
 packages : [ {
  name : "custom",
  location : base + "/custom"
 } ]
};	
</script>

Para el desarrollo de aplicaciones entre plataformas, el módulo dojox/mobile/deviceTheme (Listado 3) automáticamente detecta el dispositivo e incluye las hojas de estilo necesarias para representarse en ese dispositivo. Esto facilita una sensación nativa de la aplicación sin importar la plataforma mientras se utiliza la misma base de código.

Listado 3. Listado 3. Cargando módulos de Dojo
<script type="text/javascript">
 require(// module identifiers
  ["dojo/parser", "dojo/_base/connect", "dojox/mobile",
    "dojox/mobile/deviceTheme", "dojox/mobile/compat",
    "dojox/mobile/Button", "dojox/mobile/TabBar", "dojox/mobile/TabBarButton",
    "dojox/mobile/ScrollableView"],
     // Callback function invoked on dependencies evaluation results
     function(parser, connect) {
      dojo.ready(function() {
      parser.parse();
      dojo.style("content", "display", "");
      connect.connect(dijit.byId("myAccountsListItem"), "onClick", null, getAccounts);
      });
     });
</script>

Desarrollando adaptadores de Worklight

Los adaptadores de Worklight proporcionan una interfaz individual para una aplicación de cliente para comunicarse con sistemas de backend. Existen varios tipos de adaptadores, incluyendo conexiones HTTP, servicios de SOAP, llamadas de base de datos de SQL y más. Estos adaptadores pueden ser asegurados y supervisados.

Un AccountsAdapter es utilizado aquí para invocar un servicio de REST que recupere la información de cuenta del usuario. El adaptador consiste en estos archivos (Figura 7):

  • Un archivo XML de configuración para especificar opciones de conectividad y enumerar los procedimientos expuestos a la aplicación de cliente u otros adaptadores.
  • Un archivo de JavaScript para implementar procedimientos declarados en el archivo XML de configuración.
  • Archivos XSL opcionales para transformar los datos XML en bruto recuperados.
Figura 7. Figura 7. Archivos de adaptador de Worklight
Figure 7. Worklight adapter files

El archivo XML de configuración para AccountsAdapter (Listado 4) especifica los detalles de conexión (como política de conexión que incluye protocolo, dominio y puerto) que necesita el adaptador para la conexión para recuperar la información de cuenta. El recurso de adaptador es protegido al utilizar el Dominio definido en el atributo authenticationRealm, el cual garantiza que el usuario sea autenticado antes de que el procedimiento de adaptador sea invocado. (La protección de autentificación es configurada en la siguiente sección.)

Listado 4. Listado 4. XML de configuración para AccountsAdapter
<xml version="1.0" encoding="UTF-8"?>
<wl:adapter name="AccountsAdapter" authenticationRealm="AccountsAuthRealm"
. . . . . . . 
 <displayName>AccountsAdapter</displayName>
 <description>AccountsAdapter</description>
 <connectivity>
   <!--The configuration below assumes the REST service is deployed 
	on localhost with port 9080 --> 
   <connectionPolicy xsi:type="http:HTTPConnectionPolicyType">
    <protocol>http</protocol>
    <domain>localhost</domain>
    <port>9080</port>
   </connectionPolicy>
  <loadConstraints maxConcurrentConnectionsPerNode="2" />
 </connectivity>
<procedure name="getAccounts" requiresAuthentication="true"/>
</wl:adapter>

El archivo JavaScript del adaptador (Listado 5) contiene el código de implementación para el procedimiento definido en el archivo XML de configuración. El procedimiento getAccounts invoca un servicio de REST que recupera información de cuenta para un usuario autenticado. No hay necesidad de que la aplicación del cliente pase la información de usuario al procedimiento del adaptador, ya que puede ser obtenida utilizando WL.Server.getActiveUser() una vez que el usuario es autenticado. El servicio de REST de información de cuenta es invocado utilizando la llamada WL.Server.invokeHttp, la cual retorna los datos hacia la aplicación de cliente en formato de JSON.

Listado 5. Listado 5. Código de JavaScript del adaptador
function getAccounts() {
 . . . . 	
 var userObj = WL.Server.getActiveUser();
 var serviceURL = "/OFNWebServices/rest/account/getAccounts";
 . . . . .
 
 return WL.Server.invokeHttp({
	 method : 'get',
	 returnedContentType : 'json',
	 path : serviceURL,
	 parameters : {
	  username : userObj.userId
	 }
        });
 }

Implementando autentificación de Worklight

Entidades como los adaptadores de Worklight pueden ser protegidas por un proceso de autentificación que define etapas a ser tomadas antes de que se acceda a una entidad. AccountsAdapter está protegido; el usuario necesita ser autenticado antes de recuperar la información de cuenta utilizando el servicio de REST de backend. La autentificación de Worklight es utilizada para implementar esta medida de seguridad:

  1. Primero, un dominio de autentificación es definido en el archivo authenticationConfig.xml en la carpeta server/conf. El dominio llamado AccountsAuthRealm (Listado 6) especifica los atributos de función de inicio de sesión y función de cierre de sesión. Estos atributos definen los métodos del adaptador a llamar cuando las funciones de inicio y cierre de sesión son realizadas en el lado del servidor.
    Listado 6. Listado 6. Dominio de autentificación en authenticationConfig.xml
    <realm name="AccountsAuthRealm" loginModule="AccountsAuthModule">
     <className>com.worklight.integration.auth.AdapterAuthenticator</className>
     <parameter name="login-function" value="AuthenticationAdapter.onAuthRequired" /> 
     <parameter name="logout-function" value="AuthenticationAdapter.onLogout" />
    </realm>
  2. Un módulo de inicio de sesión es entonces definido en el mismo archivo authenticationConfig.xml. En el Listado 7, AccountsAuthModule utiliza com.worklight.core.auth.ext.NonValidatingLoginModule, indicando que la autentificación será realizada por un proceso definido por el desarrollador dentro del adaptador.
    Listado 7. Listado 7. Módulo de inicio de sesión en authenticationConfig.xml
    <loginModule name="AccountsAuthModule" canBeResourceLogin="true"
     isIdentityAssociationKey="false">
     <className>com.worklight.core.auth.ext.NonValidatingLoginModule</className>
    </loginModule>

    Las funciones de inicio y cierre de sesión son definidas en el adaptador llamado AuthenticationAdapter (Listado 8).

    Listado 8. Listing 8. Funciones onAuthRequired y onLogout en AuthenticationAdapter-impl.js
    function onAuthRequired(headers, errorMessage){
     errorMessage = errorMessage ? errorMessage : null;
     return {
      authRequired: true,
      errorMessage: errorMessage
     };
    }
    function onLogout(){
     WL.Logger.debug("Logged out");
    }
  3. En el Listado 9, el procedimiento submitAuthentication es definido en el archivo AuthenticationAdapter.xml. Este procedimiento será invocado desde la aplicación del cliente para validar las credenciales de usuario.
    Listado 9. Listado 9. submitAuthentication en AuthenticationAdapter.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <wl:adapter name="AuthenticationAdapter"
     . . . . 
     <procedure name="submitAuthentication"/>	
    </wl:adapter>

    El procedimiento submitAuthentication (vea el Listado 10) toma el nombre de usuario y contraseña como parámetros que pueden ser validados con un registro de usuario. Si se tiene éxito, el objeto userIdentity es creado y colocado en la agrupación de usuarios activos utilizando el método WL.Server.setActiveUser(). Un objeto de JSON con el parámetro authRequired:false también es retornado, indicando una autentificación exitosa. Si el usuario no es autenticado, un objeto de JSON con el parámetro authRequired:true es retornado indicando que la autentificación sigue siendo requerida.

    Listado 10. Listado 10. submitAuthentication en AuthenticationAdapter-impl.js
    function submitAuthentication(username, password) {
     if ((username=="wl" && password == "wl") || (username=="worklight" && password ==
      "worklight") ){
      WL.Logger.debug("Auth :: SUCCESS");
      var userIdentity = {
       userId: username,
       displayName: username, 
       attributes: {}
     };
     WL.Server.setActiveUser("AccountsAuthRealm",userIdentity);
     return {
      authRequired: false
      };
     }else{
      WL.Logger.debug("Auth :: FAILURE");
      return onAuthRequired(null, "Invalid login credentials");
     }
    }
  4. Al completar la autentificación en el lado del servidor, AccountsAdapter se protege al especificar el dominio AccountsAuthRealm para el atributo authenticationRealm en AccountsAdapter XML (Listado 11).
    Listado 11. Listado 11. authenticationRealm en AccountsAdapter.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <wl:adapter name="AccountsAdapter" authenticationRealm="AccountsAuthRealm"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
     xmlns:wl="http://www.worklight.com/integration"
     xmlns:http="http://www.worklight.com/integration/http">
    . . . . 
    <procedure name="getAccounts" requiresAuthentication="true"/>
    </wl:adapter>

Ahora veamos la autentificación implementada en el lado del cliente.

  1. Un archivo de JavaScript auth.js es automáticamente generado para proporcionar esqueletos de método para implementar la autentificación de Worklight. La función init (Listado 12) es utilizada para inicialización. Un manejador de eventos es definido para hacer clic en el botón Sign On (con el ID submitAuthBtn). La función de manejo de eventos invoca el procedimiento del adaptador de autentificación AuthenticationAdapter.submitAuthentication al pasar el nombre de usuario y contraseña desde los campos de entrada. En forma similar, el manejador de eventos para hacer clic en el botón Logout (con el ID logoutBtn) también es definido al invocar WL.Client.logout(‘AccountsAuthRealm’).
    Listado 12. Listado 12. Función init en js/auth.js
    init : function() {
     // Authenticator initialization code
     require([ "dojo", "dojo/_base/connect" ],
      function(dojo, connect) {
       connect.connect(dojo.byId("submitAuthBtn"),"onclick",null,function() {
       var username = document.getElementById("usernameInputField").value;
       var password = document.getElementById("passwordInputField").value;
       var invocationData = {
       adapter : "AuthenticationAdapter",
         procedure : "submitAuthentication",
         parameters : [ username,password ]
       };
       WL.Client.invokeProcedure(
         invocationData,
         {onSuccess : signOnSuccess,
          onFailure : signOnFailure
       });
     });
      connect.connect(dojo.byId("logoutBtn"), "onclick", null, function() {
       WL.Client.logout('AccountsAuthRealm');
      });
     });
    }
  2. La función isLoginFormResponse() (Listado 13) es invocada una vez que una respuesta es recibida desde el lado del servidor. La función retorna un booleano indicando si la autentificación tiene éxito o no.
    Listado 13. Listado 13. Función isLoginFormResponse en js/auth.js
    isLoginFormResponse : function(response) {
     if (!response || !response.responseJSON || response.responseText == null) {
      return false;
     }
     return response.responseJSON.authRequired;
     }
  3. La función onBeforeLogin() (Listado 14) es utilizada para borrar campos de entrada y preparar la visualización de una autentificación. La vista de autentificación puede ser una página de inicio de sesión con entradas para nombre de usuario y contraseña.
    Listado 14. Listado 14. Función onBeforeLogin en js/auth.js
    onBeforeLogin : function(response, username, onSubmit, onCancel) {
     // clean up the input login fields
     document.getElementById("usernameInputField").value = "";
     document.getElementById("passwordInputField").value = "";
     document.getElementById("AuthInfo").innerHTML = response.responseJSON.errorMessage;
     }
  4. La función onShowLogin() o onHideLogin() (Listado 15) muestra u oculta la página de inicio de sesión. Éstas son automáticamente invocadas con base en el booleano retornado desde isLoginFormResponse. Si la autentificación es exitosa, onHideLogin será invocado. De otra manera, onShowLogin será invocado. En este ejemplo, la función onHideLogin no hace nada. En su lugar, una función de devolución de llamada signOnSuccess() es especificada para invocar el adaptador de autentificación (Listado 12). La función signOnSuccess() llama a otra función getAccounts() para cambiar la pantalla de la vista de inicio de sesión a la vista de cuentas.
    Listado 15. Listado 15. Función onShowLogin / onHideLogin en auth.js
    onShowLogin : function() {
     require([ "dijit" ], function(dijit) {
      var currentView = dijit.byId("LoginView").getShowingView();
      var currentViewId = currentView.get("id");
      if (currentViewId != "LoginView") {
       currentView.performTransition("LoginView", 1, "slide", null);
      }	
     });
    },
    onHideLogin : function() {
    }
    . . . . 
    function signOnSuccess(response) {
     getAccounts();
    }

Conclusión

Este artículo describió experiencias utilizando Worklight y Dojo Mobile para desarrollar una aplicación móvil de punto a punto. Fueron descritos los temas técnicos: la implementación de la interfaz de usuario móvil utilizando Dojo Mobile, el desarrollo del adaptador de Worklight y la autentificación en Worklight.


Agradecimientos

Agradecemos a nuestros colegas Rod Fleming y Catherine McCauley por su apoyo que nos llevó al éxito de este proyecto.


Descargar

DescripciónNombretamaño
Code sampleOFNProjectSampleCode.zip30 MB

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=WebSphere, Desarrollo móvil
ArticleID=847052
ArticleTitle=Bases para el desarrollo de una aplicación móvil de punto a punto con IBM Worklight y Dojo Mobile
publish-date=11262012