Virgil Dobjanschi REST uygulama modelini uygulayan örnek Android REST İstemcisi projesine ihtiyacınız var

82

Bir android telefonda bir REST İstemcisi oluşturmak istiyorum.

REST sunucusu birkaç kaynağı ortaya çıkarır, örneğin (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

REST sunucusuyla nasıl konuşacağımı ve ihtiyacım olan bilgileri nasıl alacağımı biliyorum (düşünüyorum). Bunun gibi bir API ile bir REST İstemci sınıfı uygulardım

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

Virgil Dobjanschi'nin " Android REST istemci uygulamaları geliştirme " sunumuna atıfta bulunuldu. Aktivitenin bir İş Parçacığında REST talebini ele almanın iyi bir fikir olmadığını öğrendim. Bunun yerine Service API'yi kullanmalıyım .

Bir (Yerel) Hizmete bağlanan bir Singleton ServiceHelper'a sahip olma fikrini seviyorum, ancak Hizmet kavramını doğru anlamadığımdan korkuyorum.

Şimdilik, bir REST arama sonucunu (bir Hizmette eşzamanlı olmayan bir şekilde yapılır) arayan Aktivitesine nasıl rapor edeceğimi anlamıyorum. Ayrıca tüm REST isteklerini (farklı iade türleriyle) karşılayan BİR Servise ihtiyacım olup olmadığını veya her REST isteği için özel bir hizmete ihtiyacım olup olmadığını merak ediyorum.

Muhtemelen başka birçok anlayış sorunum var, bu yüzden benim için en iyi şey, ihtiyaçlarımı karşılayan örnek bir uygulama olacaktır . Benim kullanım durumum olağandışı değil ve umarım orada örnek uygulama vardır.

Lütfen bana haber verir misiniz?

Beni doğru uygulama yönüne yönlendiren diğer öneriler de yararlıdır (Android API-Demo, kullanım durumumla eşleşmiyor).

Şimdiden teşekkürler.

Klaus

DÜZENLEME : SO'da bulunan (bunu yayınladıktan sonra) beni ihtiyacım olan yöne yönlendiren (karmaşık "Dobjanschi kalıbını" en aza indiren) benzer Konular:

java  android  design-patterns  rest 
— FrVaBe
kaynak
1
Claszen, Tüm talepler için tek servis ve her talep için özel hizmetler hakkında herhangi bir fikir aldınız mı? Cevabınız evet ise lütfen paylaşın. Benim durumumdaki senaryo: Uygulamamda kullanılacak çok sayıda REST isteğim [yaklaşık 20] var. Yukarıda bahsedilen Google I / O'daki değerli oturumu izledim. Sorum şu, hangisinin daha iyi bir yaklaşım olduğu. Tüm talepleri tek bir hizmette ele alan tek bir hizmete sahip olmak mı? veya taleplerin her biri için özel bir hizmete sahip olmak? Sırayla ateşlenmesi gereken bazı taleplerim var ve bazıları aynı anda ateşlenebiliyor. Herhangi bir öneri ?
@ user778869 Sonunda her ('üst seviye') REST kaynağı ('şirket', 'müşteri' gibi) için bir IntentService ve ResultReceiver kullandım. Bunun bir tür 'doğal' yapı olduğunu ve iyi çalıştığını buldum. Bazı kod kopyaları üretebilir, ancak hepsi tek bir serviste yapılmışsa, kontrol yapılarının çok yoğun kullanımını engeller.
— FrVaBe
Bu, Android REST istemci uygulamasını öğrenen kişiler için çok yararlı olabilir. Dobjanschi'nin sunumu PDF'ye dönüştürüldü: drive.google.com/file/d/0B2dn_3573C3RdlVpU2JBWXdSb3c/…
— Kay Zed

Yanıtlar:

50

Genel Bakış

Düzenle:

İlgilenen herkes RESTful android'e bir göz atmayı da düşünür, bu size daha iyi bir bakış sağlayabilir.

Dobjanschi Modelini uygulamaya çalışarak edindiğim deneyimden öğrendiğim şey, her şeyin taşa yazılmadığı ve size yalnızca ne yapmanız gerektiğine dair genel bir bakış sunması, uygulamadan uygulamaya değişebileceğidir ancak formül şudur:

Bu fikirleri takip edin + Kendinizinkini ekleyin = Mutlu Android uygulaması

Bazı uygulamalardaki model gereksinimden farklı olabilir, bazıları SyncAdapter için Hesaba ihtiyaç duymayabilir, diğerleri C2DM kullanabilir, bu yakın zamanda çalıştığım birine yardımcı olabilir:

Account ve AccountManager'a sahip bir uygulama oluşturun

Verilerinizi senkronize etmek için SyncAdapter kullanmanıza izin verecektir. Bu , Kendi SyncAdapter'ınızı oluşturun bölümünde tartışılmıştır.

Bir ContentProvider oluşturun (ihtiyaçlarınıza uygunsa)

Bu soyutlama, yalnızca veritabanına erişmenize izin vermez, aynı zamanda REST Arch ile bire bir Eşleme yöntemine sahip olduğu için REST çağrılarını yürütmek için ServiceHelper'a gider.

İçerik Sağlayıcı | REST Yöntemi

sorgu ----------------> GET

ekle ----------------> PUT

güncelleme ----------------> POST

sil ----------------> SİL

ServiceHelper Katmanlama

Bu adam, ContentProvider'dan aktardığınız parametrelerle bir Http (mutlaka protokol değildir, ancak en yaygın olanıdır) REST yöntemini yürüten (a) hizmetleri başlatacaktır. İçerik Sağlayıcıda UriMatcher'dan alınan eşleşme tamsayısını geçtim, böylece hangi REST kaynağına erişeceğimi biliyorum, yani

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 
    }

}

Hizmet

Yürütülür (çoğu zaman IntentService kullanırım) ve yardımcıdan geçirilen parametrelerle RESTMethod'a gider, ne işe yarar? iyi hatırlayın Hizmet, işleri arka planda çalıştırmak için iyidir.

Ayrıca bir BroadCastReceiver uygula, böylece hizmet işi bittiğinde bu Yayını kaydeden Etkinliğimi bildir ve yeniden sorgulama. Bu son adımın Virgill Konferansı'nda olmadığına inanıyorum ama eminim ki iyi bir yol.

RESTMethod sınıfı

Parametreleri alır, WS kaynağı ( http://myservice.com/service/path ) parametreleri ekler, her şeyi hazırlar, aramayı yürütür ve yanıtı kaydeder.

Yetkilendirme belirteci gerekiyorsa AccountManager'dan talep edebilirsiniz. Hizmetin çağrılması kimlik doğrulaması nedeniyle başarısız olursa, yetkilendirme belirtecini geçersiz kılabilir ve yeni bir belirteç almak için yeniden yetkilendirebilirsiniz.

Son olarak RESTMethod, eşleştiriciye dayalı bir işlemci oluşturup yanıtı geçirsem de bana XML veya JSON veriyor.

İşlemci

Yanıtı ayrıştırmak ve yerel olarak eklemekle görevlidir.

Örnek Bir Uygulama? Elbette!

Ayrıca Eli-G'ye baktığınız bir test uygulamasıyla ilgileniyorsanız, en iyi örnek olmayabilir, ancak Service REST yaklaşımını izler, ServiceHelper, Processor, ContentProvider, Loader ve Broadcast ile oluşturulmuştur.

— Necronet
kaynak
Cevabınız için teşekkürler. Sonunda her ('üst düzey') REST kaynağı ('şirket', 'müşteri' gibi) için bir IntentService ve ResultReceiver kullandım. Dobjanschi modeli benim için çok ağırdı.
— FrVaBe
iyi b, IntentService ve ResultReseiver kullanarak, iletişim için ResultReceiver yerine Binder kullanmasına rağmen, muhtemelen Hizmet Odaklı bir model olan ilk açıklama senaryosunu kullanıyorsunuzdur, ancak söylediğim gibi bu iyi yazılmamıştır !.
— Necronet
Bir süre önce soruyu sordum ve bana uyan bir çözüm buldum. Örnek uygulamalara yönelik tüm referansları kontrol etme imkanım olmadı - ancak bu en güncel cevap olduğu için kabul edeceğim. Yine de diğer tüm cevapları da kontrol etmenizi öneririm.
— FrVaBe
Mükemmel öneri, tüm yanıtları işaretleyin, hepsinin çok sayıda iyi kaynağı ve fikri var !! Jeremy gibi Programlama Android kitabı Yoni ile iosched kaynağı.
— Necronet
@ Necronet merhaba, umut vaat eden örnek uygulamanıza az önce rastladım - ancak, onu oluştururken sorun yaşıyorum. Bize ActionBarSherlock'un hangi sürümüne karşı oluşturulması gerektiğini söyler misiniz (en son ABS 4.1 ile çalışmıyor gibi görünüyor)? Ayrıca, gönderinizden Dobjanschi'nin modellerinin hangi modelini (A, B veya C) hedeflediğinizi gerçekten bulamadım (biliyorum, muhtemelen bazı varyasyonlarla sonuçlandınız, ancak sanırım esas olarak şunlardan birine odaklandınız desenler - sanırım desen B?) Teşekkürler!
— vaiomike
17

Android'in programlanması , Virgil'in Google I / O konuşmasındaki 'Seçenek B: ContentProvider API'sini Kullanın' adanmış tam bir bölüme (13. İçerik Sağlayıcıları Keşfetme) sahiptir.

Bu yaklaşımın faydalarını tek gören biz değiliz. Mayıs 2010'daki Google I / O konferansında, Google'dan Virgil Dobjanschi, RESTful web hizmetlerini Android uygulamalarına entegre etmek için içerik sağlayıcıları kullanmaya yönelik aşağıdaki üç modeli özetleyen bir konuşma sundu ...

Bu bölümde, ikinci Finch video örneğimizle ikinci modeli ayrıntılı olarak inceleyeceğiz; bu strateji, uygulamalarınız için bir dizi önemli fayda sağlayacaktır. Bu yaklaşımın ağ işlemlerini Android MVC ile bütünleştirmesindeki zarafet nedeniyle, ona "Ağ MVC" adını verdik.

Programlama Android'in gelecekteki bir sürümü, diğer iki yaklaşımı ele alabilir ve bu Google sunumuyla ilgili daha fazla ayrıntıyı belgeleyebilir. Bu bölümü okumayı bitirdikten sonra, Google'ın konuşmasına bakmanızı öneririz.

Şiddetle tavsiye edilir.

Zigurd Mednieks, Laird Dornin, G. Blake Meike ve Masumi Nakamura tarafından Android Programlama. Telif Hakkı 2011 O'Reilly Media, Inc., 978-1-449-38969-7.

— Jeremy Haberman
kaynak
11

Virgil Dobjanschi tarafından "Android REST istemci uygulamalarının geliştirilmesi", oturum sırasında hiçbir kaynak kodu sunulmadığı veya daha sonra sağlanmadığı için çok fazla tartışmaya yol açtı.

  • Bir referans uygulaması http://datadroid.foxykeep.com altında mevcuttur (Google IO oturumu / Presentation altında belirtilmiştir). Kendi uygulamanızda kullanabileceğiniz bir kitaplıktır.
  • Android Priority Job Queue , Dobjanschi'nin konuşmasından ilham aldı ve bana çok umut verici geliyor.

Daha fazla uygulama biliyorsanız lütfen yorum yapın.

— ChrLipp
kaynak
Bu muhtemelen yararlı bağlantıyı paylaştığınız için teşekkür ederiz (şu anda daha derinlemesine inceleme şansınız yok)
— FrVaBe
Bu bir çözüm gibi görünüyor. Teşekkür ederim !
— Vincent Cantin
7

Bu konuyu ele alan bir kitaplık geliştirdik: RoboSpice .

Kütüphane, Virgil Dobjanschi ve Neil Goodmann tarafından açıklanan "hizmet yaklaşımını" kullanır , ancak aşağıdakileri sağlayan eksiksiz bir hepsi bir arada çözüm sunuyoruz:

  • POJO'ları döndüren eşzamansız (arka planda AndroidService) ağ isteklerini yürütür (ör: REST istekleri)
  • sonuçları önbelleğe alır (Json veya Xml veya düz metin dosyaları veya ikili dosyalar)
  • Hala canlıysa, faaliyetlerinizi (veya başka bir bağlamı) ağ talebinin sonucuyla ilgili olarak bilgilendirir
  • artık hayatta değillerse, faaliyetlerinizi sonucu bildirmez
  • faaliyetlerinizi UI iş parçacığında bildirir
  • basit ama sağlam bir istisna işleme modeli kullanır
  • farklı web hizmetleri sonuçlarını bir araya getirmek için birden fazla ContentServices'ı destekler
  • istek yürütmelerinin çoklu iş parçacığını destekler
  • kesinlikle yazılmış!
  • açık kaynaktır;)
  • ve test edildi

Aslında topluluktan geri bildirim bekliyoruz.

— Snicolas
kaynak
4

Retrofit burada çok yardımcı olabilir, aşağıdaki gibi çok basit bir yapılandırmadan sizin için bir Adaptör oluşturur:

Retrofit, REST API'nizi bir Java arayüzüne dönüştürür.

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

RestAdapter sınıfı, GitHubService arabiriminin bir uygulamasını oluşturur.

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

GitHubService hizmeti = restAdapter.create (GitHubService.class); Oluşturulan GitHubService üzerindeki her çağrı, uzak web sunucusuna bir HTTP isteğinde bulunur.

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

daha fazla bilgi için resmi siteyi ziyaret edin: http://square.github.io/retrofit/

Not : RestAdapterRetrofit'ten aldığınız adaptör sizden türetilmemiştir BaseAdapterbunun için bir şekilde bu SO sorusu gibi bir sarmalayıcı yapmalısınız ListFragment içinde setListAdapter çağrıldıktan sonra ListView neden boş?

— MhdSyrwan
kaynak
— exequielc
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.