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.
Víctor Pease 
Leave a comment