Potrzebujesz przykładowego projektu klienta REST dla Androida, który implementuje wzorzec implementacji REST Virgila Dobjanschi

82

Chcę zbudować klienta REST na telefonie z Androidem.

Serwer REST udostępnia kilka zasobów, np. (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

Myślę, że wiem, jak rozmawiać z serwerem REST i uzyskać potrzebne informacje. Zaimplementowałbym klasę klienta REST z takim API

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();

Odnosząc się do prezentacji „ Tworzenie aplikacji klienckich REST dla systemu Android ” autorstwa Virgila Dobjanschiego, dowiedziałem się, że obsługa żądania REST w wątku roboczym działania nie jest dobrym pomysłem. Zamiast tego powinienem użyć Service API.

Podoba mi się pomysł posiadania Singleton ServiceHelper, który wiąże się z (lokalną) usługą, ale obawiam się, że nie rozumiem poprawnie koncepcji usługi.

Na razie nie rozumiem, jak zgłosić wynik wywołania REST (wykonany asynchronicznie w usłudze) z powrotem do aktywności dzwoniącego. Zastanawiam się również, czy potrzebuję JEDNEJ usługi, która obsługuje wszystkie żądania REST (z różnymi typami zwrotów), czy też potrzebuję dedykowanej usługi dla każdego żądania REST.

Prawdopodobnie mam wiele innych problemów ze zrozumieniem, więc najlepszą rzeczą dla mnie byłaby przykładowa aplikacja, która spełnia moje potrzeby. Mój przypadek użycia nie jest niezwykły i mam nadzieję, że istnieje przykładowa aplikacja.

Czy mógłbyś dać mi znać!

Wszelkie inne sugestie, które wskazują mi właściwy kierunek implementacji, są również pomocne (Android API-Demo nie pasuje do mojego przypadku użycia).

Z góry dziękuję.

Klaus

EDYCJA : Podobne tematy znalezione w SO (po opublikowaniu tego), które prowadzą mnie w pożądanym kierunku (minimalizując złożony „wzór Dobjanschi”):

java  android  design-patterns  rest 
— FrVaBe
źródło
1
Claszen, Czy dostałeś opinię na temat jednej usługi dla wszystkich zgłoszeń w porównaniu z usługami dedykowanymi dla każdego zapytania? Jeśli tak, to podziel się. Scenariusz w moim przypadku: mam wiele żądań REST [około 20] do wykorzystania w mojej aplikacji. Obejrzałem cenną sesję w Google I / O wspomnianą powyżej. Moje pytanie brzmi: które podejście jest lepsze. Czy jedna usługa obsługuje wszystkie żądania w ramach jednej usługi? czy mieć dedykowaną usługę dla każdego z żądań? Mam kilka żądań, które powinny być uruchamiane sekwencyjnie, a niektóre z nich mogą być uruchamiane jednocześnie. Jakieś sugestie ?
@ user778869 W końcu użyłem jednej usługi IntentService i ResultReceiver dla każdego („najwyższego poziomu”) zasobu REST (takiego jak „firma”, „klient”). Odkryłem, że to rodzaj „naturalnej” struktury i działa dobrze. Może powodować duplikacje kodu, ale zapobiega zbyt dużemu wykorzystaniu struktur kontrolnych, gdyby było to wykonywane w jednej usłudze.
— FrVaBe
Może to być bardzo pomocne dla osób uczących się implementacji klienta REST systemu Android. Prezentacja Dobjanschiego przepisana na plik PDF: drive.google.com/file/d/0B2dn_3573C3RdlVpU2JBWXdSb3c/ ...
— Kay Zed,

Odpowiedzi:

50

Przegląd

Edytować:

Każdy zainteresowany również rozważ przyjrzenie się RESTful android, co może dać ci lepszy obraz.

Z doświadczenia przy wdrażaniu modelu Dobjanschiego dowiedziałem się, że nie wszystko jest napisane w kamieniu, a on daje tylko przegląd tego, co należy zrobić, może się zmienić z aplikacji na aplikację, ale formuła jest taka:

Postępuj zgodnie z tymi pomysłami + Dodaj własną aplikację = Happy Android

Model w niektórych aplikacjach może się różnić od wymagań, niektóre mogą nie potrzebować konta dla SyncAdapter, inne mogą używać C2DM, ten, nad którym ostatnio pracowałem, może komuś pomóc:

Utwórz aplikację, która ma Account i AccountManager

Umożliwi to użycie SyncAdapter do synchronizacji danych. Zostało to omówione w temacie Utwórz własny SyncAdapter

Utwórz ContentProvider (jeśli odpowiada Twoim potrzebom)

Ta abstrakcja umożliwia nie tylko dostęp do bazy danych, ale także przechodzi do ServiceHelpera w celu wykonania wywołań REST, ponieważ ma metodę mapowania jeden na jeden z Arch REST.

Dostawca treści | Metoda REST

zapytanie ----------------> GET

wstaw ----------------> PUT

aktualizacja ----------------> POST

usuń ----------------> USUŃ

ServiceHelper Layering

Ten facet po prostu uruchomi (a) usługę (y), które wykonują metodę REST (niekoniecznie protokół, ale jest to najbardziej powszechna) z parametrami przekazanymi z ContentProvider. Przekazałem dopasowaną liczbę całkowitą, która jest pobierana z UriMatchera w dostawcy treści, więc wiem, do którego zasobu REST mam dostęp, tj.

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 
    }

}

Obsługa

Zostaje wykonany (przez większość czasu używam IntentService) i przechodzi do metody RESTMethod z parametrami przekazanymi przez helpera, do czego to jest dobre? pamiętaj, że Serwis dobrze działa w tle.

Zaimplementuj także BroadCastReceiver, aby po zakończeniu usługi powiadomić moją aktywność, która zarejestrowała tę transmisję i ponownie poprosić. Wierzę, że ten ostatni krok nie jest na konferencji Virgill, ale jestem pewien, że jest to dobry sposób.

Klasa RESTMethod

Pobiera parametry, zasób WS ( http://myservice.com/service/path ) dodaje parametry, przygotowuje wszystko, wykonuje wywołanie i zapisuje odpowiedź.

Jeśli potrzebny jest authtoken, możesz zażądać od AccountManager. Jeśli wywołanie usługi nie powiodło się z powodu uwierzytelnienia, możesz unieważnić authtoken i ponownie uwierzytelnić, aby uzyskać nowy token.

Wreszcie metoda RESTMethod daje mi XML lub JSON bez względu na to, czy utworzę procesor oparty na dopasowywaniu i przekażę odpowiedź.

Procesor

Odpowiada za analizowanie odpowiedzi i wstawianie jej lokalnie.

Przykładowa aplikacja? Oczywiście!

Również jeśli interesuje Cię aplikacja testowa, którą patrzysz na Eli-G , może nie być najlepszym przykładem, ale jest ona zgodna z podejściem Service REST, jest zbudowana przy użyciu ServiceHelper, Processor, ContentProvider, Loader i Broadcast.

— Necronet
źródło
Dzięki za odpowiedź. W końcu użyłem jednego IntentService i ResultReceiver dla każdego zasobu REST („najwyższego poziomu”) (np. „Firma”, „klient”). Model Dobjanschi był dla mnie o wiele za ciężki.
— FrVaBe
cóż, b używając IntentService i ResultReseiver prawdopodobnie używasz pierwszego scenariusza opisu, który jest modelem opartym na usłudze, chociaż używa on Bindera zamiast ResultReceiver do komunikacji, ale to dobrze, jak powiedziałem, nie jest napisane w kamieniu !.
— Necronet
Zadałem to pytanie jakiś czas temu i znalazłem pasujące dla mnie rozwiązanie. Nie miałem możliwości sprawdzenia wszystkich odniesień do przykładowych aplikacji - ale ponieważ jest to najbardziej aktualna odpowiedź, zaakceptuję ją. Niemniej jednak polecam też sprawdzić wszystkie inne odpowiedzi.
— FrVaBe
Doskonała sugestia, sprawdź wszystkie odpowiedzi, wszyscy mają dużo dobrych zasobów i pomysłów !! jak Jeremy z książką Programming Android Yoni ze źródłami iosched.
— Necronet
@Necronet cześć, właśnie natknąłem się na Twoją obiecującą przykładową aplikację - jednak mam problemy z jej zbudowaniem. Czy mógłbyś nam powiedzieć, dla której wersji ActionBarSherlock ma być zbudowany (wygląda na to, że nie działa z najnowszym ABS 4.1)? Poza tym z twojego postu nie dowiedziałem się, do jakiego wzoru (A, B lub C) modeli Dobjanschiego dążyłeś (wiem, prawdopodobnie skończyłeś z pewnymi wariacjami, ale przypuszczam, że skupiłeś się głównie na jednym z wzory - chyba wzór B?) Dzięki!
— vaiomike
17

Programowanie Android ma pełny rozdział (13. Exploring Content Providers) poświęcony „Opcji B: Use the ContentProvider API” z omówienia Google I / O firmy Virgil.

Nie tylko my widzimy korzyści płynące z tego podejścia. Na konferencji Google I / O w maju 2010 r. Virgil Dobjanschi z Google przedstawił referat, w którym nakreślił następujące trzy wzorce wykorzystywania dostawców treści do integracji usług sieciowych RESTful z aplikacjami na Androida ...

W tym rozdziale omówimy szczegółowo drugi wzór w naszym drugim przykładzie wideo Finch; ta strategia przyniesie wiele ważnych korzyści dla Twoich aplikacji. Ze względu na elegancję, z jaką to podejście integruje operacje sieciowe z systemem Android MVC, nadaliśmy mu nazwę „Network MVC”.

Przyszłe wydanie Programming Android może uwzględniać pozostałe dwa podejścia, a także dokumentować więcej szczegółów tej prezentacji Google. Po przeczytaniu tego rozdziału proponujemy zapoznać się z przemówieniem Google.

Wysoce rekomendowane.

Programowanie na Androida przez Zigurda Mednieksa, Lairda Dornina, G. Blake'a Meike'a i Masumi Nakamurę. Copyright 2011 O'Reilly Media, Inc., 978-1-449-38969-7.

— Jeremy Haberman
źródło
11

„Tworzenie aplikacji klienckich Android REST” autorstwa Virgila Dobjanschiego wywołało wiele dyskusji, ponieważ podczas sesji nie przedstawiono żadnego kodu źródłowego ani nie dostarczono go później.

  • Implementacja wzorcowa jest dostępna pod adresem http://datadroid.foxykeep.com (sesja Google IO jest wymieniona w sekcji / prezentacja). Jest to biblioteka, z której możesz korzystać we własnej aplikacji.
  • Android Priority Job Queue został zainspirowany przemówieniem Dobjanschiego i brzmi dla mnie bardzo obiecująco.

Prosimy o komentarz, jeśli znasz więcej implementacji.

— ChrLipp
źródło
Dzięki za udostępnienie tego prawdopodobnie przydatnego linku (nie mam szansy przyjrzeć się dokładniej w tej chwili)
— FrVaBe
To wygląda na rozwiązanie. Dziękuję Ci !
— Vincent Cantin
7

Opracowaliśmy bibliotekę, która zajmuje się tym problemem: RoboSpice .

Biblioteka korzysta z „podejścia usługowego” opisanego przez Virgila Dobjanschiego i Neila Goodmanna , ale oferujemy kompletne rozwiązanie typu „wszystko w jednym”, które:

  • wykonuje asynchronicznie (w tle AndroidService) żądania sieciowe, które zwrócą POJO (np. żądania REST)
  • buforuje wyniki (w formacie Json lub Xml albo w zwykłych plikach tekstowych lub w plikach binarnych)
  • powiadamia Twoje działania (lub w jakimkolwiek innym kontekście) o wyniku żądania sieciowego, jeśli nadal są aktywne
  • nie powiadamia twoich działań o wyniku, jeśli już nie żyją
  • powiadamia o twoich działaniach w ich wątku interfejsu użytkownika
  • używa prostego, ale solidnego modelu obsługi wyjątków
  • obsługuje wiele usług ContentServices w celu agregacji wyników różnych usług internetowych
  • obsługuje wielowątkowość wykonywania żądań
  • jest mocno wpisany!
  • jest open source;)
  • i przetestowane

Szukamy opinii od społeczności.

— Snicolas
źródło
4

Retrofit może być tutaj bardzo pomocny, buduje adapter z bardzo prostej konfiguracji, takiej jak:

Modernizacja zamienia Twój REST API w interfejs Java.

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

Klasa RestAdapter generuje implementację interfejsu GitHubService.

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

GitHubService service = restAdapter.create (GitHubService.class); Każde wywołanie wygenerowanej usługi GitHubService wysyła żądanie HTTP do zdalnego serwera WWW.

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

aby uzyskać więcej informacji, odwiedź oficjalną stronę: http://square.github.io/retrofit/

Uwaga : adapter, RestAdapterktóry otrzymujesz z Retrofit, nie jest pochodną tego BaseAdapter, powinieneś utworzyć dla niego opakowanie w taki sposób, jak to pytanie SO Dlaczego mój ListView jest pusty po wywołaniu setListAdapter wewnątrz ListFragment?

— MhdSyrwan
źródło
Czy możesz opublikować pełny przykład dzwonienia do usługi odpoczynku, takiej jak api.icndb.com/jokes/random
— exequielc
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.