18 de marzo de 2016

¿Qué son las apps híbridas?

Las aplicaciones móviles híbridas son aplicaciones desarrolladas con un conjunto de tecnologías comunes en la web como HTML, Javascript y CSS. Estas aplicaciones corren sobre un motor nativo que se encarga de mostrar el contenido visual de las mismas a través de una vista web y de comunicar al hardware del móvil con la app.

De cara al usuario las apps híbridas son iguales que las nativas, un usuario normal no va a saber diferenciarlas, de hecho le da igual, lo que quiere es que la aplicación funcione bien. Están en todas las tiendas de apps de móvil, las hay de todo tipo: juegos, periódicos, de fotografía, etc.

 Las aplicaciones híbridas se suelen crear de una manera similar a una página web, de hecho, funcionan sobre un navegador web a pantalla completa. Para crear una aplicación híbrida tienes que sentirte como pez en el agua con HTML, CSS y sobre todo con Javascript.

La mayoría de las aplicaciones híbridas están desarrolladas a día de hoy para Apache Cordova (o Phonegap, que es una distribución comercial con herramientas adicionales). Cordova tiene un sistema de plugins con una API que permite interactuar con tecnologías nativas de Android, iOS, Windows Phone, etc. Estos plugins son desarrollados por la comunidad y también pueden ser mixtos para varios tipos de tecnología móvil.

Apache Cordova es un entorno basado en línea de comandos por lo que no trae herramientas por defecto para editar un proyecto, lo bueno es que puedes editar el proyecto desde cualquier editor común de texto.

¿Por qué se usan las tecnologías híbridas? 
  • Pues en primer lugar porque HTML es una tecnología muy accesible que conocen casi todos los programadores del mundo. Es muy raro encontrar a algún profesional que no sepa moverse con el HTML.
  • En segundo lugar debido al ahorro de costes y de tiempo, con tecnología nativa tienes que hacer la aplicación casi de 0 para cada plataforma, con tecnología híbrida basta con desarrollar la app y luego compilarla para cada versión de móvil.
  • En tercer lugar por una cuestión de facilidad de mantenimiento, no es lo mismo mantener 3 versiones de un producto que mantener una, la posibilidad de errores se divide por 3 ^_^.
¿Y por qué no se usan siempre las tecnologías híbridas? 
  • Pues en primer lugar porque son más lentas que las nativas, al ejecutarse sobre navegador web cualquier tarea gráfica, o de acceso a los sensores del dispositivo será mucho más lenta ya que tiene que pasar por más capas.
  • En segundo lugar hay que tener en cuenta que tienen siempre un tiempo de retraso en adaptarse a la última versión de la plataforma nativa, por ejemplo cuando aparece la primera versión de prueba de Android la plataforma híbrida tardará algo en estar disponible para esa versión.
  • En tercer lugar porque no siempre consiguen lo que prometen en cuanto a la consistencia en tiempo de ejecución. Cada navegador de cada móvil es un mundo y no todos ejecutan igual javascript o muestran igual los CSS.
  • Y hay una cuarta razón, aunque esta no es culpa de la tecnología híbrida en sí, si no de los clientes que solicitan la tecnología híbrida para… embeber su web en una app. Apple rechazará cualquier app que sólo sea una web convertida, advertidos estáis ☺

15 de marzo de 2016

Android: El ciclo de vida de una Activity

Las actividades en Android pueden tener diferentes estados. Podemos detectar su estado desde java para ejecutar el código que consideremos conveniente en cada momento de su ciclo.

Os pongo (y me pongo) aquí un ejemplo de referencia rápido de las diferentes situaciones.

Desde onStart a onStop la actividad es visible en pantalla.

  • onCreate se ejecuta cuando se crea la actividad.
  • onStart se ejecuta a continuación de onCreate una sola vez.
  • onRestart se ejecuta cuando ejecutamos la actividad después de volver de onStop.
  • onResume se ejecuta cuando el usuario vuelve a interactuar con la pantalla en primer plano.
  • onPause se ejecuta cuando la aplicación entra en pausa al no estar en primer plano.
  • onStop se ejecuta cuando se sale de la aplicación pero continúa en segundo plano
  • onDestroy cuando se cierra la aplicación


public class MainActivity extends ApplicationContext {
     protected void onCreate(Bundle savedInstanceState);

     protected void onStart();

     protected void onRestart();

     protected void onResume();

     protected void onPause();

     protected void onStop();

     protected void onDestroy();
 }

29 de febrero de 2016

Android: Detectar si tu móvil Android está cargando su batería

A la hora de ejecutar ciertos scripts de código en tus aplicaciones te puede interesar saber si el móvil Android está conectado a la red eléctrica o no (ya sea vía enchufe, usb o batería externa) ya que ciertos procesos pueden consumir mucha batería y si el móvil se apaga las consecuencias pueden ser poco deseables.

