Archive for the ‘Navegador’ Category


Me gustan los comics, pero más me gusta coleccionarlos. Es decir, tener la certeza de que tengo las series completas y verificar la secuencia de los mismos: no hay nada mas satisfactorio que saber que completaste una serie. En el mundo Cómic muchos apuestan por el tema digital, pero creo que el cómic impreso tiene para largo, porque la sensación es distinta al del libro, quizá sea porque en un cómic hay mas tinta y sangre puesta.

Desde que Peru21 empezó a publicar su serie de cómics a precio accesible, empecé con este hobbie al punto que puedo decir que tengo todas sus publicaciones. Otras editoriales empezaron como Editorial VUK, Skull Editores, Med Comics y después de todos estos años puedo decir que he pasado por la experiencia completa del coleccionista. Es por eso que me puse a trabajar en una aplicación que ya está lanzada el día de hoy: SuperComics como una forma de facilitar la experiencia del coleccionista.

¿Cuál es la experiencia del coleccionista? Pues en estos puntos los resumo:

  • Cronograma: Si sabes cuando van a publicarse tus cómics, se hace más fácil estar al día. Es tan crítico, porque de lo contrario tendrías que estar dando vueltas a la tienda o al kiosco a cada rato y si bien hay ahora algunas tiendas especializadas en cómics, no es fácil darse un tiempo para visitarlas. Con un cronograma se puede controlar cuáles cómics ya tienes y cuáles te faltan.
  • Inventario: Debes poder llevar un control de los cómics que ya tienes. La clásica es que te compras el cómic en un kiosco, y por ahí que caíste por el centro comercial arenales y te diste una vuelta por las tiendas de cómics, viste una carátula interesante y te la compras para darte cuenta en tu casa de que ya la tenías. Llevar la cuenta es clave.
  • Lista de compras: A pesar de los cronogramas, siempre sucede de que te faltó comprar un cómic, o que por esas cosas, perdiste alguna y necesitas reponer así que tendrás que ir a la tienda, kiosco, feria o evento donde esté la editorial. Tendrás que ir apuntando correctamente cuáles son los cómics que te faltan en una lista, aunque para evitar confusiones, tienes que llevar la carátula.
  • Tiendas: como ya dije hay algunas tiendas de cómics que van surgiendo, y algunos kioscos se han comprado el pleito de ofrecer cómics. Personalmente, hay una señora en Jesús María que incluso me guarda los cómics para no perder ninguno, y cruzando la calle hay otra tienda super caleta que te venden el mismo cómic con tu bolsicartón gratis y en bolsita, super cool. Lo malo es que si no conoces, estos lugares te los pasas sin darte cuenta. Otro ejemplo era la tienda de Perú 21 en el centro de Lima, donde podías comprar los cómics atrasados y encima el encargado te regalaba los posters de promoción, hasta ahora los tengo en su tubo porque ya me falta pared para colgarlos.

Finalmente, falta una que es el intercambio, porque si eres coleccionista, seguro que tienes repetidos que puedes cambiar o vender.

En la versión 2 de mi aplicación ofrezco las 4 primeras experiencias de tal forma que sea más fácil empezar a coleccionar, o para los que ya llevan algo de tiempo, controlar su colección más fácilmente.

La prioridad es saber lo que hay en este momento publicado y que ya se puede comprar. Por eso la pantalla de inicio comienza justamente con esos cómics:

screen01

screen14

Los 10 últimos cómics publicados se podrán ver en un carrusel, y si haces click en la portada verás todos los datos del mismo, así como la carátula completa.

screen01 screen09

Puedes ver el logo y el nombre de la colección, alguna nota importante, luego la carátula completa y si deslizas hacia abajo verás la información del cómic y sobre todo 3 botones:

  • Nola: marcas este botón si ya tienes el cómic, de tal forma que cuando regreses, podrás ver que ya lo tienes, porque habrá cambiado a “Yala”, como hacías con las figuritas de tu álbum.
  • Comprar: Si es que quieres comprar este cómic, al marcar este botón se agregará a tu lista de compras, de tal forma que los tendrás a la mano cuando vayas a la tienda. El botón se cambiará a “Lista” cuando hayas agregado el cómic.
  • Social: Podrás compartir orgulloso la carátula del cómic y sacarle pica a tus amigos de que ya lo tienes o que te gustó. Este botón te dará la opción de compartir la carátula en las redes sociales que tengas instalado en tu equipo.

Desde aquí, podrás ir casi a donde quieras:

  • Regresar al inicio: Para ver nuevamente el carrusel de comics recién publicados
  • ¿Que otros títulos tiene esta serie?: Al costado del nombre de la colección hay un punto blanco con una flecha hacia arriba. Haciendo click ahí, podrás ver la lista completa de títulos en esa seríe, al menos los que ya han sido anunciados. En algunos casos, la editorial publica un cronograma completo y podrás ver la serie completa con fechas de publicación y todo. Algo como esto:

screen15

Donde podrás ordenarlos o buscar en los títulos. El botón blanco con la flecha esta vez te llevará hacia la pantalla de la editorial:

screen06

Donde verás las otras series publicadas por esta casa, también con la opción de ordenar y buscar.

Ahora prestemos atención a los 4 botones de la parte de abajo:

  • Novedades: Es una sección secreta del app donde estarán los cómics últimos registrados. O sea que puede que aún no estén disponibles en tiendas. Si la editorial la ha anunciado con anticipación, la encontrarás en esta sección.

screen13

  • Catálogo: Encontrarás otro carrusel con los logos de todas las editoriales que publican localmente, ya sea directamente o a través de algún socio. Es el caso de editoriales gringas como Marvel, Dc, Image, Dark Horse, donde sus títulos son publicados por editoriales locales. Igual, si por ejemplo quieres ver donde está “The Walking Dead” la podrás encontrar tanto en Image como en Editorial Vuk, lo mismo para los otros títulos.

screen04 screen05 screen16

  • Compras: Si es que le diste a comprar en algún cómic, aquí es donde podrás ver tu lista de compras. De esta manera no vas a necesitar llevar tu papelito o acordarte de memoria cual querías comprarte. Después que te compres el cómic, no olvides de desmarcarlo para mantener tu lista de compras ordenada.

screen17

  • Tiendas: ¿Quieres saber donde comprar tus cómics? Pues en esta sección verás algunas de las tiendas que más se dedican al tema, y por supuesto, también he puesto el kiosco en Jesús María donde siempre compro los mios. Personalmente les recomiendo este lugar porque suele tener muchos de los números antiguos sobre todo los de Peru21. Podrán ver las tiendas en una lista, pero también en un mapa.

screen11 screen12

Inicialmente, sólo estaban incluidos cómics o “grapa” como se le dice en la jerga, pero gracias a la amabilidad de Skull Editores, ya se ha incluido su colección de Spawm que es un TPB con 4 números en cada volúmen. En la medida que reciba la información de las demás editoriales, las estaré incluyendo.

Y con esto terminamos las funciones que se pueden ver, ahora veamos las funciones que no se pueden ver:

  • Actualización automática: Salió un nuevo cómic o una editorial acaba de anunciar una nueva serie?. No te preocupes que la aplicación se actualizará automáticamente, sin que te pregunte ni nada.
  • Uso de datos: Ok, actualizar automático es cool, pero consume el saldo si no hay wifi. No te preocupes. Cuando descargues el app, viene incluida la última versión de la base de datos, lo que significa que descargarás solamente la nueva información, la cual es de mas o menos 24K por cómic. Saca tu línea: Si se publican 10 cómics en un día, recibirás una actualización de aprox 240 a 260K, casi nada. Además, si es que te quedaste sin saldo, igual podrás utilizar el app, y hacer de todo, menos el mapa que es la única función en línea. La opción Social también funcionará siempre con Whatsapp, ya que se puede usar sin saldo, Facebook te dirá que no puede subir la foto y las demás si te dirán que no tienes red.

En el futuro se vienen cosas interesantes:

  • Backup de la base de datos: Imagina que ya repasaste todo el catálogo y le diste Yala a todo. Sería una pena perder todo eso porque cambiaste de equipo. Pronto podrás hacer un backup de eso y tenerlo disponible para seguir controlando tu colección.
  • Integración con Facebook: Podrás compartir mas cosas en Facebook desde el mismo app.Además, con esto te podrás identificar de tal forma que puedas recuperar el backup de tu colección.
  • Intercambio/Venta de cómics: ¿Tienes cómics repetidos? ¿Te falta algún cómic? Podrás publicarlo y conectarte con los demás que estén en la misma situación.

La publicación en Google Play Store debe estar en unas dos semanas lista o antes. Con Apple, esto puede tomar algo más de tiempo. Con Windows Store para WP8, voy a demorar un poco más pues Microsoft está en transición así que esa versión me está demorando y si sale esa, podría también estar la versión para Windows 10.

Comentarios y sugerencias en este post, o también al correo del app en supercomics@supermio.com.pe


Microsoft acaba de anunciar su nueva línea de equipos que marcan una tendencia clara en el tema de la computación móvil, ya no estamos atados a una PC. La PC ha muerto. Como siempre, la computación podríamos separarla en empresarial y de consumo.

