Architettura per app di valutazione e commento

1

Informazioni sull'app: questa è un'app per Android. L'app ha due componenti / due utenti diversi, i marcatori che hanno segnato il gioco e i fan che visualizzano i commenti del gioco.

  1. Scoring User: Un marcatore guarda una partita di baseball dal vivo e mette il segnare dopo ogni lancio / evento del gioco. Questi eventi vengono inviati al server e memorizzati anche localmente nel telefono del segnaposto.
  2. Fans User: i fan che vogliono seguire il gioco possono visualizzare il commento di gioco per pitch / by-pitch del gioco sull'app fan inviata dal server in base agli eventi inviati dall'app scoring.

Ogni partita avrà set di dati associati al gioco. Risolti i dati che non cambieranno durante il gioco, come -:

  1. Nome team
  2. Elenco giocatori
  3. Nome del terreno .. ETC

Ogni partita avrà anche una lista / matrice di eventi. Ogni evento conterrà un numero di informazioni.

  1. Nome pastella
  2. Nome del lanciatore
  3. Corse con punteggio
  4. Se il wicket è stato preso, come è stato preso il wicket. .. ETC

Questi elenchi di eventi generati in ogni gioco sono memorizzati sul server. Per un periodo di tempo questi eventi per partita generano interessanti spunti sul lanciatore. Esempio: come è meglio un lanciatore contro battitori a sinistra, come un battitore ha una media migliore quando la squadra vince, ecc.

Problemi / suggerimenti richiesti:

  1. Il segnapunti potrebbe aver fatto un errore nel segnare un evento e ha bisogno di annullare l'ultimo evento. Quale modello di progettazione utilizzare in Android per supportare questo?
  2. Gli eventi devono essere memorizzati come JSON o POJO sull'app Android? Dopo ogni evento nell'app di valutazione, l'evento deve essere archiviato sul db locale e sul server. I dati vengono inviati al server un JSON e scaricati in un mongoDb.
  3. L'app deve memorizzare i dettagli di ogni evento da visualizzare nell'app dei commenti, anche per generare approfondimenti. L'interfaccia utente dei marcatori mostra anche il battitore attuale, le corse segnate dal battitore attuale, le informazioni del pitcher totale, attuale, ecc. Questo continua a cambiare dopo ogni evento. Tutti questi dati possono essere derivati e aggiornati sull'interfaccia utente in due modi:
    1. L'elenco degli eventi viene aggiornato dopo il nuovo evento e tutti gli altri dati derivabili vengono calcolati di nuovo eseguendo il ciclo degli eventi. Quindi, in caso di annullamento dell'ultimo evento UNDO, il ricalcolo dei valori effettivi verrà ricalcolato. Ciò potrebbe mantenere i dati precisi e meno inclini agli errori, ma deve attraversare una lunga lista ogni volta.
    2. Insieme alla lista degli eventi c'è un'altra struttura dati che contiene valori per altre informazioni da mostrare sull'interfaccia utente. L'elenco degli eventi viene aggiornato dopo il nuovo evento e tutti gli altri dati derivati vengono aggiornati anche sull'altra struttura dati. Ciò potrebbe causare una mancata corrispondenza dei dati poiché i dati sono duplicati, ma non è necessario attraversare la lunga lista di eventi ogni volta.

Ho trascorso qualche tempo sui modelli di design ma non ho potuto prendere una decisione su cosa procedere. Un'opinione / direzione di esperti o una parola da qualcuno che ha fatto qualcosa in linee simili sarebbe molto utile.

    
posta Vikram 18.01.2018 - 20:20
fonte

1 risposta

2

Un'architettura è più di una pila di schemi. È molto più un insieme di principi seguiti in modo coerente che evita che lo sviluppo della pittura diventi un angolo. Lo zelo religioso non è tuo amico qui. È pragmaticamente evitando applicazioni errate.

Hai menzionato l'annullamento che mi fa pensare al Pattern di comando . Lo sfregamento con questo è ogni comando che l'utente può usare deve avere anche un codice di annullamento che annulla qualsiasi cosa abbia fatto il comando.

Tuttavia, menzioni anche che sei disposto a ricalcolare lo stato da zero in un annullamento. Ciò significa che puoi seguire la rotta immutable . Invece di cambiare un evento, basta semplicemente ricalcolare lo stato da tutti gli eventi che non sono stati annullati. Lo sfregio qui è la prestazione. Un annullamento può diventare traumatico. Tuttavia, questo può essere mitigato salvando lo stato precedente per riprodurre su un elenco più breve di eventi. La frequenza di salvataggio dello stato è una variabile di ottimizzazione che utilizzi per adattare il rendimento spazio-tempo .

    
risposta data 18.01.2018 - 22:23
fonte