Developers need programming with native mobile frameworks

Nowadays developers need to design mobile applications. There are a lot of mobile platforms, Android, IOS and new ones like the future Ubuntu Mobile or Firefox OS, so it's pretty hard to build native mobile applications.

There is a simple solution like HTML5 but if you want to warranty the user experience you need to provide a native application per platform or either implement a version for each platform in HTML5.
That is the reason because we have implemented a framework using XML. Sometimes you have to provide an abstraction like HTML but you need an implementation for each platform. For example, using Navigation Bar in IOS or Action Bar in Android.

Providing a high language or abstraction lets to use the advantages of each operating system and extend per platform faster if you have to develop a mobile application. So here is how we suggest a possible implementation like in eMobc:

Step 1: Provide a XML to represent every element / screen (for example menus, options like rotation, themes, appearance, navigation and of course the content)
Step 2: Implement a Model for each XML so you can later load the XML in the object model to store the information.
Step 3: Use a main controller and a specific controller to implement every feature or screen.
Step 4: Use a view specific in every device (Example XIB in IOS and XML layouts in Android)

If you think this approach can be useful, you can implemnt using these steps or start contributing eMobc framework or read more about embML.

Written by Alejandro Sánchez Acosta - Managing Director eMobc

About eMobc. eMobc framework is a mobile application framework to develop apps in IOS, Android and HTML using XML. If you want to donate your code of other projects to be integrated in the project or you want to ask for a project please contact us here.

How Augmented Reality can help entrepreneurs develop mobile apps?

Technologies like augmented reality can help improve mobile applications so new products or startups can offer a new experience. 

Here we have an interview where Alejandro Sánchez, CEO of eMobc explains in the end of the video how we have used Vuforia and Alljoyn with eMobc providing a new experience to the user with Geocongress application.

Augmented reality lets match image targets like logos in the sample and provide aditional information or actions, for example show comments around the brand or create a new comment, providing a comment system around the brands. Also its possible to georeference places providing in an image target where are located.

Alljoyn also lets provide peer to peer technologies so users can communicate. Its possible to create channels where you can send messages, for example a sample room for your event.

See more about Qualcomm and eMobc in the following video:

View More Qualcomm Videos

Source: http://www.qualcomm.com/media/videos/wireless-reach-spain-csev-video-english

Developers Need Frameworks And Tools To Develop Mobile Applications

Programmers and developers who wish to create mobile applications need a plethora of resources and tools to do so. The mobile industry has expanded phenomenally and there are smart phones and tablets based on various operating systems. What anyone would need to make mobile applications is a developer framework.

A developer framework or a mobile application framework as it is also referred to, offers all the resources and tools that any programmer or developer would need to conceptualize, design and create the envisaged mobile applications.

To understand the significance of a state of the art mobile application framework, one has to look at the advantages that are in offing from a developer framework.

• A mobile application framework offers a base of all major operating systems like iOS, Android, Windows and HTML5 among others to get started with the conceptualization of the mobile applications. Without a foundation offered by a developer framework, it is almost impractical to expect a programmer or developer to get started. Having the foundations of open source operating systems or mobile interfaces, one simply has to work on the idea of the app and not the access to the system.
• Mobile applications can be easily created if one gets a mobile application framework offering various screens to build the application. To build the app, one needs a server which can be offered by a mobile application framework. It is common for a developer framework to have numerous templates for reference. Developers can refer to them and draw inspiration, customize them or have a completely new stream of imagination to create an unprecedented app design. 
• A mobile application framework helps developers to make mobile applications for specific platforms like the Android or iOS but the more intriguing attribute is that a developer framework can also help with launching the apps across various platforms like smart phone and tablet. 
• Making and launching mobile applications are only half of the entire venture. Distributing the apps and having advertisements to generate revenue is as integral to making the venture a success as the creation of the mobile applications. A mobile application framework would already have integrated ad networks and various interlinked interfaces that can help one to create and push ads which can completely change the financial dynamics of the venture. 

In a nutshell, developers and programmers can actually transform their idea into reality with the help of a mobile application framework. 

APLICACIONES NATIVAS vs HTML5

¿En qué lenguaje programar nuestra aplicación?

Esta pregunta cada vez empieza a ser más común entre desarrolladores y empresas que desean crear sus propias aplicaciones. Y es que a pesar de que HTML5 nos proporciona una aplicación multiplataforma  que funcione en cualquier sistema operativo y cualquier versión nos encontramos unas cuantas limitaciones que hacen que nuestra aplicación no consiga rendir al 100%. Podríamos decir que HTML5 esta perdiendo terreno respecto a las apps nativas. El más reciente ejemplo es el caso de Facebook.   

