java - Necesita ejemplo del proyecto REST Client de Android que implementa el patrón de implementación REST de Virgil Dobjanschi
design-patterns (8)
Quiero construir un cliente REST en un teléfono Android.
El servidor REST expone varios recursos, por ejemplo, (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
Yo (creo) 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();
Refiriéndome a la presentación " Desarrollo de aplicaciones de cliente REST de Android " de Virgil Dobjanschi, aprendí que no es una buena idea manejar la solicitud REST en un hilo trabajador de la actividad. En su lugar, debería usar la API de Service .
Me gusta la idea de tener un Singleton ServiceHelper que se una a un Servicio (Local) pero me temo que no entendí el concepto de Servicio correcto.
Por ahora, no entiendo cómo informar un resultado de llamada REST (hecho de manera asincrónica en un Servicio) a la Actividad llamante. 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, así 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.
¿Podrías decirme por favor?
Cualquier otra sugerencia que me señale en la dirección correcta de implementación 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"):
Visión de conjunto
Editar:
Cualquier persona interesada también considera echarle un vistazo a RESTful Android, esto podría darle una mejor perspectiva al respecto.
Lo que aprendí de la experiencia al tratar de implementar el Modelo Dobjanschi, es que no todo está escrito en piedra y solo le da una visión general de qué hacer, esto podría cambiar de una aplicación a otra, pero la fórmula es:
Sigue estas ideas + Agrega tu propia aplicación = Feliz Android
El modelo en algunas aplicaciones puede variar de un requisito que algunos pueden no necesitar. La cuenta para SyncAdapter podría usar C2DM, esta que he trabajado recientemente podría ayudar a alguien:
Cree una aplicación que tenga Account y AccountManager
Le permitirá usar SyncAdapter para sincronizar sus datos. Esto se ha discutido en Crea tu propio SyncAdapter
Crea un ContentProvider (si se adapta a tus 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 asignación uno a uno con el arco REST.
Proveedor de contenido | Método REST
consulta ----------------> GET
insertar ----------------> PUT
actualización ----------------> POST
eliminar ----------------> ELIMINAR
Capa de Capacitacion de Servicio
Este tipo básicamente iniciará (a) un servicio (s) que ejecute un método Http (no necesariamente el protocolo, pero es el más común) REST con los parámetros que pasó de ContentProvider. Pasé el entero del partido 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 (utilizo IntentService la mayor parte del tiempo) y va al RESTMethod con los parámetros pasados por el ayudante, ¿para qué sirve? recuerde que el servicio es bueno para ejecutar las cosas en segundo plano.
También implemente un BroadCastReceiver para que cuando el servicio finalice con su trabajo notifique a mi Actividad que registró este Broadcast 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 authtoken, puede solicitarlo al AccountManager. Si la llamada del servicio falló debido a la autenticación, puede invalidar el authtoken y reautorizar para obtener un nuevo token.
Finalmente, RESTMethod me proporciona XML o JSON sin importar si creo un procesador basado en el matcher y paso la respuesta.
El procesador
Está encargado de analizar la respuesta e insertarla localmente.
Una aplicación de muestra? ¡Por supuesto!
Además, si eres interesante en una aplicación de prueba que ves en Eli-G , puede que no sea el mejor ejemplo pero sigue el enfoque de RESTO de servicio, está construido con ServiceHelper, Processor, ContentProvider, Loader y Broadcast.
"Desarrollo de aplicaciones de cliente REST de Android" por Virgil Dobjanschi condujo a mucha discusión, ya que no se presentó ningún código fuente durante la sesión o se proporcionó después.
- Una implementación de referencia está disponible en http://datadroid.foxykeep.com (la sesión de Google IO se menciona en / presentation). Es una biblioteca que puedes usar en tu propia aplicación.
- Android Priority Job Queue se inspiró en la charla de Dobjanschi y me parece muy prometedor.
Comente si conoce más implementaciones.
Buenas noticias chicos. Una implementación del servicio de ayuda está disponible aquí: https://github.com/MathiasSeguy-Android2EE/MythicServiceHelper Es un proyecto de código abierto (Apache 2). Estoy al comienzo del proyecto. He hecho un proyecto en el que definí el patrón para hacer, pero aún no he extraído el código para hacer un librairy limpio. Será hecho pronto.
Debería consultar el código fuente de la aplicación oficial de E / S 2010 de Google, para empezar, particularmente el SyncService y las diversas clases en el subpaquete io .
Esto es un poco tarde, pero aquí hay un artículo que explica el primer patrón de la conversación:
http://www.codeproject.com/Articles/429997/Sample-Implementation-of-Virgil-Dobjanschis-Rest-p
Lo que más me gusta del primer patrón es que la interfaz con los métodos restantes es una clase simple, y el proveedor de contenido simplemente deja acceso a la base de datos.
Hemos desarrollado una biblioteca que aborda este tema: RoboSpice .
La biblioteca utiliza el "enfoque de servicio" descrito por Virgil Dobjanschi y Neil Goodmann , pero ofrecemos una solución todo en uno completa que:
- ejecuta de forma asincrónica (en un AndroidService de fondo) solicitudes de red que devolverán POJO (por ejemplo, solicitudes de REST)
- resultados de caché (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 tus actividades del resultado si ya no están vivas
- notifica tus actividades en su 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 multi-threading de ejecuciones de solicitudes
- está fuertemente tipado!
- es de código abierto;)
- y probado
En realidad estamos buscando comentarios de la comunidad.
Programación Android tiene un capítulo completo (13. Exploración de proveedores de contenido) dedicado a ''Opción B: Usar la API ContentProvider'' de la charla de E / S de Virgil en Google.
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 describía los tres patrones siguientes 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 arrojará 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 apodo de "Network MVC".
Una futura edición de Programación de Android puede abordar los otros dos enfoques, así como documentar más detalles de esta presentación de Google. Cuando termine de leer este capítulo, le sugerimos que vea la conversación 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.
La modificación podría ser muy útil aquí, construye un Adaptador para usted desde 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 RestAdapter que obtienes de Retrofit no se deriva de BaseAdapter , deberías crear un contenedor para él de alguna manera como este SO. Pregunta ¿Por qué mi ListView está vacío después de llamar a setListAdapter dentro de ListFragment?