Conexión TCP compartida entre activities

[Ivan Pajuelo]

Buenas gente.

Alguien sabe cual es la mejor forma (según Android) de compartir una conexión entre activities de la misma App?
Mi idea es usar un servicio y que la activity activa esté registrada con el, usándolo de proxy para acceder a la conexión.
Es la mejor práctica?
Alguna otra idea?

Saludos!

[Alberto Santos Benito]

yo diria que es la correcta, la que tu dices.

alguna idea mas , para conocer otros puntos de vista... vendrian bien

--
Hazte miembro en la web del GDG ( http://goo.gl/ngNRi ), y para no perderte nada sigue al GDG Barcelona en Google+ ( http://goo.gl/f3xo4 ), Twitter ( twitter.com/GDGBarcelona ), y su blog ( http://gdgbarcelona.blogspot.com.es/ )
---
Has recibido este mensaje porque estás suscrito al grupo "GDG Barcelona" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a gdg-barcelon...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a gdg-ba...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Alberto ^^

[Ivan Pajuelo]

Pues sí. La verdad es que estarían bien otras opiniones/opciones.

[Rubén Serrano]

Tal como yo lo veo, la alternativa sería un Singleton.

Service

Puedes mantener la conexión aunque se cierre la aplicación

Gestionas perfectamente el ciclo de vida del servicio

Implementar el servicio y la comunicación con las activites es un pelín más laborioso (comparado con el singleton)

Singleton

Más sencillo de implementar y más simple de comunicar con las activities

Si se cierra la aplicación, en teoría se destruye (salvo si utilizas una subclase de Application, que según Google es una mala práctica)

No sé para que lo quieres usar exactamente, pero yo creo que la clave entre uno y el otro es saber si te interesa mantener la comunicación abierta cuando la aplicación no está en primer plano. Otro criterio para escoger, es que el Service funciona en todas las situaciones, mientras que el singleton no te serviría en caso de querer mantener la comunicación abierta si el usuario pasa la app a background y luego de nuevo a foreground. 

2013/7/26 Ivan Pajuelo <ipaj...@gmail.com>

[Daniel J Narbona]

Fragment con setRetainInstance?

Saludos

Daniel J. Narbona

[Fernando Cejas]

Yo lo que haría sería usar un ContentProvider/Database para almacenar los datos que vas consumiendo desde la conexión, que podrías hacerla por un IntentService (el cual ayuda mucho porque el método on handle intent es asíncrono). 

Al final tener una clase DataManager a la cual le pedís los datos que necesitás y si esta los tiene en contentProvider, los utiliza y sino hace la petición. De esta manera tendrías una especie de cache en caso de no tener conexión o por lo menos para ahorrar datos.

También podrías tener un campo de fecha para ver cuando los datos están obsoletos y así actualizarlos.

Te recomiendo que mires este video, que es del 2010 pero explica muy bien lo que te quiero decir:

http://www.youtube.com/watch?v=xHXn3Kg2IQE

Saludos

Fernando Cejas

GDG Barcelona Organizer

@fernando_cejas

fce...@gmail.com

http://www.android10.org/

http://nfcquickactions.com

2013/7/26 Ivan Pajuelo <ipaj...@gmail.com>

[Oriol Jiménez]

Me gusta la solución que propone Fernando.

[Rubén Serrano]

+1 a la solución de Fer para el caso que propone. Pero, ¿y si la conexión no es solo para recuperar datos? Pongamos que es para enviar datos al servidor, y por una cuestión de rendimiento dejas la conexión abierta.

2013/7/26 Oriol Jiménez <ori...@gmail.com>

[Fernando Cejas]

Puede ser rubén...pero los datos a mandar los podés tener siempre persistidos en un content provider e ir chequeando si tenés pendientes en caso que te maten la activity o algo..Es como funcionan los retry... Dejar conexiónes abiertas y mas si son por sockets te mata la batería...

My two cents :)

Fernando Cejas

GDG Barcelona Organizer

@fernando_cejas

fce...@gmail.com

http://www.android10.org/

http://nfcquickactions.com

2013/7/26 Rubén Serrano <ake...@gmail.com>

[Ivan Pajuelo]

LOL Fernando!

Creo que estás pensando en que el servicio va adquiriendo datos por tcp.
No es el caso. El servidor envía eventos y las diferentes activities han de enterar al momento. Hacerlo por polling consultando la base de datos sería una locura.
Voy a darle una vuelta al singleton. A ver que tal...

[Javier Martin]

Yo como dice Fernando es como lo tengo hecho en alguna app, lo que utilizo es un ORM para que el trabajo con la base de datos sea mas sencillo.

[Rubén Serrano]