Declaraciones de Marc Zuckerberg, creador y CEO de Facebook:

“El mayor error que hicimos como empresa fue apostar demasiado por las aplicaciones en HTML5 en lugar de las nativas…desperdiciamos dos años. (…) Apostaremos completamente a las aplicaciones nativas en iOS y Android.”

Para responder a nuestra pregunta vamos a mostrar una comparativa entre las ventajas de una app nativa y una app en HTML5.

Aplicaciones nativas:

- En primer lugar debemos destacar que permiten explotar al máximo las prestaciones integradas en los dispositivos ya sea GPS, acelerómetro, imágenes, audio, vídeo, 3D... Aprovechamos nuestro dispositivo al 100% .

- Podemos beneficiarnos de los canales de distribución de los stores de cada plataforma. Desde el punto de vista de marketing es una característica muy importante pues nos permite difundir y promocionar mśs nuestra app, dandole opción a mucha más gente de acceder a ella. Con lo que conlleva también la actualización de la app y el uso de notificaciones push, podemos tener informado al usuario de cualquier noticia, promoción... Además contamos con que la app a pasado un control y unos requisitos impuestos por cada plataforma por lo que nos aseguramos que es compatible con nuestro dispositivo.

- Una app nativa puede funcionar sin estar conectada a la red, el modo off-line es una gran ventaja y esque permite la sincronización y el cacheo de datos para conseguir que la aplicación funcione en modo off-line. También hay que decir que HTML5 dispone de este modo pero los resultados no son del todo buenos.

- Las compras son una ventaja ya que las realizamos desde el usuario del dispositivo y no necesitamos facilitar datos de nuestra tarjeta de crédito. Es una manera de comprar mucho más fácil y más segura.

- Y por último una de las características más importante es la experiencia de usuario que se consigue con una app nativa. El rendimiento de la app es mucho más rápido y genera un menor número de basura pues se a conseguido separar la carga de datos de la de interfaz. Este es un punto fundamental para aplicaciones con mucho contenido como es el caso de Facebook, permite cargar imágenes, vídeos y cualquier tipo de contenido con mucha más velocidad que una app web. La navegación es mucho más cómoda e intuitiva. En general la aplicación aprovecha al máximo las capacidades del dispositivo.

Aplicaciones HTML5:

- La principal ventaja de desarrollar aplicaciones web es que son multiplataforma. Pueden ser visualizadas desde cualquier dispositivo móvil. Pero nos encontramos con un problema y esque el unificar todas las plataformas hace que la aplicación contenga un número elevado de limitaciones, esto hace que la usabilidad y las prestaciones de la app disminuyan.

- La programación en HTML es mucho más sencilla y se necesitan menos recursos, en cambio programar en nativo requiere mayores recursos y para cada una de las plataformas en particular.

- Estas apps no se someten a ningún control ya que no pertenecen a la plataforma, al contrario que en Android, IOS..., además las actualizaciones se establecerán automáticamente a todos los usuarios a la vez.

- La interfaz de la aplicación es completamente distinta a una nativa, esto hace que la aplicación no parezca integrada a la plataforma o dispositivo, es posible disimularlo pero los resultados no llegan a ser iguales. Por otro lado, del rendimiento tenemos que decir que que es menor y a medida que los contenidos de la app van aumentando el rendimiento de la app es menor.

Para contestar a la pregunta del principio, podemos decir que depende de las necesidades que tengamos. Si buscamos una app sencilla, rápida y económica, que sea fácil de utilizar por el mayor número de personas, nos decantaremos por una web móvil. Si lo que buscamos es una app de calidad, profesional,que ofrezca un gran rendimiento, que busque explotar al máximo el potencial y las prestaciones de nuestro dispositivo y que además este disponible en los markets para una mayor difusión necesitaremos crear un app nativa. Últimamente esta última opción es la más utilizada por las grandes empresas ya que buscan de su empresa la mejor imagen posible hacia el usuario.

En eMobc consideramos que todas las posibilidades son buenas dependiendo de la necesidad de cada uno, por lo que ofrecemos ambos servicios, web móvil y app nativa. Contacta con nosotros y solicita un proyecto. 

eMobc mobile for everyone

Aitor García 
Equipo eMobc

Cómo Crear una Nueva Pantalla en IOS

