Autore Topic: [How To] Gestione utenti: servizio + DB  (Letto 737 volte)

Offline helldron

  • Utente junior
  • **
  • Post: 68
  • Respect: 0
    • Mostra profilo
[How To] Gestione utenti: servizio + DB
« il: 21 Maggio 2012, 20:03:01 CEST »
0
Ciao a tutti,
nell'era dei social netwoerk e dei servizi condivisi mi chiedevo se un piccolo sviluppatore può gestire una situazione del genere:

- creare un app che permette di registrare degli utenti (meglio farlo su un DB in un Server oppure direttamente sul DB SQLite)?

- SQLite è integrato in Android giusto? Vuol dire che all'apertura e alla chiusura dell'app si distrugge e si ricrea tutta la struttura dati del DB? Come si riuscirebbero a mantenere le informazioni nel tempo (proprio nel caso di un piccolo social network che ha dei profili con uno stato che si evolvono nel tempo)?

- Domanda forse banale ma in termini di performance cosa si va incontro in caso di molte connessioni sul Server? Quindi quali sarebbero delle best practice da usare per gestire le request?

Grazie  :D!!

Offline DarnellNajanReed

  • Utente normale
  • ***
  • Post: 359
  • Respect: +49
    • Google+
    • Mostra profilo
  • Dispositivo Android:
    LG Optimus One, Acer Iconia A500/501, Asus Transformer Prime, Galaxy ACE, Galaxy S Plus, Galaxy S Advance P, Galaxy Tab 2 7.0, Google Nexus 7
  • Play Store ID:
    Luigi Notaro
  • Sistema operativo:
    OS X 10.8.3
Re:[How To] Gestione utenti: servizio + DB
« Risposta #1 il: 21 Maggio 2012, 20:34:30 CEST »
0
1) É praticamente d'obbligo un DB terzo rispetto agli eventuali db locali sui device, che dovrebbero fungere solo come "cache".

2) Il DB viene creato solo la prima volta e distrutto quando si cancellano i dati dell'app dal menu Impostazioni (o equivalenti). Un pò di info sul data storage in Android: http://developer.android.com/guide/topics/data/data-storage.html

3) Se il server va in sovraccarico amen, cade/esplode. Il tutto dipende dal numero di connessioni e dalla frequenza con le quali queste si presentano.
Per lavoro ho sviluppato un servizio di promozioni a countdown dove il picco di richieste arrivava a circa 800/1000 al secondo. Conta che avevamo 4 macchine + frontend per stare tranquilli.

Offline helldron

  • Utente junior
  • **
  • Post: 68
  • Respect: 0
    • Mostra profilo
Re:[How To] Gestione utenti: servizio + DB
« Risposta #2 il: 23 Maggio 2012, 08:26:51 CEST »
0
1) É praticamente d'obbligo un DB terzo rispetto agli eventuali db locali sui device, che dovrebbero fungere solo come "cache".

3) Se il server va in sovraccarico amen, cade/esplode. Il tutto dipende dal numero di connessioni e dalla frequenza con le quali queste si presentano.
Per lavoro ho sviluppato un servizio di promozioni a countdown dove il picco di richieste arrivava a circa 800/1000 al secondo. Conta che avevamo 4 macchine + frontend per stare tranquilli.
Grazie, info utili. Se ti va potresti suggerirmi qualche altra cosa su:

Per il punto 1) intendi che ci dovrebbe essere una replica del DB su device per ospitare un certo numero di dati  temporaneamente?

Per il punto 3) mi sorge automaticamente un'altra domanda. Per operazioni CRUD a livello di utenze sul DB tu useresti chiamate HTTP native, un Web Service SOAP/REST o altro? Diciamo sotto il punto di vista delle performance, al di là della velocità nell'implementarle.

Offline DarnellNajanReed

  • Utente normale
  • ***
  • Post: 359
  • Respect: +49
    • Google+
    • Mostra profilo
  • Dispositivo Android:
    LG Optimus One, Acer Iconia A500/501, Asus Transformer Prime, Galaxy ACE, Galaxy S Plus, Galaxy S Advance P, Galaxy Tab 2 7.0, Google Nexus 7
  • Play Store ID:
    Luigi Notaro
  • Sistema operativo:
    OS X 10.8.3
Re:[How To] Gestione utenti: servizio + DB
« Risposta #3 il: 23 Maggio 2012, 09:02:57 CEST »
0
Per il punto 1)... non è d'obbligo avere i db locali. Però questo ti consente (quando ve ne sia il bisogno) di avere un'app con alcune funzionalità offline. Inoltre una furba gestione della cache ti permette di velocizzare di molto l'app (o almeno: le consente di essere apparentemente più veloce), cosa molto importante per la UX.

Per il punto 3): ho sempre lavorato con strati, PHP o Java.
Questo per svariati motivi, non sempre legati alle performance: ad esempio, creare uno strato che permette l'interfacciarsi col DB mediante - che so - dei servizi REST ti consente di usare quell'interfaccia sempre (app android, web app, back end....) e quindi di non stare lì a scrivere codice per ogni piattaforma che usa il DB. Questo ti permette di centralizzare la gestione del DB, gestione che spalmata su 2/3 client diverrebbe infernale (la query X funziona sull'app Android....ma esplode sulla web app! sarà perchè l'ho implementata diversamente? Cavoli è vero, quella tabella non si chiama più Y e non ho aggiornato la webapp...)
Un altro motivo è che spesso si utilizzano servizi terze parti (tipo quello di Amazon) per hostare il db....e lì sei obbligato ad usare i tools che ti mettono a disposizione, che nel 99% dei casi sono servizi REST/SOAP.