En el mundo empresarial, el tema es claro, los teléfonos Lumia pueden ser estaciones de trabajo que el trabajador se puede llevar a su casa. De aquí en adelante, la solución empresarial pasará por lo potente que sea la herramienta de gestión y lo potente que sea una nube empresarial que gestione la información crítica. Las PCs ya pasaron a la historia. Teniendo en cuenta que tablets con full Windows 10 home ya están disponibles, incluso pequeñas cajitas que solo requieren de un monitor, podríamos esperar unas cajas parecidas corriendo Windows 10 Pro o Enterprise. Ahora, si es posible tener esa caja convertida en un teléfono, mucho mejor, mientras que se pueda controlar la seguridad de ese teléfono dentro de mis herramientas del dominio.

Al teléfono podríamos asignarle un grado de movilidad 1, ya que puedo trabajar en el mismo dispositivo y cuando quiera ser más productivo, podría ponerle un monitor, teclado y mouse. El problema es que esas cosas no están botadas por todas partes. Podría tener uno de esos en la oficina y otro en mi casa y ya no necesito PC.

El siguiente nivel es la tablet, o lo que hoy conocíamos como la línea Surface que tenía una versión Pro, ahora es simplemente Surface y es una tablet super delgada que tiene un teclado accesorio que le añade un trackpad multitouch, un lector de huellas y el mejor teclado portátil al día de hoy. Además, tiene un docking station que permite conectarle puertos USB adicionales, dos monitores y hasta un puerto Ethernet, que nuevamente puede usar un monitor externo y convertirse en una PC regular. La novedad aquí es el stylus que es simplemente lo que hacía falta para competir contra Apple porque tiene un muy pequeño parallax (lo que escribes se ve en la pantalla en el punto preciso que tocas), sensor de presión y hasta diferentes puntas como las que hay en los lápices reales. Han pensado hasta en el borrador y en el magneto que lo mantiene pegado al tablet cuando no está en uso. Es tan delgado que puede ser un reemplazo a nuestras libretas físicas del día de hoy sin problema.

Al tablet le damos movilidad 2, porque si bien podemos usarla como tablet y como laptop, la unión magnética del teclado y la tablet no ha cambiado por lo que se hace algo complicado trabajar si no tienes una mesa. Es lo mismo que se comentaba con el primer modelo de Surface lanzado al mercado.

La novedad mayor es la introducción de Surface Book que es una laptop con un concepto que no es nuevo pero que no tuvo mucho eco cuando Asus sacó su modelo transformer que tenía un teclado que le daba batería y disco adicional. En este caso, Surface book es una full laptop de 13 pulgadas que además es una tablet tal como el Surface regular, pero que incluye un teclado rígido que guarda un GPU Nvidia que le da un empujón cuando se trabaja en modo laptop. A un precio base de 1500 USD estamos hablando de una laptop que se vende como laptop, pero que no deja de lado la experiencia de su nivel inferior tipo Tablet note taker. Con una batería que ofrece 12 horas de duración promedio, estamos hablando de la primera laptop diseñada por Microsoft que se pone delante de la competencia en un segmento que Microsoft creó desde nada y que yo llamé Ultra Convertible.

A la laptop le damos la movilidad 3 porque puede ser utilizada en cualquier entorno gracias a su teclado rígido que es un accesorio obligatorio.

Pues bien, el problema ahora es que comprar.

Para la casa nos podría bastar la experiencia del teléfono pero quizá muchos opten por la opción tablet, lo que haría que el teléfono se vuelva en algo redundante, o tal vez podríamos considerar como una segunda PC.

Para la oficina, muchas de las estaciones podrían ser reemplazadas por teléfonos, o por cajas (que las consigues por menos de 100 USD) donde solo agregas Pantalla y teclado/mouse. Para experiencias mas top se puede usar la tablet, y los que requieren alta productividad se van con el tablet.

Para el super goloso, el laptop es la única opción.

El tema es que pasa cuando quieres subir. Para muchas de las tareas rutinarias, la experiencia teléfono tiene la potencia necesaria, pero la capacidad escribir en pantalla y un teclado puede ser el killer feature de Microsoft estas fiestas, por lo que para tareas comunes, el tablet será el equipo para la mayoría.

Si fuera Apple, tendríamos que decidir entre tablet o laptop, entre iOS y Mac OSX, pero con Microsoft esto no sucede ya que todos los equipos ejecutan Windows 10 con excepción del teléfono, pero han hecho un gran trabajo con lo que llaman aplicaciones Universales que permiten que las herramientas que necesitamos funcionen igual tanto en el teléfono como en la tablet y también en la laptop, Windows 10 mobile es exclusivo de los teléfonos ahora lo cual suena bien, porque en un teléfono queremos tener una batería de duración super larga.

Microsoft tiene en Windows 10 la llave para conquistar el mercado de computación personal y con estos nuevos equipos parece que tomará el liderazgo en el segmento de computadores móviles después de mucho tiempo, donde el mayor mérito está en crear un segmento nuevo y sorprender a los otros dos grandes como son Apple y Google y a la primera reacción de éstos, ganarles con no sólo un equipo sino con una estrategia, al punto que incluso sus competidores utilizar uno de los componentes de la estrategia como es Office 2016. Incluso en precios, parece que ni iPad Pro ni Pixel C podrán contra el Surface 4 Pro.

Espero que me caiga del cielo una Surface Book, que ya se puede pre ordenar con el modelo top of the line en 2700 USD. Dado que es un accesorio debería ser más fácil para Microsoft sacar teclados de distintos idiomas, el mayor problema con laptops Windows al día de hoy.


Esta es una continuación de la serie sobre desarrollo en móviles que comencé aquí. Les recomiendo comenzar a escribir el código fuente desde la parte 1 ya que no se publica el código para descarga.

En este punto debemos hacer un repaso y considerar algunos puntos que potencian la aplicación.

Primero, comencemos que el código está disponible en Github en la siguiente dirección:

https://github.com/victorpease/SuperDatos

Para que comiencen a verlo funcionar tendrán que seguir los siguientes pasos:

  1. Crear una cuenta en cloudant.com
  2. Crear una base de datos
  3. Crear una key en la sección de permisos y asignarle permisos de Writer
  4. Actualizar la key y la clave en el archivo services.js
  5. Actualizar la url de la base de datos también en el archivo services.js

Con esto ya podrán tener funcionando su propio lector de noticias y verán que cada vez que alguien lea una noticia, un registro será añadido a la base de datos y podrán con esa información hacer reportes sobre las noticias más populares, que luego podremos incluir como un reporte en la misma aplicación.

Bien, ahora los consejos:

  • Hasta ahora hemos considerado la sincronización Live, pero tengan en cuenta que genera mucho tráfico y por lo tanto costo, además, el cobro es por transacción, así que no importa mucho el tamaño de la base de datos. En Cloudant dan gratis un saldo de 50 dólares y eso es bastante, pero para una aplicación seria esto se puede salir de control. Lo mejor es que desactiven Live y que sincronicen manualmente cuando ocurra algún evento relevante. Para que vean la diferencia, Live sincroniza datos cada 25 segundos, así que si cambian que la sincronización sea cada 1 minuto, ya estarían bajando su consumo a la casi la mitad.
  • Si pensamos en este modelo “Offline-First”, es porque no confiamos en el acceso a la red. El mayor impacto es la primera sincronización. Piensen en usar el plugin PouchDB Load, que permite que hagan una carga inicial de datos en el móvil en lugar de esperar los datos de la red. El archivo de texto tiene que ser generado mediante el plugin PouchDB Dump Cli.
  • En el código actual tenemos un estado llamado Splash donde podemos ejecutar todas estas acciones  de inicialización antes de entrar a la aplicación.

Sobre las vistas:

  • Las vistas en PouchDB se generan la primera vez que las llamamos, por lo que pueden demorar un poco mas de lo normal durante la primera vez. Ante esto, pueden controlar que la vista se genere de forma automática sobre todo durante la primera sincronización mediante la siguiente línea:
    pouch.query('vista', {stale: 'update_after'});
  • Hasta ahora hemos usado Map/Reduce para las vistas, y puede ser algo confuso. La alternativa principal es utilizar los índices, no hay nada mas simple y más rápido. La otra alternativa es utilizar PouchDB Find, que es el futuro de las consultas en todo el ecosistema CouchDB. Personalmente, aun me gusta más Map/Reduce aunque sea algo confuso y limitado por una razón: PouchDB Find es simplemente una máscara que hace las cosas fáciles, pero no agrega velocidad.
  • Finalmente, ya les había mencionado que las vistas ocupan sitio

Sobre los límites de espacio:

  • PouchDB maneja varios métodos para almacenar los datos siendo WebSQL (sqlite) y IndexedDB los disponibles en los móviles, estando igualmente sujetos a las restricciones de espacio del navegador del sistema. Aquí pueden revisar los límites . Un truco es utilizar el plugin SQLite que les permite saltarse esos límites y tener un almacenamiento casi ilimitado. Entiendan que esto es solamente recomendado cuando su base de datos esté por los 50 mb. Además, aún tiene algunos problemitas con las vistas.
  • IndexedDB es la alternativa estándar, de hecho WebSQL ya no es mantenido. De hecho es bastante rápido, además que IndexedDB no es tan fácil de abrir que WebSQL, así que les da un nivel de seguridad a los datos.