Antes de empezar con el manual de como crear una nueva pantalla en IOS, vamos a puntualizar que este manual no incluye la lógica de la pantalla sólo incluye los pasos para conseguir que nuestro framework tenga y pueda cargar una nueva pantalla.

Para crear un nuevo estilo de pantalla lo primero que tenemos que hacer es una pantalla que esté vacía, es decir, que sólo tenga lo básico para poder funcionar.

Para nuestro ejemplo vamos a tomar una plantilla que se puede corresponder con una de las pantallas básicas.

Pasos para crear una nueva pantalla de IOS en el framework:

Crear los archivos correspondientes para guardar los datos de nuestra aplicación.

Puesto que contienen los datos de la aplicación, es dentro de este fichero donde tenemos que declarar todos los datos que nuestra aplicación va a necesitar para funcionar. Estos archivos deben estar dentro de la carpeta DATA y tendrán los siguientes nombres:

*nuevaPantallaLevelData.h

*nuevaPantallaLevelData.m

Crear los nuevos niveles para nuestra pantalla.

El Level será el encargado de añadir los datos de la pantalla en el array de la clase padre, de la clase que contiene los datos de la aplicación.

En nuestro caso sólo contendrá un método (como todos los Level) que los añadirá a una lista y a un diccionario de la aplicación

Nuestros Archivos están en la carpeta LEVEL con los nombres de:

nuevaPantallaLevel.h

nuevaPantallaLevel.m

Crear el xib de nuestra pantalla.

Es decir, tenemos que crear el aspecto de nuestra pantalla. Siguiendo el razonamiento de ir copiando los archivos que dan forma a una plantilla básica bastará con copiar el mismo xib y pegarlo dentro de la carpeta XIB.

A la hora de personalizar nuestra pantalla tendremos que incluir en el xib aquellos componentes que necesitemos para crear el aspecto de la pantalla que necesitemos.

El nuevo archivo tendrá el nombre de:

NwNuevaPantallaController.xib

Crear el nuevo controlador para que dirija nuestra interfaz.

Debido a que hemos creado un nuevo xib, le tenemos que asociar a un nuevo controlador.

El controlador es quién se encarga de llevar toda la lógica de la pantalla.

Como queremos que crear una nueva pantalla tenemos que crear un nuevo controlador aunque de momento sólo vamos a copiar el controlador de la pantalla de plantilla renombrandolo para que nos quede de la siguiente manera:

NwNuevaPantallaController.h

NwNuevaPantallaController.m

Si queremos personalizar nuestra pantalla tendremos que incluir dentro de estos archivos los métodos necesarios para que la nueva pantalla se comporte como queremos.

En este punto no sólo vamos a tener que crear los ficheros de los controladores si no que le tenemos que decir al sistema que cuando cargue la Vista de nuestra pantalla cargue también su controlador.

Para ello tenemos que abrir el xib y abrir el Inspector sobre el File’s Owner.

Cuando lo tengamos abierto nos vamos a la última pestaña, Identity (comando-4) y cambiamos la pestaña de clase donde le vamos a poner el nuevo controlador que hemos creado. De esta manera lo que estamos haciendo es decirle al Owner de nuestra Vista que necesita de nuestro nuevo controlador para funcionar.

El File’s Owner es el encargado de cargar el xib. Podemos decir que es el que enlaza la parte gráfica de nuestra pantalla con la parte de código bien sea el controlador como los eventos (IBAction) y los componentes (IBOutLet)

Modificar el archivo de AppLevel.h

AppLevel contiene todos los tipos de pantalla que hasta ahora soportaba el framework, para que el framework reconozca el nuevo tipo de pantalla que estamos creando tenemos que añadir a la variable de tipo enumerado ActivityType el nuevo tipo que representará a la nueva pantalla en nuestro caso sería así:

NUEVAPANTALLA_ACTIVITY

De esta manera cuando queramos navegar hasta nuestra nueva pantalla podremos reconocerla e invocar a los métodos específicos que me indicaran el controlador a usar, el parser o el xml asociados

Ahora nos vamos a la clase nwUtil

Esta clase es la que se encarga de dado el tipo de actividad invocar al método que indica el parser a utilizar, para conseguir esta funcionalidad tenemos que seguir los siguientes pasos:

• Lo primero que tenemos que hacer es irnos a nwUtil.h y declarar un nuevo método que nos ayudará a elegir el parser adecuado para nuestra pantalla, el propio de la pantalla.
• readNuevaPantallaData
• Después de haber añadido el nuevo método en la cabecera de nuestro archivo, vamos a seguir estos dos pasos:
• Implementar el método readNuevaPantallaData, que será el encargado de cargar todos los datos del xml en la nueva pantalla (para ello para empezar y puesto que todos siguen la misma estructura, podemos copiar el método correspondiente a nuestra plantilla)
  
  

• Añadir al método readAppLevelData la opción necesaria para cuando le entre nuestro tipo de pantalla (NUEVAPANTALLA_ACTIVITY) pueda llamar al método antes implementado.
  
  

El eMobcViewController es el encargado de invocar al método adecuado para poder cambiar de nivel, es decir cambiar de pantalla y asociar el controlador adecuado.

Para conseguir que el eMobcViewController pueda llamar al controlador de nuestra nueva pantalla tenemos que crear los siguientes métodos con su correspondiente definición en la cabecera.

Puesto que la estructura de estos métodos es la misma prácticamente para todos podemos tomar los métodos correspondientes a nuestra plantilla y ajustarlos a la nueva pantalla

• Dentro de eMobcViewController tenemos que definir e implementar los siguientes métodos. Para ello y puesto que la estructura es semejante en todos podemos tomar los métodos asociados a la plantilla y cambiar aquello que sea específico a de cada pantalla.
• loadNuevaPantallaNextLevel, carga el nuevo nextLevel y su correspondiente controlador, es decir, invoca a loadNuevaPantallaController
  
  

• loadNuevaPantallaController, carga el nuevo controlador
  
  

• Para conseguir que se llame al NextLevel de nuestra pantalla y que se le asocie el controlador adecuado tenemos que modificar:
• showNextLevel, dentro de este métodos tenemos que añadir otra opción dentro del case que soporte el nuevo tipo de actividad y que cuando le entre este tipo invoque al método de loadNuevaPantallaNextLevel
  
  

Llegados a este punto tenemos que modificar el app.xml añadiendo la nueva actividad, es decir, sabemos que el app.xml es el xml que va a tener la información de todo (o casi todo) lo que puede hacer el framework.

No sólo eso sino que es al app.xml donde vamos a ir a buscar los demás ficheros xml cuando queramos cargar un nuevo nextLevel.

Debido a ello tenemos que añadir un nuevo nivel donde tenemos que indicar el nuevo tipo de actividad (NUEVAPANTALLA_ACTIVITY),el levelID, y el levelFile que será el nombre del archivo xml asociado con nuestra nueva pantalla.

Modificado el app.xml tenemos que tomar el nombre que le hemos puesto dentro de la etiqueta levelFile y crear así el xml que va a definir los datos de nuestra pantalla.

Como lo que estamos haciendo simplemente es incluir una nueva pantalla en el framework y siguiendo el procedimiento de tomar la plantilla para conseguir una rápida integración, en este caso sólo será necesario tomar el xml asociado a nuestra plantilla. Podemos llamar al nuevo xml de la siguiente manera:

• nueva_pantalla.xml

Tenemos que tener en cuenta que cuando queramos personalizar nuestra pantalla tendremos que crear un xml ajustado a sus necesidades, de tal manera que podamos definir una nueva pantalla con los datos correspondientes.

Cabe destacar que los xml no son implementados por nosotros a mano, si no que son generados por el panel de control.

Llegados a este punto y recien modificado el app y creado nueva_pantalla.xml, tenemos que modificar AppParser (asociado al app.xml) y además tenemos que crear un nuevo parser para que pueda leer el xml que tendrá nuestra nueva pantalla.

• AppParser, será el encargado de parsear app.xml por lo que si hemos añadido nuevas etiquetas (en este caso el nuevo tipo de actividad) se lo tendremos que indicar, para que cuando lo lea pueda reconocerla, así que le tendremos que añadir esta nueva constante como:
• kActTypeNuevaPantalla = @”NUEVAPANTALLA_ACTIVITY”
  
  

NuevaPantallaParser, este será el parser que esté asociado a la nueva pantalla. Debido a ello este parser tiene que contener una constante por cada etiqueta del xml que queramos reconocer, y una acción que se corresponda con la lectura del valor de la etiqueta.

Como lo que estamos haciendo es una rápida integración, bastará con copiar el parser asociado a nuestra plantilla. No debemos olvidar que si queremos personalizar la pantalla vamos a tener que crear un nuevo parser que sea capaz de leer el xml específico de la nueva pantalla. Para crearlo, tenemos que saber que todos los parser siguen una estructura fija por lo que conviene seguirla, para saber más acerca de las estructuras de los parser, ve al capítulo de Estructura de Parser.

