domingo, 5 de abril de 2015

Ciclos de Vida de una Actividad en Android

Las Activity, en Android son el objecto principal de cualquier aplicación. Y cuando un usuario utiliza una aplicación puede entrar a la aplicación, cambiar de actividad, salir de ella, volver a entrar, etc. Entender el ciclo de vida de una aplicación es un proceso VITAL para poder crear aplicaciones Android de calidad.


Una aplicación Android corre dentro de su propio proceso Linux. Este proceso es creado con la aplicación y continuará vivo hasta que ya no sea requerido y el sistema reclame su memoria para asignársela a otra aplicación.  Una característica importante de Android es que la destrucción del proceso de la aplicación no es controlado por la aplicación, en lugar de eso, es el sistema que determina en que momento detener el proceso, basándose en el conocimiento que tiene de las partes de la aplicación que están corriendo (actividades y servicios), y cuánta memoria disponible hay en un determinado momento.

Si una aplicación es eliminada y después es vuelta a abrir se crea un nuevo proceso, pero se habrá perdido el estado que tenia esta aplicación. En estos casos, va a ser responsabilidad del programador almacenar el estado de las actividades, si queremos que cuando sea reiniciada conserve su estado.



Dependiendo de la complejidad de la aplicación no usar todos los metodos del ciclo de vida. Pero de todas maneras es importante entender cada uno e implementar esos que aseguren un correcto funcionamiento de la aplicación. Hacer eso requiere estar seguros que la aplicación no fallar en los siguientes casos:

  • No va a dar error cuando el usuario reciba una llamada o cambie a otra aplicación.
  • No va a consumir recursos importantes del sistema mientras el usuario no la este usando. 
  • No va a perder el progreso del usuario mientras deje la aplicación y vuelva.
  • No va a dar error o perder el progreso de la aplicación si el usuario cambia la orientación del telefono.
Estos son los estados descritos en la gráfica y lo que significa cada uno de ellos:

  • Activa (Resumed): En este estado la actividad esta en primer plano y el usuario puede interactuar completamente con ella.
  • Visible (Paused): En este estado la actividad esta parcialmente oscurecida por otra actividad, La activadad que este en primer plano es semitransparente o no cubre la pantalla completa. Una actividad pausada es visible pero no recibe interacciones con el usuario.
  • Parada (Stopped): En este estado la aplicación esta completamente oculta y no es visible al usuario, se considera que esta en el background. Aquí se debe almacenar el estado actual de la aplicación, interfaz, preferencias, etc...
  • Destruida (Destroyed): Cuando la actividad termina al invocarse el método finish(), o es destruida por el sistema.

Cada vez que una actividad cambia de estado se generan eventos que podrán ser capturados por  métodos de la actividad. A continuación dichos métodos:

  • onCreate(Bundle): se dispara cuando la actividad es iniciada y se usa para realizar todo tipo de inicializaciones, como la creación de la interfaz de usuario o la inicialización de estructuras de datos. Puede recibir información sobre el estatus de la actividad o recibir el intent enviado por otra aplicación. 
  • onStart(): se dispara cuando la actividad está a punto de ser mostrada al usuario.
  • onResume(): se dispara cuando la actividad esta disponible al usuario y va a interactuar con ella.
  • onPause(): se dispara cuando otra actividad pasa a primer plano y esta pasa a estar en un segundo plano. 
  • onStop():  se dispara cuando la actividad ya no es visible para el usuario. Lo siguiente que puede dispararse seria onRestart o onDestroy o nada. dependiendo de lo que haga el usuario. 
  • onRestart(): se dispara cuando la actividad va a volver a ser representada después de haber pasado por onStop().
  • onDestroy(): sucede cuando se esta limpiando la información de la aplicación antes de ser completamente destruida la aplicación. Puede suceder cuando la actividad es finalizada con finish(), o porque el sistema este destruyendo la instancia de la aplicación para guardar espacio.

    NOTA: Este metodo no debe ser contado para guardar la información del usuario. porque puede suceder que se finalice la aplicación sin llamar a este metodo. 
Documentación oficial:

Conceptos básicos de Android

Conceptos basicos de android


Conceptos básicos de Android

Conceptos basicos sobre Android, para tener una idea general sobre los componentes y posibilidades que tiene Android. y algunos enlaces a la documentación oficial para obtener mayor información. 

Activity

Una Activity es un solo elemento, enfocada que el usuario puede ver. casi todas las actividades en Android pueden interactuar con el usuario, las actividades están conformadas por dos partes, gráfica y la lógica.

El área gráfica (Layouts) es un o varios archivos XML, que tienen declarados las etiquetas similares a las de HTML. Estas etiquetas definen los elementos de la interfaz como botones, cuadros de texto, listas, etc... 

El área lógica que es el archivo .java donde se define la clase, interacciones con el entorno y responder a los eventos de los usuarios.

Intent

Un intent es una descripción abstracta de una operación a ser realizada, Puede ser usado con startActivity() o startActivityForResult() para lanzar una ActivitybroadcastIntent para enviar algo a un BroadcastReceiver, y startService(Intent) o bindService(Intent, ServiceConnection, int) para comunicarse con un Service.

Fragment

Es una porción de un interfaz gráfica, que puede añadirse o eliminarse de una interfaz de forma independiente al resto de elementos de la actividad, y que por puede reutilizarse en otras actividades. esta caracteriztica nos permite manejar contenido de una aplicación sin tener que modificar la aplicación completa como tal sino definir y manipular zonas especificas.

Un Fragment esta dentro de una Activity  por lo cual su ciclo de vida esta íntimamente relacionado a la misma.

Esto es sumamente útil para desarrollo de aplicaciones en Android para tablet, donde tenemos mayor área aprovechable que en un teléfono y necesitamos poner diferentes modulos que interactuen entre si.

BroadcastReceiver

Un BroadcastReceiver es un componente de Android que permite recibir eventos del sistema y de nuestra propia aplicación. Android posee muchos eventos dentro del sistema como por ejemplo: llego un sms o un correo, llamada entrante, se desconecto el cargador, bateria baja, etc, etc. Y un BroadcastReceiver, nos permitirá saber cuando ocurre este tipo de eventos y generar una respuesta a ellos, ya sea crear una actividad, detener la sincronización, leer un mensaje, etc. 

También lo podremos utilizar para comunicar componentes dentro de nuestra propia aplicación, como por ejemplo que un servicio averigüe si una actividad esta corriendo, o que le avise a dicha actividad que se termino de sincronizar algo, etc...

ContentProvider

Es un componente que permite compartir información entre aplicaciones. A través de los ContentProvider podemos leer información de otras aplicaciones o también podemos dejar de manera accesible información a otras aplicaciones.

Esto es sumamente útil para leer por ejemplo los datos de los contactos de las personas que están en nuestro teléfono, leer información de la agendas, etc....

Service

Es un componente de la aplicación que puede correr operaciones largas y  no poseen interfaz visual , las cuales corren en el proceso de fondo del sistema e inclusive sigue corriendo cuando el usuario cambia a otra aplicación.

Son sumamente útiles para procesos de sincronización largos, reproducir música, trabajar con sistemas de archivos, etc....

http://developer.android.com/guide/components/services.html


AndroidManifest

Tienen la información esencial de la aplicación y es obligatorio declarar cada componente aquí para poder utilizarlo, además de crearlo extendiendo de su clase correspondiente, es necesario definirlo en el AndroidManifest.xml. Este archivo es esencial en cualquier aplicación Android.

http://developer.android.com/guide/topics/manifest/manifest-intro.html

Cada componente tiene su propia etiqueta xml:
  • Para Activity.
  • Para Service.
  • Para BroadcastReceiver.
  • Para ContentProvider.
Además se definen algunas otras cosas importantes de la aplicación, como el logo, nombre, versión de android que soportara, hardware que soporta la aplicación, etc...