Sobre la seguridad:

  • Los que utilizan SQLite en Android están acostumbrados a ponerle una clave a la base de datos para protegerla. Esto no está disponible en el modelo Híbrido pero pueden usar el plugin Crypto Pouch que nos permite encriptar los datos.
  • CouchDB tiene usuarios y Cloudant también puede manejar algo parecido. Pueden acceder a esta lista de usuarios mediante el plugin PouchDB Authentication. Recuerden que esto significa que la red es necesaria. Personalmente, prefiero hacer un servicio externo que autentique y que distribuya las key y pass de Cloudant.

Modelamiento:

  • Modelar en NoSQL no es igual que en Relacional, pero hay trucos. Personalmente, prefiero el modelo minimalista de NoSQL pero existe un plugin Relational Pouch que permite utilizar la misma estructura relacional

Finalmente, como verán en algún comentario que hice, pueden tener toda su lógica en la aplicación cliente, siempre y cuando se quieran pegar al modelo “Offline-First”, pero si es que necesitan operaciones en línea, necesitaran de una capa más de lógica.

NOTA Principal: El problema principal con CouchDB y obviamente con Cloudant, es como integrarlo con nuestras bases en SQL. Es un trabajo en progreso en realidad, y no hay una herramienta porque en CouchDB el modelamiento está en función de la velocidad y de la aplicación que va a utilizar los datos, y eso puede ser muy diferente a lo que tenemos en SQL donde se programa para tener consistencia. Hay tantos modelos y tantas transformaciones posibles que una herramienta no puede hasta ahora hacer el trabajo. Felizmente, no es tan complicado porque ya en la base de datos hemos usando db.changes() , Así que el flujo sería:

  • Lenguaje recomendado: Python ( tiene una gran librería de acceso a Cloudant). También pueden usar NodeJS
  • Un script accede a la base de datos SQL y crea los documentos en Cloudant uno por uno según el modelo que hayamos fijado. Podemos cruzar dos tablas para crear documentos Maestro-Detalle siempre que no sean muchos detalles. No es tan rápido y lo ideal es usar BulkDocs para insertar por lotes.
  • Luego se invoca el comando db.changes()  donde cada documento cambiado es actualizado a la base de datos. Otra vez, puede ser como un insert, delete o update, todo depende de como sea su modelo.

Hasta ahora, todo esto es a medida por lo que mejor es que practiquen sus habilidades en NodeJS o Python.


Esta es una continuación de la serie sobre desarrollo en móviles que comencé aquí. Les recomiendo comenzar a escribir el código fuente desde la parte 1 ya que no se publica el código para descarga.

Me he tomado algo de tiempo para escribir este post por una simple razón: es hora de limpiar el código. Hasta ahora el código que han ido desarrollando es funcional pero tiene cosas que les va a crear problemas cuando quieran hacer algo mas grande. Lo bueno en todo esto es que si han ido cambiado el código desde el post 1, entonces estos cambios les harán mucho sentido. La buena noticia en todo esto, es que puedo publicar todo el código sin problemas.

Comencemos con el archivo app.js:


angular.module('starter', ['ionic','controller','service'])
.run(function($ionicPlatform) {
$ionicPlatform.ready(function() {
// Hide the accessory bar by default (remove this to show the accessory bar above the keyboard
// for form inputs)
if(window.cordova && window.cordova.plugins.Keyboard) {
cordova.plugins.Keyboard.hideKeyboardAccessoryBar(true);
}
if(window.StatusBar) {
StatusBar.styleDefault();
};
});
})
.config(function($stateProvider, $urlRouterProvider) {
$stateProvider
.state('app',{
cache:false,
abstract: true,
views:{
"home":{
templateUrl:"templates/menu.html",
controller:"menuController as menu"
}
},
resolve:{
cats: function(db){
return db.getCats();
}
}
})
.state('app.news', {
cache:false,
url: "/:catId",
views: {
"menuContent":{
templateUrl: "templates/news.html",
controller: "newsController as news"
}
},
resolve:{
noticias:function($stateParams,db){
return db.getNews($stateParams.catId);
}
}
})
.state('app.detail', {
cache:false,
url: "/detail/:id",
views: {
"menuContent":{
templateUrl: "templates/detail.html",
controller: "detailController as detail"
}
},
resolve:{
noticia: function($stateParams,db){
return db.get($stateParams.id);
}
}
});
$urlRouterProvider.otherwise('/');
})

Empecemos poniendo atención en la definición de los estados a partir de la línea 14.

  • Si tenemos un estado que muestra datos que cambian muy seguido en la base de datos, lo mejor es desactivar el cache. Eso lo hacemos mediante el atributo “cache:false” como pueden ver en la definición de cada estado.
  • Los datos es mejor cargarlos en la definición del estado. Esto se traduce en la utilización del atributo “resolve” donde verán que hacemos la llamada al servicio que recupera los datos y los pasa mediante una variable al controlador. Podrán ver que un estado puede recibir parámetros y estos nos sirven para recuperar los datos llamando a los servicios.
  • $ionicPlatform.ready() es muy importante. Conforme nuestro proyecto crezca, notarán que hará falta inicializar algunos componentes o plugins de Cordova. Cordova es el core de todo esto y la noticia es que se demora en cargar, por lo que si tenemos que inicializar algún componente o plugin propio de Cordova tienen que ponerlo dentro de esta función pues se ejecuta cuando ya es un hecho que Cordova ya está cargado.

Ahora nos toca ir a revisar el archivo controller.js


angular.module('controller',['service'])
.controller('menuController',
['$scope',
'$state',
'cats',MenuController])
.controller('newsController',
['$scope',
'$state',
'noticias',NewsController])
.controller('detailController',
['$scope',
'$state',
'noticia',DetailController]);
function MenuController($scope,$state,cats){
$scope.cats = cats.rows;
};
function NewsController($scope,$state,noticias){
$scope.notas=noticias.rows;
$scope.$on('db:changed',
function(event,changed){
$state.go('.', null, { reload: true });
console.log('Recargando noticias');
});
};
function DetailController($scope,$state,noticia){
$scope.event= noticia;
$scope.$on('db:changed',
function(event,changed){
$state.go('.', null, { reload: true });
console.log('Recargando Noticia');
});
};

Aquí si hay varias cosas para revisar. Primero, si bien no hay reglas a la hora de programar, si existen buenas prácticas y la mejor que he encontrado es esta: Angular Style Guide, así que apliquemos algunas reglas.

  • La primera es lo que se llama IIFE. Considerando que el app.js es el archivo principal, tanto controller.js como service.js deben tener todo el código contenido en una estructura como esta:
    • (function(){ … })(); En nuestro caso, hemos incumplido esto para simplificar la explicación, pero pueden agregarlo y verán que el código funciona sin problemas.
  • Verán que las definiciones de cada controlador ahora es algo diferente y es por dos razones:
    • Dependency injection: Esto es casi un formalismo, es decir, la podríamos saltar sin problema pero nos costará cuando usemos herramientas para comprimir nuestro código o para cuando querramos empaquetar nuestro código para evitar copiones. Si se fijan el primer controlador, verán que primero indicamos todos los componentes, entre comillas, que vamos a utilizar dentro del controlador, y luego, tenemos una función como parámetro final sin comillas. Finalmente la función es definida al final incluyendo como parámetros todos los componentes que vamos a usar ya sin comillas.
    • Siguiendo las sugerencias de estilo, el código de cada controlador es ahora puesta en una función aparte a fin de facilitar la lectura del código
  • La base de datos puede cambiar. Para esto tienen que pensar mucho en como diseñar sus estados. En cada controlador he incluido un $scope.$on para recibir el evento $broadcast con el nombre ‘db:changed’ que ya veremos exactamente cuando se genera pero básicamente es que cuando se detecte un cambio en la base de datos debemos refrescar los datos, en nuestro caso, hemos elegido volver a correr el estado mediante la línea $state.go() que vuelve a correr el código.
    • Algo es super importante: Cuando refrescan un estado, el estado padre no se refresca, pero si vemos bien en nuestro caso, el controlador del estado padre no tiene nada de código para refrescar. La clave aquí es que el estado padre se trata de un estado abstracto y estas si se refrescan junto con los estados hijos. Es por eso que basta con refrescar los estados hijos.

Nota final, hay casos en los que su vista no requiera refrescar datos a cada rato, así que evalúen activar el cache o que el refresco de los datos venga de algún evento como un click en algún botón, o un cambio de estado. Refrescar automágicamente cuesta.

Ahora veamos el service.js