Para detectar si el móvil está cargando o no podemos usar este código:

boolean isPlugged= false;
Intent intent = context.registerReceiver(null, new IntentFilter(Intent.ACTION_BATTERY_CHANGED));
int plugged = intent.getIntExtra(BatteryManager.EXTRA_PLUGGED, -1);
isPlugged = plugged == BatteryManager.BATTERY_PLUGGED_AC || plugged == BatteryManager.BATTERY_PLUGGED_USB;
if (Build.VERSION.SDK_INT > Build.VERSION_CODES.JELLY_BEAN) {
    isPlugged = isPlugged || plugged == BatteryManager.BATTERY_PLUGGED_WIRELESS;
}
Podéis clonarlo desde esta url de mi Git en BitBucket: https://gabicuesta@bitbucket.org/socialprotools/ischarging.git

1 de febrero de 2016

Android: Comprobar si el usuario ha autorizado los permisos del Manifest a partir de la API 23

Desde la API 23 Google va a obligar a las aplicaciones a solicitar la autorización expresa del usuario para poder acceder a datos sensibles como por ejemplo la localización del usuario.

Hasta ahora bastaba con agregar los correspondientes permisos al manifest de la app, cuando el usuario se instalaba la app se le informaba simplemente. A partir de esta API y a imagen y semejanza de lo que hace iOS desde su versión 8 la app debe solicitar expresamente al usuario durante la ejecución el acceso a estos datos.

Para ello el primer paso es comprobar si tenemos o no el permiso ya concedido, por ejemplo:

if (ContextCompat.checkSelfPermission(context,
        Manifest.permission.ACCESS_FINE_LOCATION)
        != PackageManager.PERMISSION_GRANTED) {

}


En este caso estamos comprobando si tenemos el permiso de acceso para determinar la localización más cercana, muy importante pasar el contexto adecuado a la variable context. En concreto en esta comparación nos aseguramos de no tener ese permiso para a continuación solicitarlo:

ActivityCompat.requestPermissions(this,
        new String[]{Manifest.permission.ACCESS_FINE_LOCATION},
        MY_PERMISSIONS_REQUEST_ACCESS_FINE_LOCATION);

MY_PERMISSIONS_REQUEST_ACCESS_FINE_LOCATION es una constante que hay que declarar del siguiente modo al inicio:

public static final int MY_PERMISSIONS_REQUEST_ACCESS_FINE_LOCATION = 0;

Ahora nos toca ver que hacemos si nos conceden o no el permiso:

@Overridepublic void onRequestPermissionsResult(int requestCode,
                                       String permissions[], int[] grantResults) {
    switch (requestCode) {
        case MY_PERMISSIONS_REQUEST_ACCESS_FINE_LOCATION: {
            // If request is cancelled, the result arrays are empty.            if (grantResults.length > 0                    && grantResults[0] == PackageManager.PERMISSION_GRANTED) {

                // permission was granted, yay! Do the                // contacts-related task you need to do.
            } else {

                // permission denied, boo! Disable the                // functionality that depends on this permission.            }
            return;
        }

        // other 'case' lines to check for other        // permissions this app might request    }
}

Espero que os haya sido de utilidad.


21 de enero de 2016

iOS: Indentificando como único un dispositivo

La política de Apple para identificar dispositivos es a día de hoy muy restrictiva, no te dejan identificar un dispositivo por IMEI y por UDID, de hecho han bloqueado los accesos a estos datos desde hace unas cuantas versiones de iOS.

A día de hoy la única manera de identificar de manera única a un dispositivo facilitada por Apple es con el Identificador de Publicidad del dispositivo, pero este se puede resetear desde el móvil y además sólo está permitido usarlo si muestras publicidad en tu app, si no te la rechazarán cuando subas la aplicación a la tienda.

Nos toca por tanto recurrir a soluciones propias y rezar para que Apple no detecte en su proceso de revisión que estás identificando como único a ese dispositivo, tarea necesaria cuando no solicitas al usuario que tenga una cuenta en tu servidor.

En mi caso lo que hago es generar un identificador único y lo grabo como una preferencia de usuario, así nadie puede borrarlo salvo que desinstales la app.

Os pongo aquí el método:
- (NSString*)getGUIDString {
    CFUUIDRef newUniqueID = CFUUIDCreate(kCFAllocatorDefault);
    CFStringRef newUniqueIDString = CFUUIDCreateString(kCFAllocatorDefault, newUniqueID);
    NSString *guid = (__bridge NSString *)newUniqueIDString;
    CFRelease(newUniqueIDString);
    CFRelease(newUniqueID);
    return([guid lowercaseString]);
}
Y aquí el código para guardar el dato como preferencia de usuario:
NSString *userGuid = [[NSUserDefaults standardUserDefaults] stringForKey:@"guid"];
if(!userGuid.length>0){
    NSString *guid = [self getGUIDString];
    [[NSUserDefaults standardUserDefaults] setValue:guid forKey:@"guid"];
    [[NSUserDefaults standardUserDefaults] synchronize];
}
Espero que os sea útil.

5 de enero de 2016

Como evitar que tu app sea una App Zombie

Las tiendas de aplicaciones de Apple y de Android están llenas de aplicaciones que nadie usa, aplicaciones sin descargas que pasan sin pena ni gloria al olvido. Estas aplicaciones son conocidas como Apps Zombies, hay millones de ellas, y su número crece cada día.

Obviamente no queremos que nuestras aplicaciones terminen así, ¿Cómo podemos evitarlo?

  1. ASO (App Store Optimization): Cuando publicas una app debes mimar al máximo los metadatos de la misma en las tiendas de Apple y de Google. Debes optimizar la elección del nombre de la app, su descripción, sus traducciones, las imágenes que pones y el vídeo de publicidad que te permiten ambas.
  2. Valoraciones de los usuarios: Consigue que los usuarios valoren tu app y dejen su opinión en la tienda, para ello es ideal el uso de recordatorios dentro de la aplicación con un acceso directo a valorar tu app.
  3. Blogs: Consigue que hablen de tu aplicación en la blogosfera, además de las descargas directas a través de los posts conseguirás en el caso de Google y Android subir en la tienda.
  4. Redes Sociales: Los usuarios tienen que hablar de tu app con sus conocidos, ponles fácil compartir contenidos interesantes que generen conversación. Asegúrate de tener presencia en Facebook, Twitter, Instagram, etc..., genera una conversación interesante alrededor de tu app.
  5. Publicidad: Sí, toca invertir dinero, tanto en publicidad en otras apps, como en publicidad en Google y redes sociales. También funciona bastante bien el intercambio de banners.
  6. FFF (Family, friends & fools): Familia, amigos y tontos, es decir, que todos los seres humanos que tengas a tu alcance sepan de tu app, la prueben, te den su opinión, evangelicen a los demás sobre ella y sobre todo... que no se la desinstalen, eso penaliza mucho.
  7. Feedback: Escucha a tu comunidad, deja el ego a un lado y escucha con atención para mejorar tu app.
  8. Actualizaciones: Actualiza tu app, aprende del feedback, de FFF y de las redes sociales, una app es un proyecto vivo, no vale con sacar una primera versión y echarte a dormir, hay que ir mejorándola.
  9. Planifica: El cementerio está lleno de proyectos de "genios" que tenían todo el plan en su cabeza. Contrasta los planes con gente de confianza abriendo bien los oídos y las orejas, los liderazgos de macho alfa de discoteca nunca llevan los proyectos a buen puerto.
Seguro que desde tu experiencia puedes aportar más puntos, desde mi experiencia estos son los consejos básicos que os puedo ofrecer :)

20 de diciembre de 2015

Star Wars: El despertar de la fuerza

Bueno, pues ayer vi la película Star Wars: El despertar de la fuerza y me entretuvo, no me alucinó, pero me entretuvo, que ya es algo.

La película tiene ritmo, todo el rato pasan cosas, no hay más de dos minutos seguidos sin que haya un momento de acción. A diferencia de la Amenaza fantasma no es una película infantiloide, es una película divertida para toda la familia, pero no con niños monos poniendo caras adorables.

Es una película sin rollo político, a diferencia de la trilogía anterior que era muy grandilocuente esta es una película de aventuras pura y dura sin mayores pretensiones, y creerme, se agradece.

Pero ha perdido gran parte de la magia de la saga, como película es efectiva pero no tiene peso para ser digna de recordar, es como comer palomitas, te las comes mientras duran y a los 5 minutos de terminar ni te acuerdas de ellas.

A nivel de banda sonora falta una pieza sonora propia digna de recordar, es una banda sonora efectiva pero que no tiene un tema principal que se te quede grabado.

A nivel de mezcla de sonido en la versión española en castellano no ha quedado del todo bien, por lo menos en el cine en que la vi yo por momentos el sonido era demasiado estridente y tapaba algunos diálogos.

En cuanto al guión pues no hay mucho desarrollo de personajes, pero can simpáticos. La nostalgia la justa, pero por ahí anda. En cuanto al merchandising es menos obvio que en las 2 primeras precuelas, no están vendiendo todo el rato cosas.

En fin, una película entretenida, sin más, y sí, iré a ver la segunda parte cuando salga en el cine, a ver si le meten un poquito más de desarrollo de personajes que es la pega más grande que le veo.

Es mi opinión, ya sabéis que hay gustos para todo :)