<?xml version="1.0" encoding="utf-8"?>
<manifest>

    <uses-permission />
    <permission />
    <permission-tree />
    <permission-group />
    <instrumentation />
    <uses-sdk />
    <uses-configuration />  
    <uses-feature />  
    <supports-screens />  
    <compatible-screens />  
    <supports-gl-texture />  

    <application>

        <activity>
            <intent-filter>
                <action />
                <category />
                <data />
            </intent-filter>
            <meta-data />
        </activity>

        <activity-alias>
            <intent-filter> . . . </intent-filter>
            <meta-data />
        </activity-alias>

        <service>
            <intent-filter> . . . </intent-filter>
            <meta-data/>
        </service>

        <receiver>
            <intent-filter> . . . </intent-filter>
            <meta-data />
        </receiver>

        <provider>
            <grant-uri-permission />
            <meta-data />
            <path-permission />
        </provider>

        <uses-library />

    </application>

</manifest> 



lunes, 2 de marzo de 2015

Reinventando la rueda desde Venezuela



Hoy escribo para comentar algo que me ronda la mente desde hace tiempo y es sobre el tema de hacer aplicaciones que ya están echas, como decir youtube, twitter, etc... de lo cual siempre e tendido a pensar en que no me gusta reinventar la rueda.  

En especial odio a la gente que inventa sus propios "frameworks" y terminan llevando el enredo que tienen en sus cabezas al código, Y después te piden que lo uses para terminarte dando cuenta que no sirven para nada. 

Peroooo, ese no es el tema de hoy, sino del desarrollo de aplicaciones enfocadas en lo local. Y ciertos caso de los cuales yo quería hablar. 


Youtube, twitter, facebook, LinkedIN, etc, etc etc.

Todas son aplicaciones, que funcionan muy bien cumplen su rol excelentemente, pero tienen un gran defecto. Están en los estados unidos. La mentalidad de estados unidos, es una mentalidad netamente capitalista-salvaje, de aprovechamiento al máximo de los "recursos", y estas paginas no dejan de ser parte de estos "recursos". Lo que a mi me preocupa es entregarles toda tu información toda tu vida, tus fotos, tus amistades, tu forma de pensar, lo que haces, y lo que dejas de hacer a un extraño que de por si esta más que comprobado que no le interesa tu privacidad, que pueden terminar vendiendo tu información a cualquier postor y además todas esas empresas se tienen que regir a las leyes norteamericanas o sino igual llega la CIA o la NCA e igual obtiene acceso a tu información. Y la información es poder. 

Y aparte también esta la parte donde si no le caes bien a cualquiera de estas empresas pues simplemente te cierran, te callan y no hay a quien ir a llorar. 

Además de que en buena parte de los casos, son aplicaciones pensadas para gente de habla inglesa, con mucho contenido foráneo y que a la final te pierdes en contenido que no tiene que ver con tu localidad.  Y da la sensación de que aquí no se esta haciendo nada porque como hay mucho contenido de afuera y youtube no pierde tiempo en mostrarte pues podrías estar perdiendo contenido valioso y echo aquí en Venezuela. 

Y que un país dependa siempre de agentes externos es altamente peligroso. Dígame los servicios de Whatsapp y Blackberry. Toda la comunicación personal de millones de venezolanos en manos de Agentes externos y que se usen sin el mínimo entendimiento de los riesgos que esto acarrea pues es preocupante.  


Todo es en dolares

Un tema muy importante actualmente para todos los venezolanos es el bendito dolar, y  es el que a mi más me preocupa, porque es el que nos afecta a todos como venezolanos. Y se ve reflejado en cuantos venezolanos no a gastado su cupo de dolares para comprar aplicaciones por itunes o Play Store. Y cuantos venezolanos emprendedores pueden vender aplicaciones a través de play store o itunes y ganarse un dinero por su trabajo? 

Estas preguntas nos dan a entender, que por supuesto el mercado móvil de aplicaciones móviles en Venezuela es de muy lento crecimiento porque dependes enteramente del tema dolar y que para nosotros es sumamente problemático. 

