Modello di progettazione Google Rest, Finito ContentProvider e bloccato ora

Question

Quindi, dopo aver visto il video molto conosciuto su questo argomento, ho deciso di utilizzare il modello di progettazione B. Utilizzo di contentprovider con servicehelper.

Fondamentalmente ho il seguente file:

• MyProvider
• MyDatabase
• Mycontract

nell'attività ora posso ottenere il contentresolver e interrogare il fornitore . Tutto funziona alla grande finora.

Ora ho bisogno di sincronizzare il mio contentprovider per recuperare i dati dalla mia API REST. Quindi ho bisogno di implementare un servizio di supporto di servizio e il metodo di riposo. Studiare l'app Google IO mi ha aiutato molto, im principiante con Android, quindi è ancora difficile da capire.

Vedo Google utilizza RemoteHandlers per elaborare i dati esterni, suppongo che siano le classi Processore nel diagramma?

Quello che non capisco è come posso implementare la parte servicehelper + service per ottenere i dati dalla rete.

• Dove posso chiamare l'helper del servizio?
• cosa devono fare esattamente il servizio e l'assistente?
• ci sono dei buoni esempi di questo modello di design esatto?

Ho letto diversi argomenti su questo argomento, tutti suggeriscono metodi diversi. Ho trovato un esempio che dichiara un restprovider e quindi myProvider deve estendere tale provider. Non mi piacciono queste soluzioni e voglio seguire questo modello di progettazione strutturata. Spero che voi ragazzi potete darmi una mano!

Edit: sorgente del progetto è disponibile: https://github.com/samvdb/TracknTrace

Answer 1

Nella mia comprensione del modello è:

• Non mostrare un'attività vuota e caricare il contenuto in background. Quando il caricamento non riesce, non è possibile visualizzare nulla.
• Invece visualizzare i dati memorizzati nel db accessibile tramite un provider di contenuti e un adattatore - questo garantisce che l'utente veda sempre un contenuto
• Sullo sfondo recuperare nuovi dati, una volta che i dati sono sul telefono l'attività viene aggiornata automaticamente tramite l'adattatore

alle vostre domande (ho cambiato l'ordine):

Dove Invito il servizio di aiuto?
Scelgo il pattern A dal discorso di Vigils. In tal caso la chiamata dipende dalla tua applicazione. È possibile attivare l'aggiornamento all'avvio dell'applicazione, quando viene creata l'attività o quando l'utente seleziona un pulsante di aggiornamento. Sceglierei alla creazione di attività.

Hai scelto il modello B. In tal caso è chiaro che il fornitore di contenuti deve attivare l'aggiornamento. Quando? Per ottenere nuovi dati: al momento della creazione o dopo il primo accesso in lettura. Vorrei usare il tempo di creazione. Per creare, aggiornare, eliminare dopo l'azione corrispondente nel fornitore di contenuti.

Esistono buoni esempi di questo modello di progettazione esatto?
Dal mio post allo https://stackoverflow.com/a/8693919/734687: l'unica implementazione di riferimento open source che conosco è disponibile in http://datadroid.foxykeep.com. È una libreria che puoi usare nella tua applicazione. L'architettura è spiegata sotto/presentazione - assicurati di leggerla.

cosa deve fare esattamente l'helper del servizio?
Se si guarda lo slides alla diapositiva 19, si tratta di un singleton che incapsula la chiamata al servizio e gestisce le chiamate asincrone tramite gli ID di richiesta.

cosa deve fare esattamente il servizio?
Il servizio (diapositiva 17 nella presentazione) garantisce solo che l'azione venga eseguita in background.