Archive for Linux
Instalando NODE.JS en CENTOS 6 con su administrador de paquetes npm
[root@localhost ~]# yum groupinstall ‘Development Tools’ && yum install openssl-devel
[root@localhost ~]# cd /usr/src/ && wget -c http://nodejs.org/dist/v0.6.6/node-v0.6.6.tar.gz
[root@localhost ~]# tar -xvzf node-v0.6.6.tar.gz
[root@localhost ~]# cd ./node-v0.6.6 && ./configure && make && make install
[root@localhost ~]# curl http://npmjs.org/install.sh
Ciclo de vida del ‘Servicio’ de un dispositivo mobil con Android
El ciclo de vida para un servicio es similar al establecido para una actividad, aunque difiere en algunos detallitos:
onCreate and onStart
Las diferencias… Servicios pueden ser iniciados cuando un cliente realiza una llamada a la funcion Context.startService(Intent). Si el servicio no estubiece corriendo, Android arrancara este, y llamara su funcion onCreate seguida por la funcion onStart. Si el servicio se encuentra ya corriendo, su funcion onStart es invocada de nuevo con la nueva Intencion .
onResume, onPause, y onStop
No son requeridos.. Recordemos que un servicio por lo general no poseen interface de usuario, ya que siempre corre en segundo plano.
onBind
Si un cliente necesita una coneccion persistente a un servicio. Este crea el servicio si este no se encuentra corriendo, y llama onCreate pero no onStart. En lugar de eso, la funcion onBind es llamada con la “intencion” del cliente, y esto retornara un objeto IBind que el cliente puede usar para hacer cuantas llamadas desee a el servicio.
onDestroy
Como con una “Actividad”, la funcion onDestroy es llamada cuando el servicio esta a punto de terminar. Android terminara un servicio cuando no existen mas clientes iniciando o enlazados a este. Como con las Actividades, Android pudiece tambien terminar un servicio cuando la memoria esta llegando a su limite. Si esto sucediera, Android intentará reiniciar el servicio cuando la presión de la memoria pase.
El Manifiesto de una App Android
Mas detalles en http://www.memoriasdeunaprendiz.com/android/2010/07/27/entendiendo-el-manifiesto/
Ciclo de vida de la ‘Actividad’ de un dispositivo mobil con Android
Android es diseñado en base a los unicos requerimientos de las aplicaciones que son para mobiles. Android reconoce que recursos (memoria y bateria, por ejemplo) son limitados sobre la mayoria de los dispositivos mobiles, y provee mecanismos para conservar dichos recursos. Los mecanismos son evidentes en el ciclo de vida de la actividad de Android.
La “actividades” monitorean y reaccionan a estos eventos mediante la instanciacion de metodos que sobreescriben la clase de “Actividades” para cada evento:
Es importante tomar ventaja de estos metodos ya que proveeran la mejor experiencia para el usuario.
Componentes de una Aplicacion Android
Las aplicaciones en android son construidas de 4 tipos de componentes basicos que son definidos en la arquitectura Android:
1.- Los componentes del tipo Actividades (Activities)
Estos componentes son comparables a las solitarias aplicaciones de escritorio. En si son piezas de codigo ejecutable , instanciadas cada vez que son requeridas ya sea por el sistema operativo o algun usuario. Estos componentes pueden interactuarcon el usuario y solicitar datos o servicios que ofrescan otros componentes actividades.
La mayoria del codigo ejecutable que se escribe para Android sera ejecutado en el contexto de Actividad. Las Actividades usualmente correspontes a pantallas en el display: cada Actividad mostrara una pantalla a el usuario. Cuando estas no estan activamente corriendo, el sistema operativo dispondra de ellas matandolas, como si se tratace de cualquier proceso en linux que se finaliza con un kill -9.
2.- Los componentes del tipo Servicios (Services)
Estos son analogos a los demonios en un sistema unix. No son mas que piezas de codigo ejecutable que correran en segundo plano desde el momento en que estas se carguen hasta que el mobil es apagado. Por lo general no seran expuestos en interfaces de usuario.
3.- Los componentes del tipo Difusores y Receptores de Intenciones (Broadcast and Intent Receivers)
Estos responderan a solicitudes de servicio proveenientes de alguna otra aplicacion. Un receptor de la difusion (A Broadcast Receiver) respondera a aquel aplicativo que le anuncie un evento. Esos anuncios pueden proveenir del mismo Sistema operativo ( por ejemplo “bateria baja”) o de agun otro aplicativo corriendo en el sistema operativo. Una actividad o un servicio proveen otras aplicaciones con acceso a su funcionalidad al ejecutar un Receptor de Intenciones, un pequeña pieza de codigo ejecutable que reponde a los datos y servicios de otras actividades.
4.- Proveedores de contenido (Content providers)
Son los componentes creados para compartir datos con otras actividades o servicios. Un proveedor de contenido usa una interface standard en la forma de una URI para llenar las solicitudes para los datos de otras aplicaciones que pueden no conocer aun, que proveedor de contenidos estan ellas usando. Por Ejemplo, cuando una aplicacion dispara una consulta para obtener los datos de un contacto, esta localiza la consulta a la URI de la forma: content://contacts/people
El sistema operativo buscara que aplicaciones se han registrado ellas mismas como proveedoras de contenido para la URI dada, y mandara la solicitud a la aplicacion apropiada (iniciara la aplicacion incluso si esta no se encuentra corriendo). Si existiece mas de un proveedor de contenido registrado para la URI solicitada, el sistema operativo preguntaria al usuario cual le gustaria usar.
Una aplicacion no tiene que usar todos los componentes de Android, pero una aplicacion bien hecha tendra que hacer uso de los mecanismos que ya se proveen, “mas que reinventar la rueda”.
