Problema architettonico per la comunicazione di attività in un'app Android

4

Gestisco un'applicazione Flickr open source Glimmr per Android. C'è attualmente un problema architettonico relativo alla paginazione che sto cercando di risolvere da un po 'e apprezzerei le idee.

Ecco i componenti coinvolti:

  1. Attività - varie sottoclassi di AsyncTask che prelevano le foto da fonti come un photostream degli utenti (LoadPhotoStreamTask), Photoset (LoadPhotoSetTask), ecc.

  2. PhotoGridFragment: un frammento che visualizza le foto recuperate dalle attività in una griglia. Sottoclassi di questo esistono che corrispondono a ciascuna attività, ad es. PhotoStreamGridFragment, PhotoSetGridFragment, ecc. La griglia è impaginata, in modo che quando l'utente scorre fino alla fine delle foto, l'attività viene attivata per andare a recuperare la pagina successiva delle foto.

  3. PhotoViewerActivity - responsabile della visualizzazione di un elenco di foto dalla griglia a schermo intero. Questo viene avviato da PhotoGridFragments con due informazioni, a) l'elenco di foto attualmente nella griglia e b) un indice a cui iniziare la visualizzazione.

Il problema sorge quando l'utente raggiunge la fine dell'elenco da PhotoViewerActivity . Questa attività non ha le informazioni necessarie per avviare l'attività corretta e aggiornare l'elenco di foto che è stato passato.

Voglio capire un modo per farlo mantenendo l'accoppiamento tra PhotoGridFragment e PhotoViewerActivity il più basso possibile. Le persone che hanno familiarità con Android sapranno che poiché abbiamo a che fare con due attività separate, tutte le comunicazioni tra di loro devono avvenire tramite Intenti con dati che devono essere persistenti o serializzati. Afaik PhotoViewerActivity non può richiamare facilmente la griglia e chiedere altre foto.

Le cose sono complicate dal fatto che ogni attività richiede diversi pezzi di stato e informazioni per fare il suo lavoro. per esempio. un LoadPhotosetTask richiede l'id set, LoadPhotoStreamTask richiede un utente specifico ma non si preoccupa degli insiemi, ecc. Quindi non è sufficiente passare il nome dell'attività richiesto per scaricare più foto per l'attività del visualizzatore.

Un'altra soluzione potrebbe essere quella di astrarre le parti comuni di funzionalità da PhotoViewer in una classe astratta e quindi creare visualizzatori di foto specifici per ogni origine, in modo simile al modo in cui disponiamo di PhotoGridFragments specifici per ogni origine. Questo sembra eccessivo, ma è probabilmente la soluzione nella mia mente in questo momento.

Come risolveresti questo?

    
posta brk3 17.03.2014 - 17:47
fonte

1 risposta

0

Hai un modello / businscomponent / servizio che è responsabile della gestione dei dati? per me la tua descrizione sembra come se i tuoi elementi di GUI (attività / frammento) stessero facendo il lavoro.

Il modo usuale sarebbe avere un modello / businscomponent / servizio che gestisce i dati e viene utilizzato da diversi componenti dell'interfaccia grafica.

    
risposta data 22.03.2014 - 01:34
fonte

Leggi altre domande sui tag