Particolarità: tipi di dato suggeriti per le colonne, non obbligatori accediamo alla shell



Scaricare 445 b.
13.11.2018
Dimensione del file445 b.







Citando http://www.sqlite.org/:

  • Citando http://www.sqlite.org/:

    • «SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine.»
  • Caratteristiche:

    • lavora su un file singolo per ogni db;
    • ha un’impronta contenutissima (completo in Android);
    • supporta la maggior parte dello standard SQL92;
    • molto più veloce per molte operazioni;
    • è supportato nativamente in Android;
  • Particolarità:

    • tipi di dato suggeriti per le colonne, non obbligatori.


accediamo alla shell (dell’emulatore in esecuzione):

  • accediamo alla shell (dell’emulatore in esecuzione):

    • adb shell
  • creiamo un nuovo database (che elimineremo):

    • sqlite3 prova.db
  • creiamo una tabella:

    • create table note(_id integer primary key autoincrement, content text not null);
  • elenchiamo le tabelle e vediamone lo schema:

    • .tables
    • .schema note
  • inseriamo un dato di esempio:

    • insert into note(content) values('una nota di esempio');
  • vediamo lo in HTML (provare anche cvs, tabs, …):

    • .mode html
    • select * from note;
  • dump di tutto il db come istruzioni SQL:

    • .output myDump
    • .dump
    • .output stdout
  • fine sessione:

    • .exit


Il Framework ci offre alcuni strumenti:

  • Il Framework ci offre alcuni strumenti:

    • gestione delle versioni del DB (per gli aggiornamenti);
    • wrapping in Java delle API;
    • astrazione dei cursori;
    • composizione di query e DDL con metodi comodi.
  • Per l’interfaccia utente:

    • adattatori dedicati alla fruizione di dati da DB.
  • Per l’accesso ai dati:

    • la possibilità di realizzare ContentProvider:
      • accedere ai dati da altre applicazioni;
      • offrire un nuovo tipo di content URI;
    • accesso locale nella nostra app (primo esempio).


ORM:

  • ORM:

    • esistono dei progetti a riguardo:
        • http://ormlite.com/  reflection su annotazioni stile JPA
        • http://hadi.sourceforge.net/  come sopra ma più JPA-oso
        • http://greendao-orm.com/  code generation
        • http://code.google.com/p/hiberdroid/  Hibernate per Android
    • più altri framework generici per l’ORM:
        • http://www.avaje.org/
        • http://cayenne.apache.org/
    • ma niente ancora di standard;
    • spesso si tende a fare ORM «a manina».
  • Cosa vedremo noi?

    • Utilizzo «piatto» del DB;
    • ORM «a manina» con uno strumento nostro;
    • hadi come esempio di ORM su Android.


SQLiteOpenHelper:

  • SQLiteOpenHelper:

    • classe da estendere per accedere a un DB;
    • ci offre dei metodi per la «connesione» al DB;
    • invoca i nostri metodi per il mantenimento:
      • onCreate:
        • DB mancante, prima esecuzione, creazione schema;
      • onUpgrade:
        • se cambia la versione vorremmo aggiornare lo schema.
  • Gestore del DB:

    • la nostra app accederà al DB da diverse activity:
      • serve un gestore centralizzato del DB;
    • gestisce l’accesso al DB nascondendo i dettagli;
    • offre le operazioni che ci interessa svolgere sul DB.








Dinamicità nella creazione di query?

  • Dinamicità nella creazione di query?

    • Query dalla struttura dinamica possono esser create:
      • per concatenazione di stringhe:
        • rende difficile la produzione di statement validi se parti diverse dell’app devono «metterci il proprio» (parti differenti);
  • Soluzione alternativa:

    • builder per la query a cui dichiarare ciò che si vuole;
    • aggiunta programmatica di parti di query;
  • Altre soluzioni:

    • framework esterni che offrono criteria-query:
        • http://code.google.com/p/infinitum-framework/
        • http://code.google.com/p/hiberdroid/


A volte una sequenza di più operazioni su un DB deve avere le seguenti caratteristiche:

  • A volte una sequenza di più operazioni su un DB deve avere le seguenti caratteristiche:

      • Atomiche: come fossero eseguite istantaneamente
      • Consistenti: con i vincoli imposti dal DB (relazioni, vincoli)
      • Isolate: se concorrenti non interferiscono
      • Durature: modifiche con successo sono permanenti anche a crash
  • In Android usiamo il seguente pattern:



Come gestire qualcosa di «globale» in una app?

  • Come gestire qualcosa di «globale» in una app?

    • Le attività vanno e vengono, scomodo usare lo stato;
    • i servizi possono sopravvivere indefinitamente…
        • … ma comunicare con essi non è particolarmente agile;
    • attributi statici pubblici (o con getter e laziness) possono aiutare ad affrontare il problema…
        • …ma offrono in realtà un modello «sporco» di lavoro.
  • Il contesto… non è sono l’attività:

    • il concetto di contesto è più ampio di quanto si pensi;
    • l’app possiede un contesto indipendente dalle attività;
    • creiamo la nostra classe applicazione:
      • potremo personalizzarne il ciclo di vita;
      • offriremo il DbManager mantenuto in vita.




Vogliamo gestire un ricettario su Android…

  • Vogliamo gestire un ricettario su Android…

    • schema del (semplice) DB (che estenderemo):


RecipesActivity:

  • RecipesActivity:

    • attività principale, elenca le attività;
  • RecipeDetailsActivity:

    • consultazione ed eventuale editing di una ricetta;
  • IngredientsActivity:

    • gestione degli ingredienti, creazione, modifica.


Consultazione ricette:

  • Consultazione ricette:

    • L’utente può leggere la lista di ricette, accedendo al menu po’ crearne una nuova, o selezionarne una esistente per consultarla (modalità di lettura).
    • L’attività di consultazione mostra i dettagli della ricetta in sola lettura, il menu consente di passare alla modalità di enditing (automatica per ricette nuove).
  • Editing di una ricetta nuova o vecchia:

    • I campi di testo divengono modificabili, il menu mostra voci in più (salvataggio, aggiunta ingrediente).
    • Se non si salva si mantiene una copia temporanea.
    • Dal menu si passa da una modalità all’altra.
  • Editing degli ingredienti:

    • Possono essere creati, eliminati, modificati da una lista tramite un menu contestuale.


Aspetto accattivante della ricetta consultata:

  • Aspetto accattivante della ricetta consultata:

    • campi di testo come su carta con una piega;
    • aspetto normale in modalità di editing
    • vogliamo una sola immagine per tutte e tre i campi.
  • Disegniamo una nine-patch:

    • prepariamo un’immagine png della carta;
    • usiamo draw9patch per definire la patch.
  • Utilizziamo un drawable XML (selector):



Vogliamo rendere le nostre ricette disponibili…

  • Vogliamo rendere le nostre ricette disponibili…

    • …anche ad altre applicazioni (altri processi);
    • tramite cursori direttamente dal DB;
    • mantenendo controllo sui permessi di scrittura;
    • mantenendo indipendenza tra l’applicazione che offre i contenuti e quella che ne usufruisce.
  • Soluzione: implementare un ContentProvider:

    • ogni ricetta viene mappata con un uri «content://…»;
    • devono essere noti (oltre l’uri) i nomi delle colonne:
        • non obbligatoriamente, solo se si intende proiettare;
        • spesso si utilizza una classe contratto contenente le costanti;
    • un ContentResolver permette poi di accedere ai dati:
        • inconsapevolmente rispetto alla sorgente li ha prodotti.






Per verificare il nostro provider dobbiamo:

  • Per verificare il nostro provider dobbiamo:

    • creare una applicazione separata che lo utilizzi;
    • mostriamo (banalmente) in una ListView le ricette.
        • Proviamo assieme a modificare il «client» per sfogliare solamente le ricette «as they are» (senza ingredienti).
        • Proviamo a offrire/mostrare anche gli ingredienti.


Come per le call… anche la nostra app può:

  • Come per le call… anche la nostra app può:

    • registrarsi per un uri custom  recipe:
    • mostrarsi come strumento di consultazione;
    • venire interpellata in maniera trasparente.


Android offre una funzionalità di ricerca:

  • Android offre una funzionalità di ricerca:

    • a volte con un tasto fisico sul dispositivo;
    • noi possiamo offrire sempre un tool di avvio ricerca.
  • Per abilitarlo:

    • lo dichiariamo nel manifest;
    • ne catturiamo la richiesta come intent.


ORM  Object Relational Mapping:

  • ORM  Object Relational Mapping:

    • lavoriamo sempre a oggetti nella nostra app;
    • qualcun altro si preoccupa di fare traduzione tra modello di dati OO e modello di dati relazionale;
    • auto-magicamente i dati divengono persistenti!


Solo un cenno di architettura, per dare l’idea:

  • Solo un cenno di architettura, per dare l’idea:



In Hadi vengono utilizzate le annotazioni:

  • In Hadi vengono utilizzate le annotazioni:

    • porzioni di informazione «annotate» sul codice;
    • proviamo anche in un nostro ORMapper!


Esiste anche il lato oscuro della persistenza:

  • Esiste anche il lato oscuro della persistenza:

    • accesso diretto a file su telefono o SD;
    • utilizzo di SharedPreferences;
    • utilizzo di file classici con java.io.
  • La persistenza non è tutto nella vita:

    • i dati potrebbero provenire da altre fonti:
      • internet e servizi HTTP (RESTful);
      • servizi di localizzazione;
      • sensori di vario tipo.
    • spesso si usano strumenti misti, ad esempio se volessimo aggiungere un’immagine per ricetta salveremmo un URI, mantenendo l’immagine su SD.
  • Considerare i tempi di accesso:

    • quanto fatto dovrebbe venir modificato per lavorare in differita da un thread diverso da quello principale.






©astratto.info 2017
invia messaggio

    Pagina principale