angular.module('service',[])
.factory('db',['$q','$rootScope',DbService]);
function DbService($q,$rootScope){
var key = 'bentareadyessharyinessee';
var pass = 'OnEixgKgpt8LyEtl0S5DkAon';
var remote = 'https://'+key+':'+pass+'@supermio.cloudant.com/news';
var db;
function changed(change){
console.log('cambios en la base de datos');
$rootScope.$broadcast('db:changed',change);
};
return {
init: function(){
if (!db) db = new PouchDB('news');
this.replicate();
return true;
},
replicate: function(){
if (!db) this.init();
db.replicate.from(remote,
{live:true,
retry:true})
.on('paused',function(changes){
changed(changes);
});
},
get: function(id){
if (!db) this.init();
return db.get(id);
},
getCats: function(){
if (!db) this.init();
return db.allDocs(
{startkey:'cat_',
endkey:'cat_\uffff',
include_docs:true});
},
getNews: function(catId){
if (!db) this.init();
if (catId)
return db.query('news/topic',
{key:[catId],
include_docs:true,
descending:true});
else return db.allDocs({startkey:'news_\uffff',
endkey:'news_',
descending: true,
include_docs:true});
}
}
};

  • Cuiden la replicación.
    • En la línea 20 verán que iniciamos la replicación  y con el atributo “live” y esto nos garantiza que los cambios se pasan casi instantáneamente pero como todo en la vida, tiene costo, así que consideren tenerlo apagado y encenderlo cuando haga falta. El siguiente atributo “retry” se refiere a que la replicación continúe luego de una falla en la red, tenganlo siempre en true, pero no se confíen.
    • Al encender la replicación podemos especificar eventos. En nuestro caso en la línea 23 encendemos el soporte del evento “paused” que se refiere a que la replicación “live” ya no recibe nuevos cambios, así que podemos decir que la base de datos remota y local son iguales. En nuestro caso, este es un buen momento para refrescar las vistas. Hay otro evento que es “change” que se genera con cada cambio que se recibe, lo cual es bueno pero no tanto porque si refrescamos aquí, tendríamos ejecutando el refresco muchas veces, sobre todo para la corrida inicial y nuestra base de datos local está vacía. Luego utilizaremos estos eventos para crear notificaciones locales.
  • Cuídense de los procesos asíncronos. Todos los métodos en el servicio “db” son iguales en una cosa: todos son asíncronos. Tal como les recomendé, usen los estados en el archivo app.js para llamar a estos métodos y se librarán de la pesadilla de javascript llamada “Promesas”. Ya luego veremos como manejar promesas.

Y listo, todos los demás archivos van iguales y en lineas generales podrán ver que el código está más limpio y ordenado, además, estamos llamando todos los datos directamente desde la base de datos.

Nota final: en lo que se refiere a performance, el consejo básico es que diseñen su app para que no tenga que refrescar automáticamente nada de nada, a menos que sea absolutamente necesario por la simple razón que si bien PouchDB es una buena base de datos, puede volverse bastante pesada si tienen que lidiar con una gran cantidad de datos. Refrescar datos por eventos es la mejor estrategia.

Como podrán ver, no han habido nuevas funciones que hayamos incluido, pero al menos hemos mejorado el código y espero que los consejos y el estilo de programación mostrado aquí les sirva para organizar su código en algo que puedan mantener y entender con facilidad.


Esta es una continuación de la serie sobre desarrollo en móviles que comencé aquí. Les recomiendo comenzar a escribir el código fuente desde la parte 1 ya que no se publica el código para descarga.

En la parte 8 dejamos el app con menus que permiten mostrar las noticias por categorías, pero faltaba cargar las categorías directamente de la base de datos, de tal forma que se vayan mostrando automáticamente las categorías nuevas.

Las categorías serán extraídas de la base de datos en una consulta bastante simple y debemos considerar lo siguiente:

  • Debemos poder establecer el orden en que se muestran las categorías. Para eso deberíamos agregar un campo que nos permita establecer el orden.
  • Debemos poder desactivar las categorías. Para eso también agregaremos un campo que indique el estado

Ok, hagamos esto primero entonces, felizmente tenemos pocas categorías. Para ejemplo, veamos como quedaría “cat_01”:


{
"_id": "cat_01",
"_rev": "2-df694a2ed157b1403baa2ca9214d801b",
"nombre": "Nacional",
"descripcion": "Noticias del país",
"tipo": "topic",
"orden":1,
"estado":1
}

Lo mismo para todas las demás categorías. Con estos cambios, consultaremos las categorías, las ordenamos por el campo orden y las filtramos por el campo estado.

Ahora para hacer la consulta tenemos dos alternativas:

  • Usando la clave principal: Todas las categorías tienen un id que comienza con “cat_” entonces podemos usar la clave por defecto. El orden será el orden de las claves: cat_01 luego cat_02 y así, igual podemos ordenarlo al mostrarlo.
  • Creando una vista: estaremos creando un índice solamente para recuperar categorías, ¿valdrá la pena? pues son pocas categorías así que aún no vale la pena ir por este camino.

Listo, ahora empieza lo complicado. Necesitamos que la lista de categorías sea pasado al estado inicial para que pueda ser mostrado. Recordemos que hemos definido un estado abstracto para incluir el sidemenu. Como en el ejemplo anterior, pasar datos a un estado requiere el uso de “resolve”, eso es fácil, lo  complicado es que tenemos que hacer la consulta a la base de datos para obtener esas categorias. Si revisan el archivo app.js, por ninguna parte hago alguna llamada al factory “db” que contiene todas nuestras operaciones por lo que si llamamos alguna operación de datos en el “app.js” simplemente fallarán porque acuerdense que inicializamos la factory db con el método db.init()  en el controlador “newsController” en la línea 8 del archivo “controllers.js” como pueden ver aquí:


.controller('newsController',function($scope,db){
db.init();
$scope.notas=[];
$scope.$on('refrescar',function(event,news){
$scope.$apply(function(){
$scope.notas = news;
})
})
})

Esto nos funcionó en su momento, y como ya podrán darse cuenta, es una mala práctica inicializar las cosas en un controlador. Incluso llamar a un inicializador puede resultar malo. Así que comenzaremos modificando el archivo “services.js” para dos cosas:

  • Ejecutar la rutina init() cuando haga falta y no tener que llamarla en ningún lugar. De esta manera simplemente llamaremos a las consultas y siempre tendremos la db lista.
  • Agregar el método para consultar las categorias

El primer paso es fácil: simplemente agregamos estas líneas al comienzo de cada método:


if (!db) {
this.init();
}

Simple, preguntamos si la variable interna es nula o no, y ejecutamos el método init() cuando haga falta. Agregamos eso a todos los métodos del factory.

El segundo paso también es simple, al igual que el método “mostrar” usamos el método allDocs así:


getCats: function(){
if (!db) {
this.init();
}
return db.allDocs({startkey:'cat_',endkey:'cat_\uffff',include_docs:true})
}

Con tanto cambio, el archivo services.js. quedará así:


angular.module('services',[])
.factory('db',function($rootScope){
var key = 'bentareadyessharyinessee';
var pass = 'OnEixgKgpt8LyEtl0S5DkAon';
var remote = 'https://'+key+':'+pass+'@supermio.cloudant.com/news';
var db;
var cat;
var mostrar = function(){
db.allDocs({startkey:'news_\uffff',endkey:'news_',descending: true,include_docs:true})
.then(function(result){
$rootScope.$broadcast('refrescar',result.rows);
});
};
var mostrarCat = function(catId){
if (catId)
db.query('news/topic',{key:[catId],include_docs:true,descending:true}).then(function(result){
$rootScope.$broadcast('refrescar',result.rows);});
else mostrar();
};
return {
init: function(){
if (!db) {
db = new PouchDB('news');
}
mostrarCat(cat);
this.replicate();
},
replicate: function(){
if (!db) {
this.init();
}
db.replicate.from(remote,{live:true,retry:true})
.on('paused',function(info){
mostrarCat(cat);
});
},
get: function(id){
if (!db) {
this.init();
}
return db.get(id);
},
setCat: function(id){
if (!db) {
this.init();
}
cat = id;
mostrarCat(cat);
},
getCats: function(){
if (!db) {
this.init();
}
return db.allDocs({startkey:'cat_',endkey:'cat_\uffff',include_docs:true})
}
}
});

Y listo, ahora vamos al archivo “app.js” donde vamos a agregar el resolve al estado abstracto:


.state('app',{
abstract: true,
views:{
"home":{
templateUrl:"templates/menu.html",
controller:"menuController as menu"
}
},
resolve:{
cats: function(db){
return db.getCats();
}
}
})

Agregamos la llamada al nuevo método y la pasamos al controlador a través de la variable “cats”. No se olviden de que, ya que estamos llamando a un factory definido en el modulo “services”, tenemos que agregarlo como dependencia. Así que la primera línea de nuestro “app.js” será ahora así.


angular.module('starter', ['ionic','controllers','services','ui.bootstrap'])

Y listo, terminamos con este archivo. Ya terminamos actualizando el modelo, ahora toca el controlador. Aquí simplemente tenemos que recoger la variable cats con las categorias y quitar cualquier llamada a “db.init()”. El controlador “menuController” quedaría así:


.controller('menuController',function($state,$scope,db,cats){
$scope.cats = cats.rows;
$scope.setCat = function(id){
$state.go('app.news');
db.setCat(id);
};
})

Acuérdense que cuando llamamos a la base de datos obtenemos un objeto y dentro de ese objeto el array “rows” nos trae los registros que queremos.

Ahora así quedaría el controlador “newsController”:


.controller('newsController',function($scope){
$scope.notas=[];
$scope.$on('refrescar',function(event,news){
$scope.$apply(function(){
$scope.notas = news;
})
})
})

