Posts Tagged ‘Internet’


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.

Advertisements

Con la salida del iPhone al mercado se ha marcado una tendencia clara en lo que se refiere al diseño de los celulares y esta es que mientras mas grande y nítida sea la pantalla, mejor lo que hace que los teclados físicos sean cosa del pasado.

Incluso, uno de los abanderados de los teclados QWERTY en móviles como RIM simplemente se rindió ante esta tendencia y sigue terco con sus modelos Storm, aunque siga siendo el modelo Bold el màs requerido.

¿Es que acaso el teclado ya no tiene sitio en los móviles? parece que si tiene un sitio, de lo contrario RIM si estaría muerto, o no habrían Androides con teclado, aunque no sean los que mas venden.

¿Acaso estaremos dejando la practicidad de un teclado QWERTY por la factor Sexy de un telefono full pantalla? Me parece que si aunque no tenga cifras para probarlo. Deberìa haber un estudio para medir si es que los que utilizan un teléfono full pantalla escriben menos como es que sospecho. Lo que si es muy cierto es que las personas que realmente trabajan con su teléfono y utilizan para eso el correo electrónico, no tienen una mejor alternativa que el Blackberry con teclado QWERTY. Es imposible lograr la misma productividad con otro modelo de teléfono.

No puedo encargar estudios sobre comportamientos así que esta vez simplemente dejaré mi tesis: Los usuarios de teléfonos full pantalla suelen basar su comunicación en fotos o frases cortas, mientras que los usuarios de teléfonos con teclado QWERTY simplemente no tienen límite.

Si revisamos la lista de equipos más vendidos veremos que todos tienen casi el mismo diseño: un full pantalla. ¿Es realmente este el diseño para ser mas productivos? Depende de nuestras necesidades como siempre, pero cada día parece que somos empujados a elegirlos porque hay cada vez menos alternativas.

Veamos las alternativas:

– Blackberry sigue teniendo fuerza gracias a su diseño candy bar con qwerty y que es rescatado por algunos smartphones como HTC con su Status. Pero con una diferencia. Los que utilizan Blackberry notaran que el sistema operativo esta diseñado para extraer toda la utilidad del teclado, mientras que los que han utilizado algún Android con teclado, notaran que el teclado suele confundir al sistema operativo, o a nosotros por comportamientos erráticos, como si el teclado no haya sido considerado en el diseño del software.

– Las alternativas de escritura rápida como Swype que buscan aumentar la velocidad de escritura de los teclados en pantalla. A mi simplemente no me sirve.

– La resignación de escribir con errores o limitarnos a frases cortas.

Yo creo que la última opción nos esta ganando.

La mejor solución a esta situación es que exijamos mejores diseños que se adecuen a nuestras necesidades y no simplemente resignarnos a elegir algo de lo que hay disponible. Esta bien que iPhone sea el más buscado, pero hay gente que requiere un teclado o una alternativa igual o mas productiva.


En Estados Unidos hay protestas frente a las oficinas de Google y el FCC (o el órgano todopoderoso en materias de internet) se rasca la cabeza para encontrar una forma de asegurar que nadie ponga trabas a la red. Pero ¿qué significa todo esto para nosotros?

La neutralidad de la red busca que los operadores se vuelvan simples tubos por donde pase cualquier tipo de información. Es el usuario el único filtro posible sobre el tipo de información que se transmitirá a través del tubo.

Para entender las consecuencias económicas de esto, veamos como los Operadores de red hacen dinero con esto: Primero, se estima un comportamiento promedio para un usuario a fin de establecer el consumo de ancho de banda. Luego se establece un consumo mínimo y un consumo máximo. Finalmente, se estima el tamaño de mercado objetivo y se establecen los porcentajes para el usuario promedio, el consumidor mínimo y el consumidor máximo. De esta manera, se establece cuanto ancho de banda ofrecer y el margen de error es el famoso “porcentaje de aseguramiento” que por lo general es el 10%.

¿Dónde está la plata?, en los usuarios que consumen el promedio de ancho de banda o menos. Usuarios que consumen mas allá del promedio calculado, como yo, representan la pérdida para los Operadores.

Esto es mas notorio con los Operadores Wireless, que establecen un tope de tráfico, a partir del cual aplican una tarifa mas elevada, precisamente para evitar que los usuarios se escapen del promedio de consumo que ellos calculan.

Es justo que los Operadores hagan dinero, para eso están. Si bien Internet es una gran ventaja para todos, aún no es un servicio público básico como el agua o la electricidad. Así que los Operadores están en su derecho de hacer dinero. Ahora revisemos cuales serían algunas estrategias para maximizar el ingreso de los Operadores.

  • Límites de tráfico. Común en Operadores Wireless. De tal forma que sabemos como usuarios que debemos controlar el uso de aplicaciones de alto consumo de datos. En otras palabras, el usuario establece cuales son sus prioridades en la red.
  • Bloquear sitios “ilegales”. El mayor temor de los Operadores es el uso de descargas ilegales o “torrents”, “warez” o cualquier otro tipo de sitios que ofrezcan gratis lo que otros venden. El problema aquí es el uso de la red para descargar contenido, mediante herramientas que exprimen al máximo la capacidad de la conexión, elevando el consumo promedio y saturando la infraestructura. Bloqueo por Ips en el Operador, es la respuesta mas fácil y sobre todo discreta, pues no sabemos si el Operador está bloqueando o no ciertos lugares.
  • Bloquear o bajar la prioridad a determinados protocolos. Si es torrents, video streaming, ftp, o cualquier otro protocolo relacionado a descargas, será mas lento que otras aplicaciones, si es que el Operador establece una política para eso en su infraestructura. Requiere de equipos de red inteligentes y por lo general mas caros. Igual no nos daremos cuenta.
  • Modelo Francés. este es el modelo más estricto. Descargas material ilegal, te encuentran y te advierten. A la tercera advertencia te quitan el acceso y juicio incluido.

Como vemos, hay métodos “invisibles” y los otros “visibles” que tienen todos algo en común. Alguien está mirando lo que estamos haciendo en la red.

La neutralidad de la red se refiere a que nadie debe estar “mirando” lo que hacemos. Si compramos un acceso, ese acceso debe ser solamente un tubo tonto que deje pasar todo lo que yo le pida. Aquí viene el choque con el Operador pues ya vemos que sus alternativas para controlar el tráfico, y por ende mantener el negocio rentable, atentan contra el principio del tubo tonto. ¿Entonces como reconciliar la neutralidad con el interés comercial de los Operadores?

Aún no hay un ente regulatorio fuerte, la competencia ha permitido mantener el acceso a Internet en niveles aceptables para nuestra realidad. El mayor problema que hay con los Operadores siempre ha sido el bendito CIR o porcentaje de ancho de banda asegurado. Fuera de eso, tenemos algo bien parecido a un tubo tonto, al menos en la parte de acceso a través de conexiones fijas. En el mundo Wireless, el tubo tonto es un tubo que se hace mas caro. Y listo, nadie nos ha cortado acceso a video conferencia, o a torrents ni nada.

La solución a la neutralidad de la red ha sido para nosotros, pues simplemente establecer cuotas de tráfico, y si se te acaban, pues compras mas y listo esto para la red Wireless, y para la red fija, pues te bajan el CIR y listo, si quieres mejor Internet, entonces tendrás de dejar los torrents de lado.

Parece que por alguna razón, por este lado del mundo hemos visto cómo resolver este problema rápidamente. En Estados Unidos tendrán para largo sobre este tema. Quizá deberían mirar un poco hacia el sur para buscar algunas soluciones.


Desde que me enteré el día de ayer que Google iba a lanzar un nuevo navegador al mercado, con características “fuera de este mundo” como “Multithread” para el rendering de páginas, super ultra veloz y también “Multithread” motor de javascript, seguro a mas no poder y sobre todo gratis, Open Source y demás términos que caracterizan a esta empresa, estuve pegado a mi laptop probando y probando la dirección de descargas hasta que finalmente funcionó. 

http://www.google.com/chrome 

Estoy escribiendo este artículo desde mi nueva instalación de Chrome y quiero decir que todos los adjetivos que le puse en el párrafo inicial son aún transparentes para mi. Ultra veloz? pues no tanto, Super seguro? pues ojalá, en fin. Empezaré a usarlo como navegador por defecto y según eso podré opinar. 

Tengo que apuntar que actualmente estoy usando en mi laptop Windows Server 2008 como sistema operativo y bajo esta situación Internet Explorer 7 se ha convertido en mi navegador por defecto pues su desempeño ha sido de lejos muchisimo mejor que la de Firefox en esta plataforma. Todo lo contrario cuando tenía esta misma laptop con Windows XP, Firefox era el rey. Aqui si he notado una gran diferencia entre estos dos navegadores. En Win2k8 32 bits, Internet Explorer es muy seguro, estable y rápido, mientras que el Firefox 3 se mostró lamentablemente lento, inestable y los plugins pues malograban la experiencia mas que mejorarla. 

Ante ese panorama, la inclusión de un nuevo navegador a mi set de herramientas, comienza por preguntarme si realmente necesito otro navegador. Y la respuesta es que no estoy seguro de necesitar otro, pero si voy a tener una experiencia de Web mejor, vale la pena probar. 

La promesa de Google hasta ahora me ha parecido intrigante, Webkit es el engine utilizado, también en Safari de Apple inclusive en Iphone, y su disponibilidad en plataformas móviles hace abrigar la esperanza de que tendremos una experiencia Web única sin importar el dispositivo. Android también tendrá este engine así que lo único que debemos de preocuparnos es algo de lo que ya sufren los usuarios de Iphone: Plugins!!!!. Flash es el gran ausente en Iphone y espero que no sea ignorado en Android.

¿Que pasará si Chrome cumple con todo lo que promete? El ganador será el usuario final, no hay otra opción. No hay ganancia real en la batalla de los navegadores, Netscape era el rey y quebró de un día para otro, ¿que ganancia reporta Internet Explorer a Microsoft?. Opera sobrevive vendiendo licencias de su navegador para equipos móviles. Entonces, viene Google y dice que va a regalar un super navegador tal como lo prometió Microsoft con IE7, y Opera con su versión 9.5. Pues bien, si gana la batalla de los navegadores, crecerá su fama pero económicamente será una victoria pírrica . La gente seguirá optando por el navegador de su conveniencia pues IE vendrá preinstalado en todos los Windows, MAC vendrá con Safari y desde esa base el usuario elegirá. Es dificil imaginar un panorama con un solo navegador. 

Lo que se está dejando de lado es la experiencia: “No importa como llegue a Internet, mientras vea lo mismo”. Existía un plugin para Firefox llamado Google Sync donde uno podía recuperar su sesión de web, favoritos y cookies de una pc a otra usando los servidores de Google para almacenar toda esta información. Algo asi como mi perfil en roaming para mi navegador. Casi lloro el día que Google decidió descontinuarlo. Si hubiera salido para IE, la verdad no me hubiera importado el navegador. Y la versión para móviles hubiera sido el sueño hecho realidad, pero ya no pues Google lo canceló. Se canceló la experiencia Web única. Ahora plantea un nuevo navegador, y la experiencia?

Prueben Chrome, a ver si algún día Google o quien sea, se dan cuenta que el valor para el usuario está en su experiencia: Favoritos, perfiles grabados (Si se borra mi cuenta grabada en ViaBCP se me hace un nudo todos los pagos), plugins. Y todo esto va mas allá que escoger el navegador.





%d bloggers like this: