Necesita un proyecto de cliente REST de Android de muestra que implemente el patrón de implementación REST de Virgil Dobjanschi


82

Quiero construir un cliente REST en un teléfono Android.

El servidor REST expone varios recursos, p. Ej. (GET)

http://foo.bar/customer      List of all customer
http://foo.bar/customer/4711    The customer with id 4711
http://foo.bar/customer/vip     List of all VIP customer

http://foo.bar/company           List of all companys
http://foo.bar/company/4711     The company with the ID 4711
http://foo.bar/company/vip      List of all VIP companys

Creo que sé cómo hablar con el servidor REST y obtener la información que necesito. Implementaría una clase de cliente REST con una API como esta

public List<Customer> getCustomers();
public Customer getCustomer(final String id);
public List<Customer> getVipCustomer();

public List<Company> getCompanies();
public Customer getCompany(final String id);
public List<Customer> getVipCompanies();

Con referencia a la presentación " Desarrollo de aplicaciones cliente REST de Android " de Virgil Dobjanschi, aprendí que no es una buena idea manejar la solicitud REST en un subproceso de trabajo de la actividad. En su lugar, debería usar la API de servicio .

Me gusta la idea de tener un Singleton ServiceHelper que se une a un servicio (local), pero me temo que no entendí correctamente el concepto de servicio.

Por ahora, no entiendo cómo informar el resultado de una llamada REST (realizada de forma asincrónica en un Servicio) a la Actividad de la persona que llama. También me pregunto si necesito UN servicio que maneje todas las solicitudes de REST (con diferentes tipos de devolución) o si necesito un servicio dedicado para cada solicitud de REST.

Probablemente tengo muchos otros problemas de comprensión, por lo que lo mejor para mí sería una aplicación de muestra que satisfaga mis necesidades. Mi caso de uso no es inusual y espero que exista una aplicación de ejemplo.

¡Por favor, házmelo saber!

Cualquier otra sugerencia que me indique la dirección de implementación correcta también es útil (Android API-Demo no coincide con mi caso de uso).

Gracias por adelantado.

Klaus

EDITAR : Temas similares encontrados en SO (después de publicar esto) que me llevan en la dirección que necesito (minimizando el complejo "patrón Dobjanschi"):


1
Claszen, ¿Recibió alguna opinión sobre el servicio único para todas las solicitudes frente a los servicios dedicados para cada solicitud? Si es así, ¿puede compartirlo? Escenario en mi caso: tengo muchas solicitudes REST [alrededor de 20] para usar en mi aplicación. He visto la valiosa sesión en Google I / O mencionada anteriormente. Mi pregunta es cuál es el mejor enfoque. ¿Tener un solo servicio que maneje todas las solicitudes en un solo servicio? o tener un servicio dedicado para cada una de las solicitudes? Tengo algunas de las solicitudes que deberían activarse secuencialmente y algunas de ellas pueden activarse simultáneamente. Alguna sugerencia ?

@ user778869 Finalmente usé un IntentService y ResultReceiver para cada recurso REST ('nivel superior') (como 'empresa', 'cliente'). Encontré que esta es una especie de estructura 'natural' y funciona bien. Puede producir algunas duplicaciones de código, pero evita el uso excesivo de las estructuras de control si se hiciera todo en un solo servicio.
Viernes

Esto puede resultar muy útil para las personas que aprenden a implementar el cliente REST de Android. Transcripción de la presentación de Dobjanschi a PDF: drive.google.com/file/d/0B2dn_3573C3RdlVpU2JBWXdSb3c/…
Kay Zed

Respuestas:


50

Visión de conjunto

Editar:

Cualquier persona interesada también considere echar un vistazo a Android RESTful, esto podría darle una mejor visión al respecto.

Lo que aprendí de la experiencia al intentar implementar el modelo Dobjanschi es que no todo está escrito en piedra y él solo le brinda una descripción general de qué hacer, esto podría cambiar de una aplicación a otra, pero la fórmula es:

Siga estas ideas + Agregue la suya propia = Aplicación de Android feliz

El modelo en algunas aplicaciones puede variar del requisito, algunas pueden no necesitar la Cuenta para SyncAdapter, otras pueden usar C2DM, esta en la que trabajé recientemente podría ayudar a alguien:


Cree una aplicación que tenga Account y AccountManager

Le permitirá utilizar SyncAdapter para sincronizar sus datos. Esto se ha discutido en Cree su propio SyncAdapter

Cree un ContentProvider (si se adapta a sus necesidades)

Esta abstracción le permite no solo acceder a la base de datos, sino que va al ServiceHelper para ejecutar llamadas REST, ya que tiene un método de mapeo uno por uno con el REST Arch.

Proveedor de contenido | Método REST

consulta ----------------> OBTENER

insertar ----------------> PONER

actualizar ----------------> POST

eliminar ----------------> BORRAR

Capas de ServiceHelper

Básicamente, este tipo iniciará (un) servicio (s) que ejecutan un método REST Http (no necesariamente el protocolo, pero es el más común) con los parámetros que pasó desde ContentProvider. Pasé el entero de coincidencia que se obtiene de UriMatcher en el proveedor de contenido, así que sé a qué recurso REST acceder, es decir

class ServiceHelper{

    public static void execute(Context context,int match,String parameters){
//find the service resource (/path/to/remote/service with the match
//start service with parameters 
    }

}

El servicio

Se ejecuta (yo uso IntentService la mayor parte del tiempo) y va al método RESTM con los parámetros pasados ​​desde el ayudante, ¿para qué sirve? Recuerde que el servicio es bueno para ejecutar cosas en segundo plano.

También implemente un BroadCastReceiver para que cuando el servicio termine con su trabajo notifique a mi Actividad que registró esta Transmisión y vuelva a consultar. Creo que este último paso no está en la Conferencia Virgill, pero estoy bastante seguro de que es un buen camino a seguir.

Clase RESTMethod

Toma los parámetros, el recurso WS ( http://myservice.com/service/path ) agrega los parámetros, prepara todo, ejecuta la llamada y guarda la respuesta.

Si se necesita el authtoken, puede solicitarlo al AccountManager. Si la llamada del servicio falló debido a la autenticación, puede invalidar el authtoken y volver a autenticar para obtener un nuevo token.

Finalmente, el método RESTM me da un XML o JSON sin importar si creo un procesador basado en el comparador y paso la respuesta.

El procesador

Se encarga de analizar la respuesta e insertarla localmente.

¿Una aplicación de muestra? ¡Por supuesto!

Además, si está interesado en una aplicación de prueba, mira Eli-G , puede que no sea el mejor ejemplo, pero sigue el enfoque Service REST, está construido con ServiceHelper, Processor, ContentProvider, Loader y Broadcast.


Gracias por tu respuesta. Finalmente utilicé un IntentService y ResultReceiver para cada recurso REST ('nivel superior') (como 'empresa', 'cliente'). El modelo Dobjanschi era demasiado pesado para mí.
Viernes

bueno, si usa IntentService y ResultReseiver, probablemente use el primer escenario de descripción que es un modelo impulsado por el servicio, aunque él usa Binder en lugar de ResultReceiver para la comunicación, ¡pero eso es bueno, como dije, no está escrito en piedra !.
Necronet

Hace algún tiempo que hice la pregunta y encontré una solución que me encajaba. No tuve la posibilidad de verificar todas las referencias a aplicaciones de muestra, pero como esta es la respuesta más actualizada, la aceptaré. Sin embargo, recomiendo verificar todas las demás respuestas también.
Viernes

Excelente sugerencia, marque todas las respuestas, todas tienen muchos buenos recursos e ideas !! como Jeremy con el libro de programación de Android Yoni con la fuente iosched.
Necronet

@Necronet hola, acabo de tropezar con su prometedora aplicación de muestra; sin embargo, tengo problemas para construirla. ¿Le importaría decirnos contra qué versión de ActionBarSherlock tiene que construirse (parece que no funciona con la última versión de ABS 4.1)? Además, de tu publicación no descubrí realmente a qué patrón (A, B o C) de los modelos de Dobjanschi estabas apuntando (lo sé, probablemente terminaste con algunas variaciones, pero supongo que te estabas enfocando principalmente en uno de los patrones - ¿supongo que el patrón B?) ¡Gracias!
vaiomike

17

La programación de Android tiene un capítulo completo (13. Exploración de proveedores de contenido) dedicado a la 'Opción B: Use la API ContentProvider' de la charla de I / O de Google de Virgil.

No somos los únicos que vemos los beneficios de este enfoque. En la conferencia de Google I / O en mayo de 2010, Virgil Dobjanschi de Google presentó una charla que describió los siguientes tres patrones para usar proveedores de contenido para integrar servicios web RESTful en aplicaciones de Android ...

En este capítulo, exploraremos el segundo patrón en detalle con nuestro segundo ejemplo de video de Finch; esta estrategia producirá una serie de beneficios importantes para sus aplicaciones. Debido a la elegancia con la que este enfoque integra las operaciones de red en Android MVC, le hemos dado el nombre de "Network MVC".

Una edición futura de Programming Android puede abordar los otros dos enfoques, así como documentar más detalles de esta presentación de Google. Una vez que termine de leer este capítulo, le sugerimos que vea la charla de Google.

Muy recomendable.

Programación de Android por Zigurd Mednieks, Laird Dornin, G. Blake Meike y Masumi Nakamura. Copyright 2011 O'Reilly Media, Inc., 978-1-449-38969-7.


11

"El desarrollo de aplicaciones cliente REST de Android" de Virgil Dobjanschi generó mucha discusión, ya que no se presentó el código fuente durante la sesión ni se proporcionó posteriormente.

Por favor comente si conoce más implementaciones.


Gracias por compartir este enlace probablemente útil (no tengo la oportunidad de echar un vistazo más profundo en este momento)
FrVaBe

Eso parece una solución. Gracias !
Vincent Cantin

7

Hemos desarrollado una biblioteca que aborda este problema: RoboSpice .

La biblioteca utiliza el "enfoque de servicio" descrito por Virgil Dobjanschi y Neil Goodmann , pero ofrecemos una completa solución todo en uno que:

  • ejecuta de forma asíncrona (en un AndroidService en segundo plano) solicitudes de red que devolverán POJO (por ejemplo, solicitudes REST)
  • almacena en caché los resultados (en Json o Xml, o archivos de texto plano o archivos binarios)
  • notifica sus actividades (o cualquier otro contexto) del resultado de la solicitud de red si todavía están vivas
  • no notifica sus actividades sobre el resultado si ya no están vivos
  • notifica sus actividades en su hilo de interfaz de usuario
  • utiliza un modelo de manejo de excepciones simple pero robusto
  • admite múltiples ContentServices para agregar diferentes resultados de servicios web
  • admite múltiples subprocesos de ejecuciones de solicitudes
  • está fuertemente tipado!
  • es de código abierto;)
  • y probado

De hecho, estamos buscando comentarios de la comunidad.


4

La modificación podría ser muy útil aquí, crea un adaptador para usted a partir de una configuración muy simple como:

Retrofit convierte su API REST en una interfaz Java.

public interface GitHubService {
  @GET("/users/{user}/repos")
  List<Repo> listRepos(@Path("user") String user);
}

La clase RestAdapter genera una implementación de la interfaz GitHubService.

RestAdapter restAdapter = new RestAdapter.Builder()
    .setEndpoint("https://api.github.com")
    .build();

Servicio GitHubService = restAdapter.create (GitHubService.class); Cada llamada en el GitHubService generado realiza una solicitud HTTP al servidor web remoto.

List<Repo> repos = service.listRepos("octocat");

para obtener más información, visite el sitio oficial: http://square.github.io/retrofit/

Nota : el adaptador RestAdapterque obtiene de Retrofit no se deriva de BaseAdapterusted debe crear un contenedor para él de alguna manera como esta pregunta SO ¿ Por qué mi ListView está vacío después de llamar a setListAdapter dentro de ListFragment?


¿Puede publicar un ejemplo completo llamando a un servicio de descanso como api.icndb.com/jokes/random
exequielc


3

Para empezar, debe consultar el código fuente de la aplicación I / O 2010 oficial de Google , en particular SyncService y las diversas clases del subpaquete io .


+1 No es realmente mi caso de uso, pero en cualquier caso es un buen y útil ejemplo de aplicación de Android. ¡Gracias!
Viernes

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.