Si hemos seguido todos los pasos anteriores y si no hemos tocado el código de todos los ficheros que hemos copiado tendremos que tener una copia de la pantalla que hemos tomado como plantilla sólo que con diferente nombre.

Para ver si realmente nuestra pantalla ha quedado integrada (aunque de momento sea una copia de otra) sólo tendremos que modificar (por ejemplo) el xml de la portada para que sea capaz de cargar como nextLevel nuestra nueva pantalla.

Aitor García

Equipo eMobc

Crear un nuevo tipo de pantalla (Android)

Si necesita crear un nuevo tipo de pantalla porque ninguna de las existentes se adapta a sus necesidades, puede crear una nueva siguiendo los pasos que se muestran a continuación:

Paso 1: Tipo de actividad

Añadir nuevo caso al enumerado ActivityType dentro del paquete com.emobc.android. El nuevo caso es el nuevo tipo de pantalla.

ACTIVITY_NAME_ACTIVITY

Paso 2: Crear y definir un XML

Es necesario definir el xml para el nuevo tipo de pantalla. Tendría que incluir todos los datos necesarios para poder construir la pantalla. Es posible reutilizar alguno existente.

Paso 3: Crear datos de la aplicación

Crear los datos que se usarán en tiempo de ejecución por la aplicación. Estos datos serán clases que almacenan toda la información contenida en los xml previamente definidos.

Las clases de datos están almacenadas en neurowork.mobile.android.fw.levels.impl.

<NAME>LevelDataItem.java

<NAME>DataItem.java

Paso 4: Añadir parser

• Crear un nuevo método dentro de ParseUtils.java para parsear el archivo xml del nuevo tipo de pantalla.
  
  

private static Map<String, Object> parse<ACTIVITY_NAME>LevelDataFile(XmlPullParser xpp)

• Añadir el nuevo caso dentro del método parseLevelDataFile en ParseUtils.java para que devuelva el nuevo parser creado ante el nuevo tipo de pantalla.
  
  

Paso 5: Añadir Activity

• Si fuera necesario, crear una nueva activity para el nuevo tipo de pantalla que herede de createMenus.
  
  

<ActivityName>Activity.java

Es posible reutilizar una activity previamente creada si se adapta a las necesidades del nuevo tipo de pantalla.

IMPORTANTE: Si se crea una nueva Activity, es necesario declararla en Manifest.xml

• Añadir el nuevo caso al método getActivityClass en AppLevel.java dentro del paquete neurowork.mobile.android.fw.levels donde se devolverá la clase de la actividad creada o la que se reutilizará.
• Crear el layout correspondiente al nuevo tipo de pantalla.
  
  

<activity_type>_layout.xml

Paso 6: Crear ActivityGenerator

• Crear el nuevo generador de pantalla para el nuevo tipo de pantalla dentro del paquete net.neurowork.mobile.fw.activities.generators
  
  

<ActivityName>Generator.java

En esta pantalla incluimos toda la lógica que queremos que tenga nuestra aplicación.

El generator utilizará el tipo de datos del paso 3 para configurar el layout del paso 5.

• Incluir este nuevo generator en la clase ActivityGeneratorFactory, en el método createActivityGenerator(), añadiendo un nuevo caso.
  
  
  Aitor García 
  Equipo eMobc

Primeros pasos desarrollo framework android

Empezar a utilizar eMobc framework

1) Descargar el framework de GitHub
https://github.com/emobc/emobc-android

Git clone
git clone https://github.com/emobc/emobc-android.git

2) Renombrar la carpeta del framework emobc-android por el nombre de vuestra aplicación, vamos a suponer que la realizaremos sobre balonmano.

3) Borrar el contenido de la carpeta assets.

4) Descargar y copiar el samples de balonmano de https://github.com/emobc/emobc-samples/tree/master/balonmano en assets

5) Renombrar el fichero de .project

Abrir eclipse e importar el proyecto

Modificar el proyecto con las versiones que tenemos de Android en local.properties y project.properties.

Mover la imagen de images/icon.png a drawable. (Generar en panel de control)
Hacer un refresh y project clean del proyecto

Por último ejecutar en la máquina virtual de Android

La documentación podéis descargarla desde nuestro repositorio de Github o desde nuestra web.


Aitor García
Equipo eMobc