Como ven, sólo le hemos quitado la llamada a “db.init()”. Y con esto hemos acabado con el controlador y vamos a arreglar la vista en el archivo “menu.html”. Si se fijan en la línea 25 comienza una lista donde todos los valores son estáticos y va hasta la línea 38. Reemplazamos todo eso por un iterador y quedaría así:


<ion-list>
<ion-item collection-repeat="cat in cats | orderBy: 'doc.orden'| filter:{'doc':{'estado':1}}" nav-clear menu-close ng-click='setCat(cat.id)'>
{{cat.doc.nombre}}
</ion-item>
</ion-list>

Cosas interesantes aqui:

  • Collection-repeat es propio de Ionic y es más eficiente en listas largas
  • El array cats es el que metimos en el $scope desde el controlador y tiene todas nuestras categorías.
  • Mediante “orderBy” las ordenamos por el campo “orden” que agregamos.
  • Y mediante “filter” mostramos solamente los que tienen estado =1

Todo lo demás viene del template anterior, incluso para llamar al método “setCat” llamamos al cat.id.

Y listo!, Si prueban el código hasta aquí funcionará, pero hay algunas limitaciones:

  • Si agregan una categoría en el servidor o se cambia el orden de alguna, no se refresca en la lista del menú automáticamente
  • Al inicio se mostrarán todas las noticias, incluidas las que pertenezcan a categorías inactivas

Esas las veremos en el siguiente post. Lo que si es urgente es corregir el estilo del código, siendo el más urgente el que figura en el controlador “detailController” donde verán que tenemos una llamada a db.get y esperamos por la respuesta. Si se habrán dado cuenta, para las categorías es lo mismo pero no esperamos por respuesta en ningún lado, simplemente esperamos valores y ya, así que usemos ese patrón aquí y corrijamos el controlador para que se vea así:


.controller('detailController',function($scope,db,noticia){
$scope.event=doc;
});

y tendríamos que cambiar el resolve de la ruta en el archivo “app.js” para que se vea asi:


resolve:{
noticia: function($stateParams,db){
return db.get($stateParams.id);
}

Y listo. La explicación para este cambio es que como casi todo en JavaScript es asíncrono, tenemos que usar un modelo llamado “promesas” para esperar por la respuesta y hacer algo con eso. Es por esto que usamos objeto.then() y dentro del then() incluimos una función con una operación. Pues bien, al momento de utilizar estados, el componente detrás de toda esa magia (UI-Router!!!) hace muchas cosas bien, y una de esas cosas es manejar la resolución de las promesas y es tan inteligente que esperará hasta que la promesa sea resuelta y podamos recibir los documentos en el controlador. Con eso nuestro código queda mas limpio.

Promises es todo un tema y siempre es un motivo de confusión así que mejor dejar que sea UI-Router quien las maneje. Así que para que se diviertan notarán que para cargar las noticias para la categoría seleccionada podemos usar el mismo esquema anterior. A ver si pueden completarlo por su cuenta.

NOTA: Ya un lector notó que todo es sobre leer datos en el cliente y tiene una razón. Grabar datos es bien simple pero supone que tengamos mucho cuidado durante el diseño, porque si dejamos escribir a un usuario, debemos tener en cuenta que cualquier usuario podrá hacerlo a menos que pongamos un control. Establecer un control requiere de cierto manejo adicional que aún falta explicar. Para que lo vean en perspectiva: 

  • Cualquiera puede escribir:
    • No hace falta establecer usuario y pass al inicio
    • Se debe tener cuidado de no duplicar el id del documento que se vaya a grabar
    • La replicación debe modificarse, porque si hay muchos usuarios, estaremos recibiendo muchos cambios y datos en nuestra db local.
  • Todos usuarios registrados pueden escribir:
    • Hay que incluir usuario y pass
    • También la replicación se tiene que ajustar para controlar los datos entrantes.
  • Sólo algunos usuarios registrados pueden escribir:
    • Usuario y clave es obligatorio
    • Hay que determinar quien puede escribir y quien no. Podemos integrar la autentication propia de CouchDB para determinar esto, pero esto aplica a todos los documentos, lo cual no necesariamente es bueno.
    • La replicación también se modifica pero ya es más simple

Recuerden que más importante que empezar a construir es sentarse a diseñar.


Esta es una continuación de la serie sobre desarrollo en móviles que comencé aquí. Les recomiendo comenzar a escribir el código fuente desde la parte 1 ya que no se publica el código para descarga.

Bien, con lo desarrollado en la parte 07 ya tenemos una aplicación funcional que filtra los datos por categoría, pero no está completa pues faltaría una forma de poder elegir la categoría mediante un menú. En Ionic Framework, tenemos una librería de controles interesantes, y para nuestro caso, vamos a utilizar el side menú. Para eso tenemos que hacer la introducción de un concepto nuevo: estado abstracto.

Un estado abstracto es un estado utilizado para cuando lo que se quiere hacer es mostrar una parte del UI que es común para otros estados. Pensemos en que un estado abstracto es un marco donde podremos poner logos y cabeceras, e incluso poner cierta lógica y que tiene una zona donde otros estados podrán mostrar información.

Primero, comencemos cambiando nuestra configuración de estados en el archivo app.js:

.config(function($stateProvider, $urlRouterProvider) {
    $stateProvider
        .state('app',{
            abstract: true,
            views:{
                "home":{
                    templateUrl:"templates/menu.html",
                    controller:"menuController as menu"
                }
            }
        })
        .state('app.news', {
            url: "/",
            views: {
                "menuContent":{
                    templateUrl: "templates/news.html",
                    controller: "newsController as news"
                }
            }
        })
        .state('app.detail', {
            url: "/detail/:id",
            views: {
                "menuContent":{
                    templateUrl: "templates/detail.html",
                    controller: "detailController as detail"
                }
            },
            resolve:{
                detail: function($stateParams){
                    return $stateParams.id;
                }
            }
        });
        $urlRouterProvider.otherwise('/');
    });

Como pueden ver, hemos agregado un estado en la línea 17 donde el primer atributo es uno nuevo: abstract:true, lo que significa que éste será nuestro estado abstracto que servirá para colocar el side menu.
Una vez que hemos agregado el estado abstracto, ahora hay que indicar a los otros estados que deben tener como estado “padre” al estado “app”. Para eso, simplemente le añadimos “app.” al nombre de cada estado, con eso basta para indicar la dependencia. Fijense como ha cambiado el nombre en la línea 26 y en la línea 35.
Otro punto importante que deben notar es que hemos cambiado el valor del atributo “views” en la definición de cada estado en las líneas 29 y 38. Inicialmente, habíamos indicado que el estado sea mostrado en la vista “home” ahora le estamos diciendo que utilice la vista “menuContent”, puesto que estos estados serán mostrados dentro del estado abstracto, tendremos que indicar una vista definida dentro del estado abstracto. Veremos esto más claro al definir la vista para el menú.

En la configuración de estados hemos indicado que hay un controlador para el estado abstracto, así que agreguemos el controlador al archivo controllers.js:

angular.module('controllers',['services'])
	.controller('menuController',function(){
	})

Por ahora lo mantendremos así sin código.
Ahora agreguemos un template para el menú que hemos definido como el archivo menu.html

<ion-side-menus enable-menu-with-back-views="true">
    <ion-side-menu-content>
        <ion-nav-bar class="bar-stable">
            <ion-nav-buttons side="right">
                <button class="button button-icon icon ion-android-exit " ng-click="salir()"> Salir
                </button>
            </ion-nav-buttons>
            <ion-nav-buttons side="left">
                <button class="button button-icon button-clear ion-navicon" menu-toggle="left">
                </button>
            </ion-nav-buttons>
        </ion-nav-bar>
        <ion-nav-view name="menuContent"></ion-nav-view>
    </ion-side-menu-content>

    <ion-side-menu expose-aside-when="large" side="left">
        <ion-header-bar class="bar-stable">

<h1 class="title">Noticias</h1>

        </ion-header-bar>
        <ion-content>
<div align="center">
                <img width="50" src="img/ionic.png">Categorias
            </div>
            <ion-list>
                <ion-item nav-clear menu-close>
                    Nacional
                </ion-item>
                <ion-item nav-clear menu-close>
                    Internacional
                </ion-item>
                <ion-item nav-clear menu-close>
                    Espectáculos
                </ion-item>
                <ion-item nav-clear menu-close>
                    Opinión
                </ion-item>
            </ion-list>
        </ion-content>
    </ion-side-menu>
</ion-side-menus>

El componente sidemenu tiene dos partes: el side-menu y el side-menu-content, en nuestro ejemplo, hemos definido primero el side-menu-content donde podrán ver en la línea 13 que hemos definido la vista “menuContent” donde se mostrarán los demás estados dependientes.
En la línea 16 hemos definido el side-menu que es el menú propiamente que aparecerá a un costado. En este caso hemos definido que el estado se muestre a la izquierda “side=left” y que si la pantalla es muy ancha entonces el menú se muestre desplegado por defecto, si la pantalla es angosta, el menú se esconderá a la espera que hagamos un “swipe” o hagamos click en el botón de tres líneas que aparecerá.

Para resumir, tenemos ahora varios niveles de estado:
– Index.html define la vista “home”
– En la configuración de estados, pintamos el estado abstracto “app” definido en el archivo “menu.html” en la vista “home”
– Menu.html define la vista “menuContent”
– Todos los demás estados se hacen dependientes del estado app y serán mostrados en la vista “menuContent”.

El resultado es algo parecido a esto:
Con la pantalla ancha tipo tablet.

menuA

Con la pantalla angosta

menuB01 menuB02

Si hacemos click a una noticia podemos ver como se sigue mostrando dentro del mismo marco. También notarán que la lista de categorías está puesta manualmente y además no hacen mucho. Para no extender mucho el post, primero hacemos que el menú funcione.

Primero revisemos el estado original de nuestro servicio que controla los datos (services.js)

angular.module('services',[])
.factory('db',function($rootScope){
    var key = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx';
   var pass = 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx';
   var remote = 'https://'+key+':'+pass+'@server.cloudant.com/news';
   var db;
   var mostrar = function(){
        db.allDocs({startkey:'news_\uffff',endkey:'news_',descending: true,include_docs:true})
                    .then(function(result){
                    $rootScope.$broadcast('refrescar',result.rows);
                });
    };
    var mostrarCat = function(catId){
        db.query('news/topic',{key:[catId],include_docs:true,descending:true})
                    .then(function(result){
                    $rootScope.$broadcast('refrescar',result.rows);
                });
    };
    return {
        init: function(){
            if (!db) {
                db = new PouchDB('news');
            }
            mostrarCat("cat_01");
            this.replicate();
        },
        replicate: function(){
            db.replicate.from(remote,{live:true,retry:true})
                .on('paused',function(info){
                mostrarCat("cat_01");
            });
        },
        get: function(id){
            return db.get(id);
        }
    }
});

NOTA: En la línea 14 estoy incluyendo una corrección : he cambiado el parámetro “startkey” por “key”. La diferencia es que “startkey” se usa para cuando se quiere establecer un rango, por lo que “cat_01” con el parámetro descending true devolverá sólo “cat_01”, mientras que “cat_04” mostrará también “cat_03”, “cat_02” y “cat_01” lo que no buscamos. Con “key” solamente se devolverán los valores iguales al id de categoría.

Podemos ver que estamos pasando “en duro” la categoría 1 como parámetro para mostrar, por lo tanto tenemos que crear una variable miembro para almacenar este valor, cosa que al seleccionar un elemento del menú su valor se cambie para mostrar las noticias correspondientes. Por defecto mostraremos todas las noticias y tendremos que agregar un método para actualizar la variable de categoría y refrescar la vista. En el archivo services.js, empecemos agregando la variable cat:

angular.module('services',[])
.factory('db',function($rootScope){
        var key = 'bentareadyessharyinessee';
        var pass = 'OnEixgKgpt8LyEtl0S5DkAon';
        var remote = 'https://'+key+':'+pass+'@supermio.cloudant.com/news';
        var db;
        var cat;

Luego agregamos el método que llamaremos “setCat”

get: function(id){
    return db.get(id);
},
setCat: function(id){
    cat = id;
    mostrarCat(cat);
}

Ahora, tenemos que eliminar las llamadas de mostrarCat con la categoría “en duro”

return {
    init: function(){
        if (!db) {
            db = new PouchDB('news');
        }
        mostrarCat(cat);
        this.replicate();
    },
    replicate: function(){
        db.replicate.from(remote,{live:true,retry:true})
            .on('paused',function(info){
            mostrarCat(cat);
        });
    },

Finalmente, si mostrarCat recibe un valor nulo o vacio debemos mostrar todas las noticias.

var mostrarCat = function(catId){
    if (catId)        
    db.query('news/topic',{key:[catId],include_docs:true,descending:true})
                .then(function(result){$rootScope.$broadcast('refrescar',result.rows);});
    else mostrar();
};

Con eso ya arreglamos el modelo, ahora vamos al controlador en el archivo controllers.js.

angular.module('controllers',['services'])
	.controller('menuController',function($state,$scope,db){
		$scope.setCat = function(id){
			$state.go('app.news');
			db.setCat(id);
		};
	})

Aquí estamos usando una nueva entidad $state que nos va a permitir llamar a un estado.
Ahora, en la vista tenemos que llamar a la función del controlador al momento de hacer click. Como tenemos las categorías “en duro”, seguiremos indicando las claves “en duro”, así que modificamos el archivo menu.html para incluir los links que llamen a la función $scope.setCat(id):

 <ion-list>
     <ion-item nav-clear menu-close ng-click='setCat("cat_01")'>
       Nacional
     </ion-item>
     <ion-item nav-clear menu-close ng-click='setCat("cat_02")'>
       Internacional
     </ion-item>
     <ion-item nav-clear menu-close ng-click='setCat("cat_03")'>
       Espectáculos
     </ion-item>
     <ion-item nav-clear menu-close ng-click='setCat("cat_04")'>
       Opinión
     </ion-item>
</ion-list>

Lo que hemos hecho es agregar la propiedad ng-click para que se ejecute la funcion setCat(id) definida en el controlador tal como lo dijimos.

Y listo. Por ahora tendremos el siguiente comportamiento:

  • La aplicación mostrará todas las noticias al cargar
  • Al hacer click en una categoría, se mostrarán solamente las tareas relacionadas

En el siguiente post veremos como cargar las categorías directamente de la base de datos y ya no “en duro”. Ya saben si encuentran algún error, me avisan.


Esta es una continuación de la serie sobre desarrollo en móviles que comencé aquí. Les recomiendo comenzar a escribir el código fuente desde la parte 1 ya que no se publica el código para descarga.

Ayer mencioné que iba a publicar un nuevo post para contestar una pregunta que recibí en la semana. Notarán el post sobre tips para rendimiento donde la moraleja resumida es que preocuparse por la velocidad de PouchDB contra Sqlite es detenerse en el arbol en lugar de apreciar todo el bosque.

La primera pregunta que recibí fue sobre como hacer para recuperar una lista de objectos y luego recuperar los detalles de un objeto en particular. Como en cualquier correo, tienen la lista de correos y cuando hacen click en uno en particular, verán el contenido en otra ventana. Este mecanismo es la perfecta introducción al concepto de estados que Ionic soporta mediante la inclusión de UI-Router.

Primero hagamos un poco de orden en el código que dejamos en la parte 2 de esta serie. Para los que recién llegan, no hay un download del código, así que vayan a la Parte 1 para que hagan el código paso a paso con el post.

Como podrán ver, tenemos el código todo regado en el archivo app.js lo cual esta mal. Lo que yo suelo hacer es tener un archivo para los controladores (controller), otro para los servicios (service, factory) y dejamos el app.js lo más limpio posible. Esperen!!, services y factories es algo que no había mencionado hasta ahora. Así que toca un poco de introducción.

Los que venimos del mundo de cliente/servidor y objetos y todo eso recordaremos que solíamos tener un super objeto casi global para ciertas tareas que estaba corriendo todo el tiempo esperando que le pidamos cosas. Si es que necesitábamos mantener la consistencia de sus operaciones, entonces declarábamos este objeto como un Singleton y listo, estabamos seguros que todas las operaciones las podíamos verificar antes de mandarlas. Pues eso en el mundo de AngularJS lo encontramos en las estructuras Service y Factory. ¿Cuál usar? Personalmente yo utilizo Factory la mayor parte del tiempo, pero Service también debería hacer el trabajo. La diferencia principal es que Factory es un Singleton y Service no, nada mas.

Comencemos por el mas fácil, pongamos todos los controladores en un módulo:

angular.module('controllers',[])
.controller('newsController',function($scope){
	$scope.notas=[];
	$scope.$on('refrescar',function(event,news){
		$scope.$apply(function(){
			$scope.notas = news;
		})
	})
})

Llamemos a este archivo controllers.js y pondremos aquí todos los demás controladores que nos hagan falta.

Ahora, para que el cambio sea completo, hay que cambiar tanto el app.js y el index.html.

angular.module('starter', ['ionic','controllers'])

Esta es la única línea que cambia del archivo app.js. Simplemente le estamos diciendo a AngularJS que el módulo App.js llamado ‘starter’, tiene una dependencia adicional llamada ‘controllers’.

<!DOCTYPE html>
<html>
 <head>
 <meta charset="utf-8">
 <meta name="viewport" content="initial-scale=1, maximum-scale=1, user-scalable=no, width=device-width">
 <title></title>
 <!-- compiled css output -->
 <link href="css/ionic.app.css" rel="stylesheet">
 <!-- ionic/angularjs js -->
 <script src="lib/ionic/js/ionic.bundle.js"></script>
 <!-- cordova script (this will be a 404 during development) -->
 <script src="cordova.js"></script>
 <!-- your app's js -->
 <script src="js/controllers.js"></script>
 <script src="js/app.js"></script>
 <script src="lib/pouchdb/dist/pouchdb.js"></script>
 </head>

En el caso de index.html, hemos agregado la línea 14 donde le indicamos que tiene que cargar el archivo controllers.js con nuestros controladores. Y listo, ya tenemos algo mas de orden.

Ahora nos toca ordenar la base de datos. Lo ideal sería tener un objeto que esté siempre disponible gestionando las llamadas a la base de datos, por lo que aplica a ser un Service o un Factory. Prefiero un factory como ya les había dicho así que esto quedaría en un módulo de la siguiente manera.

angular.module('services',[])
.factory('db',function($rootScope){
    var key = 'bentareadyessharyinessee';
	var pass = 'OnEixgKgpt8LyEtl0S5DkAon';
	var remote = 'https://'+key+':'+pass+'@supermio.cloudant.com/news';
	var db = new PouchDB('news');

    return {
        init: function(){
            db.replicate.from(remote,{live:true,retry:true})
                .on('paused',function(info){
                db.allDocs({startkey:'news_\uffff',endkey:'news_',descending: true,include_docs:true})
                    .then(function(result){
                    $rootScope.$broadcast('refrescar',result.rows);
                });
            });
        }
    }
})

Llamaremos services.js a este archivo y como podrán ver es un Factory que publica solamente un método llamado init. Este método tenemos que invocar para que se inicie el manejo de la base de datos. Si queremos simplificar nuestro archivo de controladores quedará así:

angular.module('controllers',['services'])
.controller('newsController',function($scope,db){
 db.init();
 $scope.notas=[];
 $scope.$on('refrescar',function(event,news){
 $scope.$apply(function(){
 $scope.notas = news;
 })
 })
})

Notarán que en la línea 1 se ha agregado el módulo services como dependencia y en la línea 3 estamos llamando al método init del Factory db.

Y el app.js quedará así:

angular.module('starter', ['ionic','controllers'])

.run(function($ionicPlatform,$rootScope) {
  $ionicPlatform.ready(function() {
    // Hide the accessory bar by default (remove this to show the accessory bar above the keyboard
    // for form inputs)
    if(window.cordova && window.cordova.plugins.Keyboard) {
      cordova.plugins.Keyboard.hideKeyboardAccessoryBar(true);
    }
    if(window.StatusBar) {
      StatusBar.styleDefault();
    }
  });
})

Comparado con el desorden que teníamos al principio ahora todo se ve más ordenado. Pero lo mas importante es que podemos centrarnos en escribir servicios o factories de forma general y reutilizarlos en otros proyectos simplemente copiando los archivos, lo mismo con controladores.

Una sugerencia final es que según estuve leyendo, esto de separar el código en controladores y servicios es bueno, pero no sirve si nuestro proyecto crece demasiado. La solución es la de hacer la separación por funciones de nuestro app y dentro de cada función poner los controladores y servicios separados en archivos. Esto lo veremos mejor cuando incluyamos el concepto de estados.

Continuaremos en otro Post porque el tema de estados es muy importante entender el concepto antes de programar.

NOTA: Soy muy flojo programando, así que hacer todo esto paso a paso lo hago para combatir este defecto. Así que para notar que este esfuerzo vale la pena, les pido que sigan el tutorial desde la parte 1, si les paso el código para que lo copien simplemente no vale ni mi esfuerzo ni ustedes tampoco van a entender.


Durante todos estos años como programador, mi mayor problema siempre ha sido la instalación de software y si es Open Source con mayor razón. Si eres un programador me entenderás que eso de fijar variables de entorno, copiar archivos, modificarlos es una jarana criolla en Barrios Altos. Incluso, hasta hace unos años era cool decir “voy a hacer una partición linux” para probar ciertos programas. Hoy eso queda huachafo.

La solución hasta hace un par de años, o incluso menos, era la de hacer máquinas virtuales con tu VMWare o Virtual Box si eras misio (pero no por eso con menos funciones). Simple, cuando querías algún otro sistema operativo prendías la máquina virtual y listo, instalabas ahí todo lo que querías probar. Para los que enseñaban Oracle, esta era la opción pues comenzaban la clase, hacían destrozos en su VM y luego regresaban a la versión original y listo para el siguiente turno.

Para las empresas, también las máquinas virtuales ayudaron a aprovechar el hardware mucho mejor. La lección aprendida es que una PC, Servidor o cualquier tipo de computador no utiliza el hardware a plenitud a menos que se lo exijas, y con una sola aplicación no lo vas a lograr a menos que estés programando a bajo nivel. Con las máquinas virtuales eso se hizo más simple y  permitió ahorrar mucha plata a pesar de que aún hay gente que les tiene miedo.

La cosa no queda ahí. El año pasado de la nada recibí un correo presentando un proyecto llamado Dockers que no tiene nada que ver con pantalones. Después de muchas pruebas puedo decir ahora que es lo que faltaba tanto para programadores como para administradores: La posibilidad de crear entornos aislados donde una aplicación pueda correr, casi como una VM pero para una aplicación en particular. El día de hoy ya veo porque tiene cada vez mas empresas apoyando esta tecnología incluso grandes como Google.

Primero tratemos de ver en forma simple de que se trata Dockers. Primero pensemos en una app que puede ser Java. Para que funcione bien hemos aprendido todos estos años que hay que fijar primero el Entorno, es decir, las rutas y variables indicando donde están los archivos principales y los valores que indiquen que version de Java estamos usando. Para muchos esto queda oculto pues le dan al instalador en Windows y no hacen nada mas. Los verdaderos programadores de Java en cualquier plataforma han tenido que fijar su entorno para lograr trabajar sin problema. Con el entorno fijado, ahora hay que asegurar que estamos usando la versión correcta del SDK  para compilar los programitas y también verificar la versión del runtime. Y, finalmente para casos extremos ya teníamos que fijarnos que ciertos puertos estuvieran disponibles para cosas raras como JMX o JMS o probar un servidor HTTP. Todo esto era algo que tomaba casi 1 día en configurar y probar para recién empezar a programar o para publicar nuestra aplicación en producción.

En resumen: Entorno, Archivos y Red.

En una VM no hay problema porque es como tener una máquina limpia para una sola aplicación, pero ya vemos que es casi un desperdicio a pesar de que podemos controlar la asignación de recursos. Aquí es donde entra Dockers. ¿Qué tal si en lugar de 1 máquina nos dan 1 usuario totalmente limpio para nuestra aplicación? Ya sabemos que los entornos de ejecución de cada usuario son totalmente independientes con excepción de los servicios y la configuración de red. Lo principal aquí es que una app ejecutada bajo el usuario Juan no se puede tumbar a otra app que se ejecuta bajo el usuario Andrés a menos de que se trate de un bug muy feo.

Docker hace eso, crea una máquina virtual en tu máquina y crea un usuario para cada “VM” que quieras usar y le agrega un administrador de archivos y de configuración de red de tal forma que tu solo tienes que acceder a tu app a través del un IP virtual en tu máquina y un puerto. Genial. Esto significa que si quieres jugar con entornos como Nginx, Yii2, Node.js y demás que están fuertemente ligados a entornos ya no necesitas tener un entorno con variables PATH gigantes, pero lo mas importante, ya no vas a configurar tu entorno nunca mas.

La cosa no queda ahí nomás. Docker provee un registro o biblioteca de “Contenedores” que no son más que aplicaciones ya configuradas listas para usar. Por ejemplo, por alguna razón Couchbase no me funciona en Windows, después de varios días de prueba me puse Dockers y bajé un contenedor con Couchbase ya listo y funcionando en menos de 5 minutos, en un par de comandos. Lo mismo en Mac OSX, pues como saben viene con su propio PHP y hay casos como YII2 que requiere de un PHP mas reciente, después de meses de fallar, le puse Docker al Mac y el contenedor Yii2 y listo en 5 minutos. Para un entorno productivo el proceso tendría que ser mas o menos igual, con la diferencia que habría que fijar los volúmenes de seguridad y configurar un poco mas a medida la maquina virtual host y todo eso, pero lo mas pesado ya no sería problema.

Ahora, Docker no es para todo tipo de aplicaciones. Básicamente, Docker es para servicios del lado del servidor que puedan ser publicados de forma “headless”. En cristiano, si tu app del lado de servidor se instala tipo Windows, ya fuiste. La cosa es que la instalación del servicio se pueda hacer mediante la simple copia y configuración de archivos, algo que para el mundo UNIX es algo normal. Además, se debe tener en cuenta que Docker utiliza un sólo “HOST” virtual donde pone a todos los contenedores, y por ahora ese HOST corre Linux. No creo que pase mucho para que Microsoft haga algo al respecto.

Por mientras, hay una serie de funciones adicionales que tiene Docker que hay que revisar como es la gestión de volúmenes a fin de hacer cosas interesantes como “Contenedores” redundantes apuntando a un mismo espacio en disco. Cool.

Mientras tanto, para ser superficial, Docker es un “must have” si es que eres programador y estas con el tema de desarrollo de aplicaciones basadas en el mundo Open Source. Y si eres un “hard core” hay otra cosa mágica llamada Vagrant pero ya será tema de otro post.

Dense una vuelta por Docker.com y dejen de perder el tiempo fijando variables de entorno y compatibilizando versiones.


Después montones de pruebas, ya publiqué mi app. Por ahora está en Windows Phone Store y en Google Play. Muy pronto en iOS.

Es un catálogo de comics publicados localmente, que les permitirá resolver el problema principal que como coleccionista he tenido que sufrir, ir al puesto de revistas y no saber cual cómic comprar o si es que ya salió el siguiente.

El app es muy simple en el uso, pero detrás tiene un par de cosas interesantes: Sincronización automática de datos y un código para 3 plataformas.

El código único está hecho en Cordova como les dije en un post anterior. Ionic Framework para ser exactos. Las ventajas que trabajar con esta herramienta son innumerables, pero me concentraré en decir que el ahorro de tiempo en programación es de lujo. El punto en contra podría ser que pierdes ciertas funciones nativas, pero me he dado cuenta que el real problema es otro: Interfase de Usuario nativa. Con Ionic, la interfase de usuario es HTML5 donde no hay Panoramas ni Pivots que hay en WP8, por lo demás, hay alternativas que puedes salvar. Entonces, a fin de que sus usuarios no se quejen, aprendan algo de CSS y de SASS y si pueden contraten a un buen diseñador. Si es que no tienen esa virtud de diseñar pantallas bonitas, hagan como yo, manténganlo todo simple. Igual les prometo que contrataré un diseñador para mejorar la presentación.

La sincronización automática se logró mediante la plataforma CouchDB. Para ser exactos, los datos están en un servidor Cloudant y en el cliente utilizo PouchDB, de tal forma que todos los datos son locales para la aplicación. Si es que se publican colecciones o comics nuevos, la data se sincroniza (sólo las diferencias) y desde ese punto todo es local. Ahora bien, existe un modo de sincronización que permite que los datos sean replicados en tiempo real, como resultado de las pruebas he llegado a la conclusión que sólo tiene que ser activado en algunas situaciones limitadas, por dos razones: Costo del tráfico y batería.

CouchDB es super inteligente para sincronizar, y si le dices que quieres hacer una sync “live” se va a encargar de tener los datos en el móvil super actualizados, y con PouchDB eso significa que se mantenga una conexión abierta con el Servidor la mayor parte del tiempo. Esto consume tráfico, batería y todo lo que puedas imaginar. Además, Cloudant te cobra por HTTP Request, lo que significaba, para el caso de mi app, mandar una transacción “pesada” cada 25 segundos por cada móvil. Haciendo las matemáticas, es mucha plata considerando que las publicaciones de comics se hacen por lo general cada semana. En JavaScript hay un método maravilloso llamado SetTimeOut que permite establecer un método donde el app sincroniza todo al iniciar y luego decirle que vuelva a sincronizar a los n minutos. De esa manera puedo hacer que las apps sólo sincronizen cuando es realmente necesario. Como por ahora no se cuantos usuarios pueda tener, mi estrategia de sincronizacion es cada 10 minutos si es que no se ven cambios y cada 100 minutos si es que se obtuvieron cambios, es decir, como los cambios los publico una sola vez, si los descargas, ya no volverás a ver otro lote de cambios hasta dentro de un largo tiempo, así que 100 minutos es el largo tiempo por ahora. Esto debe soportar las nuevas funciones que pienso introducir en el siguiente release.

Entre los principales problemas que tuve es el hecho de trabajar en un código único es posible mientras no tengamos que ver cosas muy pegadas al móvil. Por ejemplo, hay plugins para manejar beeps o para el manejo de estadísticas que sólo funcionan en el móvil haciendo las tareas de debug  bastante tediosas. Así que lo ideal es empezar el proyecto sabiendo que plugins se van a utilizar, para lo cual hay que certificarlos antes y probar que funcionan tal como deben. Por ejemplo, yo les comenté en un Post anterior que utilizaría Angulartics para el manejo de estadísticas, pues resulta que no trabaja tan fácil como lo pensé, y no es que el código sea complicado, simplemente tiene sus lios y listo. Gastar tiempo en investigar esos errores dentro del proyecto es una pesadilla, así que hagan su propio catálogo de plugins que ustedes hayan certificado y tendrán la ventaja.

Por el lado de los datos, PouchDB (o CouchDB como quieran) es un estándar que lo único que tiene fuerte es la sincronización y el manejo de los formatos de base de datos. Quiere decir que consultar los datos puede llegar a ser algo especial. Felizmente PouchDB es manejado por un tipo muy buena onda que se llama Nolan Lawson que está creando librerias y herramientas muy potentes que ayudan a bajar la complejidad, pero lo que si es un hecho es que NO ES SQL, así que hay que meterle algo de cabeza al inicio, como por ejemplo, crear llaves primarias con fecha y datos de la clase padre (plop!) y demás trucos que están todos documentados que en sistemas SQL ni te imaginas. Igual todo vale la pena porque funciona como un reloj suizo.

Un punto importante es el tema de los formatos de base de datos. Hasta ahora, SQLite ha sido la opción única para manejar datos en el móvil y resulta que es un estándar que ya fue. WebSQL definía el uso de archivos sql en aplicaciones HTML5 y actualmente ha sido reemplazado por IndexedDB que es como un super diccionario. El problema aquí es que SQLite sigue siendo muy veloz, y algunas plataformas ya han dejado de lado SQLite, como por ejemplo FirefoxOS y parece que Windows Phone 8.1 también. En fin, para evitar tener que recodificar ese soporte, PouchDB nos facilita la vida haciendo esa gestión por nosotros, si el sistema soporta WebSQL, lo usa y si sólo soporta IndexedDB, cambia todo tras bambalinas, genial. Tiene otros soportes, pero con estos dos es suficiente. Para los curiosos, PouchDB también trabaja en la PC para lo cual utiliza LevelDB que es otro rollo en base de datos para aplicaciones Web.

En conclusión, ya pueden probar mi App que principalmente les permitirá ver que un app puede tener datos actualizados de forma transparente y que comparte un código para todas sus plataformas, así no sean coleccionistas de comics.

Google Play Store:

Get it on Google Play

Windows Phone Store:

154x40_WP_Store_blk

 

Muy pronto para iOS:

 

NOTA FINAL: Disculpen los banners, pero también son parte del experimento

 


Desde que probé la MacBook Air de 13 pulgadas, descubrí que estuve muy equivocado en el tema de laptops pues luego de trabajar duro por una laptop gigante de 17 pulgadas o más, me dí cuenta que lo que más vale es que puedas trabajar por un largo periodo de tiempo, y sin malograrte la espalda en el camino.

El día de hoy comprar una laptop basada en Windows significa que tienes que elegir una muy ligera que pueda convertirse en tablet, de lo contrario, estás comprando algo que no te va a durar. Y no hablo solamente de moda, SSD y Connected Standby son dos características que toda laptop basada en Windows debe tener y eso viene solamente en las laptops convertibles. La única excepción es si eres un professional gamer o estas en arquitectura o ing civil y debes hacer trabajo en la obra, en estos casos debes comprarte una Alienware o una mobile workstation de HP, respectivamente, pero son casos especiales.

El perfil de trabajadores móviles es de aquellos que básicamente utilizan office, email y web, con alguna que otra app por ahi. Eventualmente, un programa empresarial. Bajo este perfil, no hay mejor equipo de una Macbook Air. En el mundo Windows pueden haber opciones, de hecho, tengo una Sony Vaio Duo que me sorprendió gratamente con unas 6 horas de trabajo continuo y con energía para seguí quizá una hora mas, pero ya no hay Sony, y las demás marcas no las he probado.

Con el anuncio de Apple el día de hoy, definitivamente borran las demás alternativas posibles con un modelo mas ligero, mas delgado y por sobre todo, con una pantalla Retina. Simplemente injusto para los demás. Para nosotros, el punto es el ideal.

Resumiré lo que obtendrás con una MacBook Air :

– Hasta 10 horas de batería (Digamos que sean 8 horas efectivas, yo he llegado hasta 6 horas full con la antigua MBA)

– Más memoria (Con 4 gb se portaba muy bien, pero 8 es mucho mejor, de verás se siente la diferencia)

– Pantalla Retina (No solamente para ver una película, sino también para aumentar el tamaño del escritorio, genial)

– Trackpad y teclado (Ambos ya eran muy buenos, pero el teclado ha sido mejorado para que sea mas silencioso y el trackpad tiene respuesta táctil que no se bien que es pero si se porta al menos igual que el actual, bienvenido)

Lo mejor de todo es que el precio no es tan alto aunque la realidad es que tienes que añadirle algunos accesorios básicos:

– Hub USB (El equipo viene con USB tipo C así que si quieres usar tu mouse actual, esto es obligatorio)

– Salida de video (si quieres hacer tu presentación no hay ni HDMI ni VGA así que tendrás que comprar uno)

– Finalmente, un estuche para que ningún rayón malogre su caja de aluminio (Thule recomendado)

Así que ya sabes, si trabajas la mayor parte del día en la calle, junta tu billete para que este 20 de abril te compres tu MacBook Air 2015.

Sobre Apple Watch, si quieres un reloj que puede quedarse sin batería en algún momento, cómpratelo. 18 horas de duración no es suficiente para utilizarlo para reemplazar un aparato que en su modelo más barato tiene una duración de 3 años (un Casio). En mi caso, tengo una banda Xiaomi que me avisa todo lo que pasa en mi celular por 20 dólares cuya batería dura 1 mes (comprobado) además de registrar información básica del ejercicio que hago.





%d bloggers like this: