Autore Topic: Consiglio su sistema per visualizzazione dati  (Letto 695 volte)

Offline crc_error

  • Utente junior
  • **
  • Post: 85
  • Respect: +8
    • Mostra profilo
  • Dispositivo Android:
    LG-P500
  • Sistema operativo:
    Windows 8, Ubuntu 12
Consiglio su sistema per visualizzazione dati
« il: 13 Gennaio 2014, 11:55:26 CET »
0
Ciao a tutti,
avrei bisogno di una dritta su come implementare il recupero e la visualizzazione dei dati nella app che sto sviluppando.

Attualmente ho un servizio che elabora i dati ricevuti da gps e una fonte json e li memorizza in un db locale (update tabella header e insert tabella dettaglio).

Contemporaneamente i dati (circa 20 variabili di vario tipo) dovrebbero esser visualizzati su diversi fragment (un mapfragment e almeno 3 fragment in un FragmentStatePagerAdapter).

Secondo voi quale è il sistema più performante per visualizzare questi dati?
Soprattutto tenendo conto che non tutti i fragment saranno attivi e attaccati alla activity (per es. il 3° fragment nel FragmentStatePagerAdapter).

Per ora ho pensato a:
- un bundle dei dati in messaggi attraverso la activity?
- un bundle dei dati inviato attraverso un local broadcast e implementato in ogni fragment attivo?
- Loader con "SimpleCursorAdapter.FLAG_REGISTER_CONTENT_OBSERVER" in modo che aggiorni automaticamente non appena vengono aggiornati i dati nel db?

Secondo voi quale è il più performante e quello che consuma meno risorse?

Grazie in anticipo

Offline crc_error

  • Utente junior
  • **
  • Post: 85
  • Respect: +8
    • Mostra profilo
  • Dispositivo Android:
    LG-P500
  • Sistema operativo:
    Windows 8, Ubuntu 12
Re:Consiglio su sistema per visualizzazione dati
« Risposta #1 il: 17 Gennaio 2014, 15:08:46 CET »
0
Nessuno?

Offline clshack

  • Nuovo arrivato
  • *
  • Post: 13
  • Respect: 0
    • Github
    • Mostra profilo
    • ClsHack
  • Dispositivo Android:
    nexus 4
  • Sistema operativo:
    ArchLinux
Re:Consiglio su sistema per visualizzazione dati
« Risposta #2 il: 17 Gennaio 2014, 17:30:00 CET »
0
Secondo me dipende da come implementi il codice.
Un po' di test con gli strumenti che ti fornisce android potranno farti vedere quale soluzione consuma meno ram e risorse.
Io cerco sempre di utilizzare le ultime api disponibili.

Offline crc_error

  • Utente junior
  • **
  • Post: 85
  • Respect: +8
    • Mostra profilo
  • Dispositivo Android:
    LG-P500
  • Sistema operativo:
    Windows 8, Ubuntu 12
Re:Consiglio su sistema per visualizzazione dati
« Risposta #3 il: 17 Gennaio 2014, 23:05:16 CET »
0
Se uso il broadcast devo aggiungere codice al servizio e preparare il bundle da spedire e inserire il ricevitore in ogni fragment.
Inoltre spedendo ogni secondo avrei un piccolo ritardo nella visualizzazione iniziale dei dati.



Se uso i messaggi invece devo sempre preparare il bundle da spedire e inserire i metodi per l'handler nel servizio e nell'attività e le interfacce per la com tra fragment e activity
L'handler già lo userei per collegarmi al servizio e pilotarlo per cui.. ma ho paura di creare troppo "traffico" di messaggi per i fragment e rendere troppo incasinato il codice visto che devo accertarmi anche quali fragment sono attivi ogni volta...


Caricare i dati dal db sulla carta mi sembra la cosa più giusta, visto che non avrei lag sulla presentazione dei dati al caricamento del fragment e inoltre i fragment anche 100 resterebbero completamente indipendenti da servizio e attività.
L'unico dubbio che è che il servizio ogni secondo scrive nel db e così tante query di lettura potrebbero farmi beccare un table lock con conseguenza perdita del dato da salvare..


mmm... :-\








Offline gigias

  • Nuovo arrivato
  • *
  • Post: 10
  • Respect: 0
    • gigias6615
    • @gigias6615
    • Mostra profilo
  • Dispositivo Android:
    Table Nextway E9
  • Sistema operativo:
    Slackware 14.0 x64
Re:Consiglio su sistema per visualizzazione dati
« Risposta #4 il: 22 Gennaio 2014, 00:45:57 CET »
0
Per il lock dal sqlite mi sa che è remota questa possibilità, l'sqlite ha un timeout di default di 5 sec che gli serve a definire quanto tempo deve ritentare la scrittura se trova il lock del db. Puoi passare alla modalità WAL dell'sqlite così dovrebbe essere ancora più remota e il lock vale solo tra 2 scritture, e non tra una lettura e scrittura simultanee.

Inviato dal mio E9 utilizzando Tapatalk