¿Quieres decir que dejar una conexión abierta mata la batería? Yo creo que si no hay circulación de datos, no hay gasto, porque no se produce ninguna operación en el sistema. De hecho, push funciona dejando una conexión abierta y manteniéndola para que no se cierre.

De todas formas, si son datos, me has convencido con tu sistema :)

2013/7/26 Javier Martin <barb...@gmail.com>

[Fernando Cejas]

hubieras avisado Iván. Entonces..porque no usar push? y cuando te llega el evento hacés un pull de los datos o en todo caso si es una pequeña cantidad la mandás con el mismo push...

Fernando Cejas

GDG Barcelona Organizer

@fernando_cejas

fce...@gmail.com

http://www.android10.org/

http://nfcquickactions.com

2013/7/26 Javier Martin <barb...@gmail.com>

[Fernando Cejas]

jjaja.. +1 Rubén. El "keep alive" que mantiene el push está optimizado al 100% aparte que usa la misma conexión para todos los servicios de Google. Creo que se podría hacer pero llegar al nivel de optimización del que tiene el SO costaría un pelín...

En fin, está bueno el debate para ir aprendiendo diferentes alternativas...

Iván...por ahí si detallás el propósito de tu app podemos ser mas específicos jeje ;)

Fernando Cejas

GDG Barcelona Organizer

@fernando_cejas

fce...@gmail.com

http://www.android10.org/

http://nfcquickactions.com

2013/7/26 Rubén Serrano <ake...@gmail.com>

[Rubén Serrano]

Por supuesto! No decía de reinventar el push XD Que GCM funciona muy bien XD

2013/7/26 Fernando Cejas <fce...@gmail.com>

[Oriol Jiménez]

Comento solo un par de utils que pueden ser interesantes en algún caso.

OkHttp (soporta spdy, si en el server tienes apache con el mod-spdy las conexiones serán mucho mas eficientes si las quieres mantener abiertas)

EventBus (me gusta mas que otto y broacastreceivers intra-app)

No se si te servirán para este caso especifico.

2013/7/26 Rubén Serrano <ake...@gmail.com>

[Fernando Cejas]

+1 a Oriol :)

Fernando Cejas

GDG Barcelona Organizer

@fernando_cejas

fce...@gmail.com

http://www.android10.org/

http://nfcquickactions.com

2013/7/26 Oriol Jiménez <ori...@gmail.com>

[Raúl Muñoz]

Subclasear Application es mala práctica?? :O

Oh my God, pues yo pasé de tener la costumbre de meter en variables estáticas/singletons a meter las cosas compartidas por toda la app en la subclase de Application (recomendación de un par de amigos, uno de ellos senior de Java).

Me di cuenta de comportamientos raros cuando tienes estáticas. Mantienen el valor aunque cierres la app. Aunque creo que pasa igual con la subclase de Application. Ambas viven mientras el SO no te mate la app, aunque la tengas cerrada (pulsando back), o mientras el usuario no haga Force Close.

Esto lo tengo comprobado, si cierras (force close) la app el Application pasa por el onTerminate y se libera.

Saludos

[David Lopez Dayer]

Yo también he usado una subclase de Application para guardar el datamodel de la app, y creo que no soy el único: 

http://stackoverflow.com/questions/708012/android-how-to-declare-global-variables 

http://brianwilliammee.com/2012/05/09/where-to-hold-global-application-state-in-android-apps/

Imagino que lo que dice Rubén se refiere a la documentación de la clase Application:

There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.

Por lo que parece que se puede hacer lo mismo con un singleton que haga referencia al Context.getApplicationContext().

Sin embargo no veo tampoco ningún problema en usar la subclase de Application, que como indican en la documentación:

Base class for those who need to maintain global application state. 

Espero que alguien pueda aportar más sobre el tema, que cuanto menos es interesante :)

Slds!

[Rubén Serrano]

Ojo, no decía que fuera mi opinión, si no lo que dice Google. He visto decir a Dianne Hackborn varias veces que lamenta mucho el día que se le ocurrió sugerir el uso de Application como sustituto de los singletons. Y de hecho, al principio en la documentación oficial de Android salía que el mejor singleton era el de Application, y que metiesemos todo allí, porque así se sabía seguro cuando se creaba y se destruía; y luego por el 2011 se ziscaron esa parte.

Para muestra, un botón: http://stackoverflow.com/questions/15048902/should-initialization-logic-say-for-numerous-singletons-be-in-oncreate-or-onre#comment21156839_15048937

2013/7/26 David Lopez Dayer <day...@gmail.com>

[iñaki]

más:

http://www.developerphil.com/dont-store-data-in-the-application-object/

https://plus.google.com/u/0/117230458394250799679/posts/DsfpW51Vvow

Iñaki

2013/7/26 Rubén Serrano <ake...@gmail.com>

[Xavi Rigau]

@Raul La documentación de Application.java dice:

public void onTerminate ()

Added in API level 1

This method is for use in emulated process environments. It will never be called on a production Android device, where processes are removed by simply killing them; no user code (including this callback) is executed when doing so.

El problema es que todo lo estático sigue vivo mientras el proceso de nuestra app siga vivo y además puede causar memory leaks. Así que lo mejor es ver en cada caso cual es la mejor opción, intentando evitar estáticos y Application dentro de lo posible, ya que tampoco es que no se deban usar, simplemente que siempre hay una solución más "limpia" ;)

Xavi Rigau (email me)

Mobile games & apps developer

@xrigau - xavirigau.com

[Raúl Muñoz]

Hola Iñaki,

en el caso del artículo de developerhill, desaconseja usar Application porque se podría dar el caso de nullpointerexceptions cuando Android mate la app y la vuelva a abrir, estando el Application en su estado inicial. En realidad los singletons sufrirían el mismo tipo de problema si no me equivoco, porque si el proceso es matado, los valores de las variables también desaparecen. Digamos que en este caso Application y singleton se comportan igual. Cuando se llaman para ser creados tienes un punto en el cual inicializar variables:

- Application pasa siempre por onCreate

- El singleton pasa siempre por MiClase.getInstance() (dentro del getInstance() llamas al if(instance == null){ instance = new MiClase(); } return instance;)

Ambas soluciones son iguales salvo que:

- En Application es solo un objeto y si tienes muchas variables no estaría bien organizado, mientras que con singleton, puedes separar variables según su temática y tenerlo más organizado.

- Al contrario de lo que dice la documentación el onTerminate sí se llama (comprobado en una app), de forma que tienes un lugar donde limpiar las variables. En singleton no tienes ese hook (a no ser que alguien sepa cómo)

Es decir, ambos tienen sus ventajas e inconvenientes pero está claro que los dos tienen el inconveniente de que si Android mata el proceso de tu app, cuando vuelves a la app con el task switcher, cosas raras pueden pasar.

PD: es una discusión muy interesante esta del Application vs Singleton!

Saludos

[Rubén Serrano]

Raul, un problema del onCreate como punto de inicialización de todos los "singletons reformados" es que probablemente acabes inicializando objetos que no necesites hasta bastante más tarde (o incluso que no se usen en una ejecución de la app), haciendo que baje el rendimiento de la app al inicializarse. Eso es lo que más crítica Dianne del hecho de tenerlo todo metido en Application.

2013/7/28 Raúl Muñoz <raul.munoz...@gmail.com>

[Raúl Muñoz]

Eso es, porque en el Application es siempre al inicio de la app y los singletons son on demmand. Me habéis convencido, singletons son mejores que Application. Aunque como dicen por ahí, si son cosas pequeñas, con intent extras mucho mejor.

[Joan Puig Sanz]

Para los singletons puedes usar RoboGuice. Hace la vida más sencilla a la hora de programar patrones como singleton, factory, etc

[Ramon]

RoboGuice va molt bé, la veritat que estalvia força mal de caps. Això si, té una penalització en temps d'execució força alta en projectes relativament grans i dispositius lents.

Semblant a RoboGuice hi ha Dagger (http://square.github.io/dagger/). La principal diferència és que Dagger genera codi en temps de compilació i no d'execució.

--

Ramon

[Joan Puig Sanz]

Per el 95% dels projectes que hi han al market, el performance no afectaria al projecte. Dagger te uns quants drawbacks que poden fer que el codi no sigui tan... entenedor, però sembla una bona opció també :)

Kind Regards / Met vriendelijke groeten / Saludos / Salutacions / Mange hilsner

-------------
Joan Puig Sanz

ServDroid.web: http://joanpuigsanz.github.io/servdroid/
BeyondAR (Augmented Reality Platform): http://beyondar.com/

2013/8/7 Ramon <oni....@gmail.com>

Has recibido este mensaje porque estás suscrito a un tema del grupo "GDG Barcelona" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/gdg-barcelona/t-rYltL-4VE/unsubscribe. Para anular la suscripción a este grupo y todos sus temas, envía un correo electrónico a gdg-barcelon...@googlegroups.com.

[Roc Boronat]

Ep! Ojito amb la performance! Hi ha gent que encara té HTC Hero i compra apps.

Roc Boronat

http://fewlaps.com

2013/8/7 Joan Puig Sanz <joanpu...@gmail.com>

[Joan Puig Sanz]

funciona be en un HTC Magic... ;)

Kind Regards / Met vriendelijke groeten / Saludos / Salutacions / Mange hilsner

-------------
Joan Puig Sanz

ServDroid.web: http://joanpuigsanz.github.io/servdroid/
BeyondAR (Augmented Reality Platform): http://beyondar.com/

2013/8/7 Roc Boronat <r...@fewlaps.com>