|
Programación y Desarrollo para Android Subforo exclusivo para temas de programación de software para PDAs y desarrollo de aplicaciones, interfaces, etc bajo Android |
|
Herramientas |
#1
|
||||
|
||||
Compartir con redes sociales
Hola, mi pregunta iba referida como el título indica a compatir en redes sociales, estoy buscando información y me gustaría preguntar más y salir de dudas.
La idea es publicar un mensaje con una imagen en Facebook, Instagram y Twitter por ahora. - Alguien conoce alguna librería, que integre ya la posibilidad de compartir con N redes sociales? (pregunto desde la ignorancia) - He de hacer el código independiente con cada una de ellas? Como digo, simplemente quiero información y un poco colocarme en situación y que me deis alguna sugerencia en cuanto al librerías?. Gracias de antemano. |
|
#2
|
||||
|
||||
Antes que una biblioteca para la app vería más factible un servicio web que hiciera eso (le pasas el mensaje con la foto y ya se encarga de publicarlo en varias redes).
Eso se presta a servicios de pago porque es un valor añadido importante al no tener que lidiar con bibliotecas, APIs, que si hoy te cambio una cosa y mañana otra y la app ya no es compatible. Existen "unificadores" de redes sociales, ya es ver si te compensa. En cualquier caso intentaría evitar que la lógica de hablar con cada red social estuviera en la app, más si es para publicar en varias (que la app suba una imagen vale, si la tiene que subir cinco veces es un gasto innecesario de batería y ancho de banda). Un servidor en node.js o vert.x con OAuth que "ataque" a las API de cada proveedor es más gestionable. Si me dices que es una app para usuarios muy concretos, como community managers, entonces igual no les importa que la imagen se suba cinco veces o que tenga que actualizar la app más frecuentemente porque al fin y al cabo es su trabajo. Si es para compartir un logro de un juego no
__________________
El mejor Cuatro en Raya de Android (Hilo en HTCMania, Play Store) ¡Un millón de descargas!
|
Gracias de parte de: | ||
#3
|
||||
|
||||
Lo fácil es usar el ACTION_SEND y restringir las aplicaciones a esas 3.
Aquí tienes un ejemplo de como hacerlo para Facebook, Twitter y MMS. Modificarlo para que sea Instagram no es complicado: http://stackoverflow.com/questions/9...erent-text-for ¿La pega? Que el usuario tiene que tener instaladas las 3 aplicaciones y configuradas con su usuario, ya que realmente lo que haces es pasarle la pelota a esas apps para que publiquen, además de que el usuario tiene que intervenir. Si quieres que la publicación sea automática, tienes que usar el API de cada una de esas redes sociales, que en el caso de Twitter es bastante sencilla y en el caso de Facebook es bastante desagradable, además de que lo cambian cada 2x3 obligándote a tener que rehacer tu app. Además, salvo que la cosa haya cambiado, en el caso de Facebook es obligatorio tener la app instalada, aunque no logeado (salvo que uses el modo SSO), desde que obligaron que para usar la API de Facebook tenías que enviar las apps a validación no lo uso y no se como está actualmente. En cuanto a la forma de usarlas, en los 3 casos es similar, necesitas un Client Id y un Client Secret que obtienes registrándote en las páginas de desarrollador de cada una de las plataformas y dando de alta tu app. A partir de ahí las 3 funcionan mediante OAuth 2.0, teniéndose que logear el usuario en un WebClient y autorizar a tu app, a partir de ese momento obtienes un token con el que ya usando el API puedes publicar. EDIT: Se me adelantó mocelet. |
Gracias de parte de: | ||
#4
|
||||
|
||||
Antes que una biblioteca para la app vería más factible un servicio web que hiciera eso (le pasas el mensaje con la foto y ya se encarga de publicarlo en varias redes).
Eso se presta a servicios de pago porque es un valor añadido importante al no tener que lidiar con bibliotecas, APIs, que si hoy te cambio una cosa y mañana otra y la app ya no es compatible. Existen "unificadores" de redes sociales, ya es ver si te compensa. En cualquier caso intentaría evitar que la lógica de hablar con cada red social estuviera en la app, más si es para publicar en varias (que la app suba una imagen vale, si la tiene que subir cinco veces es un gasto innecesario de batería y ancho de banda). Un servidor en node.js o vert.x con OAuth que "ataque" a las API de cada proveedor es más gestionable. Si me dices que es una app para usuarios muy concretos, como community managers, entonces igual no les importa que la imagen se suba cinco veces o que tenga que actualizar la app más frecuentemente porque al fin y al cabo es su trabajo. Si es para compartir un logro de un juego no Estoy contigo, pues cada dos por tres pueden cambiarte la cosa y se hace la app incompatible, así que toma más fuerza esta opción, pues así me quito de andar actualizando la app. Gracias. |
#5
|
||||
|
||||
Lo fácil es usar el ACTION_SEND y restringir las aplicaciones a esas 3.
Aquí tienes un ejemplo de como hacerlo para Facebook, Twitter y MMS. Modificarlo para que sea Instagram no es complicado: http://stackoverflow.com/questions/9...erent-text-for ¿La pega? Que el usuario tiene que tener instaladas las 3 aplicaciones y configuradas con su usuario, ya que realmente lo que haces es pasarle la pelota a esas apps para que publiquen, además de que el usuario tiene que intervenir. Si quieres que la publicación sea automática, tienes que usar el API de cada una de esas redes sociales, que en el caso de Twitter es bastante sencilla y en el caso de Facebook es bastante desagradable, además de que lo cambian cada 2x3 obligándote a tener que rehacer tu app. Además, salvo que la cosa haya cambiado, en el caso de Facebook es obligatorio tener la app instalada, aunque no logeado (salvo que uses el modo SSO), desde que obligaron que para usar la API de Facebook tenías que enviar las apps a validación no lo uso y no se como está actualmente. En cuanto a la forma de usarlas, en los 3 casos es similar, necesitas un Client Id y un Client Secret que obtienes registrándote en las páginas de desarrollador de cada una de las plataformas y dando de alta tu app. A partir de ahí las 3 funcionan mediante OAuth 2.0, teniéndose que logear el usuario en un WebClient y autorizar a tu app, a partir de ese momento obtienes un token con el que ya usando el API puedes publicar. EDIT: Se me adelantó mocelet. Lanzo la pregunta, sí se da el caso de que la red social está instalada usar directamente el metodo que comenta kriogeN y de no ser así usar la opción que comenta mocelet? Cómo lo veis, lo mismo me estoy complicando, pues la opción de mocelet me quita todo el entuerto tenga o no instalada la app. Gracias. |
#6
|
||||
|
||||
Sí esta opción la he utilizado alguna vez, pues pienso, que hoy en día, todo el mundo tendrá la app de su red social más usada en su móvil, pero conozco a gente que no, aunque ahora que lo pienso, no sé si sería bueno combinar ambas opciones, es decir:
Lanzo la pregunta, sí se da el caso de que la red social está instalada usar directamente el metodo que comenta kriogeN y de no ser así usar la opción que comenta mocelet? Cómo lo veis, lo mismo me estoy complicando, pues la opción de mocelet me quita todo el entuerto tenga o no instalada la app. Gracias. Eso usando los SDK de las redes sociales te viene "automatizado". Además en el caso de Facebook (como he comentado antes) deberás pasar el proceso de validación, y no se si a Facebook le hará gracia que sea tu servidor el que almacene ambos tokens y no su SDK. |
#7
|
||||
|
||||
Ten en cuenta que para la opción que comenta mocelet tienes que almacenar los tokens en tu servidor y ligarlos a un token interno que tendrás que pasar en cada llamada. Eso si quieres publicar en el nombre del usuario, si quieres hacerlo en el tuyo propio no lo necesitas. También ten en cuenta que tendrás que hacer el proceso de Refresh y por tanto deberás almacenar los Refresh Token también.
Eso usando los SDK de las redes sociales te viene "automatizado". Además en el caso de Facebook (como he comentado antes) deberás pasar el proceso de validación, y no se si a Facebook le hará gracia que sea tu servidor el que almacene ambos tokens y no su SDK. Al final lo más conveniente será utilizar su propio SDK, y tener que asumir que si cambian algo, he de actualizar la app. Gracias. |
#8
|
||||
|
||||
Siempre he leído en la documentación de Facebook y ahí sigue sin cambiar que los token son portátiles y los puedes comunicar al servidor para hacer llamadas. Lo que sí te piden es que lo envíes por HTTPS para mayor seguridad.
https://developers.facebook.com/docs...s#architecture (apartado los token son portátiles) Cada opción tiene sus ventajas EDIT: Cierto que no pone "almacenar el token" en ningún sitio, solo habla de enviarlo para realizar llamadas en el servidor (que presupone un almacenamiento temporal mientras haces la llamada). Tampoco es que te haga falta almacenarlo para nada, con incluir el token en la petición donde iría el mensaje y la imagen basta, y lo puedes guardar en el propio cliente para ahorrarte base de datos de tokens en el servidor.
__________________
El mejor Cuatro en Raya de Android (Hilo en HTCMania, Play Store) ¡Un millón de descargas!
Última edición por mocelet Día 18/04/17 a las 12:00:27. |
#9
|
||||
|
||||
Siempre he leído en la documentación de Facebook y ahí sigue sin cambiar que los token son portátiles y los puedes comunicar al servidor para hacer llamadas. Lo que sí te piden es que lo envíes por HTTPS para mayor seguridad.
https://developers.facebook.com/docs...s#architecture (apartado los token son portátiles) Cada opción tiene sus ventajas EDIT: Cierto que no pone "almacenar el token" en ningún sitio, solo habla de enviarlo para realizar llamadas en el servidor (que presupone un almacenamiento temporal mientras haces la llamada). Tampoco es que te haga falta almacenarlo para nada, con incluir el token en la petición donde iría el mensaje y la imagen basta, y lo puedes guardar en el propio cliente para ahorrarte base de datos de tokens en el servidor. Que no es mucho la verdad, en lugar de almacenar podrías hacer "tokenfb=.........&tokentw=............&tokenin=.. ............." |
#10
|
||||
|
||||
|
Estás aquí | ||||||
|