Para el consumidor promedio, es decir el todos los venezolanos, pues no consiguen aplicaciones a su medida, que puedan pagar en bolívares o simplemente que tengan que ver con su día a día o las. 

Porque comento esto, pues porque cualquier aplicación echa afuera que se pueda adaptar a nuestra vida cotidiana, bien valdría la pena poder contar con una versión Venezolana. Y a mi parecer no seria tan exitosa como la extranjera pero seria bien recibida y tendría buena acogida dentro del publico venezolano. 



martes, 23 de diciembre de 2014

Django PostgreSQL Idle in Transaction

Es u problema muy común en los sitos que corren django y PostgreSql que allá conexiones que queden en "Idle in Transaction" Son producto de transacciones sin cerrar o esperando commit o roolback.

Este tipo de problema tiene dos posibles momentos en los que sucede esto. Uno es a la hora de hacer responder peticiones y otra es a la hora de señales de django que se ejecutan al cargar un modelo.

Para cuando las consultas queda abiertas al hacer peticiones, django trae consigo TransactionMiddleware, al añadir al final 'django.middleware.transaction.TransactionMiddleware' a MIDDLEWARE_CLASSES debería solucionarse de manera definitiva el problema.

En el otro caso me sucedió en un sistema, que estaba ejecutado una consulta en class_prepared.connect. Y dejaba u proceso abierto que evitaba que el resto de las consultas se ejecutara. ¿Solución? Estas dos lineas de código y listo:


from django.db import connection
#cierro la ejecución despues de terminar de ejecutar las cosultas
connection.close()

Ninja 3D Blender


Hoy les dejo mi primer ninja echo en Blender. Espero que les guste y pronto espero colocar más información sobre blender.

Three.js ninja ejemplo:
http://bomba1990.pythonanywhere.com/sosinformatico/js/ninja-blender

Blender:
https://www.dropbox.com/s/g71vtjgm0xmrudj/ninja2.blend?dl=0

lunes, 22 de diciembre de 2014

Packt’s $5 eBonanza returns



Following the success of last year’s festive offer, Packt Publishing will be celebrating the holiday season with an even bigger $5 offer.
From Thursday 18th December, every eBook and video will be available on the publisher’s website for just $5. Customers are invited to purchase as many as they like before the offer ends on Tuesday January 6th, making it the perfect opportunity to try something new or to take your skills to the next level as 2015 begins.
With all $5 products available in a range of formats and DRM-free, customers will find great value content delivered exactly how they want it across Packt’s website this Xmas and New Year.

Find out more at http://bit.ly/1w1Vkps

sábado, 29 de noviembre de 2014

Django models añadir permisos para ver a todos. (view_*)

Algo muy común que se usa en Django son los permisos de modelo para controlar quien puede objetos particulares. Django provee permisos por defectos en todos los modelos, crear, editar y eliminar.

Hay varias formas de agregar este permiso de "ver" en la web, pero la forma más sencilla que yo e visto es hacerlo en "post_syncdb". Cuando uses el comando syncdb, todos los modelos de tu sistema se chequeara si tienen el permiso view y si no se los creara.

Solo tienes que poner el siguiente script en el __init.py en el directorio de management/ de cualquiera de tus aplicaciones. Necesita estar dentro de un directorio de management o si no, no sera descubierto por el comando syncdb.

from django.db.models.signals import post_syncdb
from django.contrib.contenttypes.models import ContentType
from django.contrib.auth.models import Permission
 
def add_view_permissions(sender, **kwargs):
    """
    This syncdb hooks takes care of adding a view permission too all our 
    content types.
    """
    # for each of our content types
    for content_type in ContentType.objects.all():
        # build our permission slug
        codename = "view_%s" % content_type.model
 
        # if it doesn't exist..
        if not Permission.objects.filter(content_type=content_type, codename=codename):
            # add it
            Permission.objects.create(content_type=content_type,
                                      codename=codename,
                                      name="Can view %s" % content_type.name)
            print "Added view permission for %s" % content_type.name
 
# check for all our view permissions after a syncdb
post_syncdb.connect(add_view_permissions)