Parte 2 - Architettura

Un elemento chiave per la creazione di app multipiattaforma consiste nel creare un'architettura che si presta a un'ottimizzazione della condivisione del codice tra piattaforme. L'adesione ai principi di programmazione orientata agli oggetti seguenti consente di creare un'applicazione ben progettata:

• Incapsulamento : verifica che le classi e persino i livelli architetturali espongono solo un'API minima che esegue le funzioni necessarie e nasconde i dettagli di implementazione. A livello di classe, questo significa che gli oggetti si comportano come "caselle nere" e che l'utilizzo del codice non deve sapere come eseguono le attività. A livello di architettura, significa implementare modelli come facciata che incoraggiano un'API semplificata che orchestra interazioni più complesse per conto del codice in livelli più astratti. Ciò significa che il codice dell'interfaccia utente (ad esempio) deve essere responsabile solo della visualizzazione di schermate e dell'accettazione dell'input dell'utente; e non interagiscono mai direttamente con il database. Analogamente, il codice di accesso ai dati deve solo leggere e scrivere nel database, ma non interagire mai direttamente con pulsanti o etichette.
• Separazione delle responsabilità : assicurarsi che ogni componente (sia a livello di architettura che di classe) abbia uno scopo chiaro e ben definito. Ogni componente deve eseguire solo le attività definite ed esporre tale funzionalità tramite un'API accessibile alle altre classi che devono usarle.
• Polimorfismo : programmazione in un'interfaccia (o classe astratta) che supporta più implementazioni significa che il codice principale può essere scritto e condiviso tra piattaforme, pur continuando a interagire con funzionalità specifiche della piattaforma.

Il risultato naturale è un'applicazione modellata dopo entità reali o astratte con livelli logici separati. La separazione del codice in livelli semplifica la comprensione, il test e la gestione delle applicazioni. È consigliabile che il codice in ogni livello sia fisicamente separato (nelle directory o anche in progetti separati per applicazioni di grandi dimensioni) e separato logicamente (usando spazi dei nomi).

Livelli di applicazione tipici

In questo documento e nei case study si fa riferimento ai sei livelli di applicazione seguenti:

• Livello dati: persistenza di dati non volatili, probabilmente un database SQLite, ma può essere implementato con file XML o qualsiasi altro meccanismo appropriato.
• Livello di accesso ai dati: wrapper intorno al livello dati che fornisce l'accesso crud (Create, Read, Update, Delete) ai dati senza esporre i dettagli di implementazione al chiamante. Ad esempio, il dal può contenere istruzioni SQL per eseguire query o aggiornare i dati, ma il codice di riferimento non deve conoscere questo problema.
• Livello business: (talvolta definito livello di logica di business o BLL) contiene definizioni di entità business (modello) e logica di business. Modello di facciata candidata per le aziende.
• Livello di accesso ai servizi: usato per accedere ai servizi nel cloud: da servizi Web complessi (REST, JSON, WCF) a recupero semplice di dati e immagini da server remoti. Incapsula il comportamento di rete e fornisce un'API semplice da utilizzare dai livelli applicazione e interfaccia utente.
• Livello applicazione: codice in genere specifico della piattaforma (in genere non condiviso tra piattaforme) o codice specifico dell'applicazione (in genere non riutilizzabile). Un buon test che indica se inserire il codice nel livello applicazione rispetto al livello dell'interfaccia utente è (a) per determinare se la classe ha controlli di visualizzazione effettivi o (b) se può essere condivisa tra più schermate o dispositivi (ad esempio, i Telefono e iPad).
• Livello interfaccia utente : il livello rivolto all'utente contiene schermate, widget e controller che li gestiscono.

Un'applicazione potrebbe non contenere necessariamente tutti i livelli, ad esempio il livello di accesso al servizio non esiste in un'applicazione che non accede alle risorse di rete. Un'applicazione molto semplice potrebbe unire il livello dati e il livello di accesso ai dati perché le operazioni sono estremamente di base.

Modelli software per dispositivi mobili comuni

I modelli sono un modo stabilito per acquisire soluzioni ricorrenti ai problemi comuni. Esistono alcuni modelli chiave utili per la creazione di applicazioni per dispositivi mobili gestibili o comprensibili.

• Model, View, ViewModel (MVVM): il modello Model-View-ViewModel è diffuso con i framework che supportano il data binding, ad esempio Xamarin.Forms. È stato diffuso dagli SDK abilitati per XAML come Windows Presentation Foundation (WPF) e Silverlight; dove ViewModel funge da go-between tra i dati (Model) e l'interfaccia utente (View) tramite data binding e comandi.
• Model, View, Controller (MVC): modello comune e spesso frainteso, MVC viene spesso usato durante la compilazione di interfacce utente e fornisce una separazione tra la definizione effettiva di una schermata dell'interfaccia utente (visualizzazione), il motore dietro di esso che gestisce l'interazione (controller) e i dati che lo popolano (modello). Il modello è in realtà un pezzo completamente facoltativo e quindi, il nucleo di comprensione di questo modello si trova nella visualizzazione e nel controller. MVC è un approccio diffuso per le applicazioni iOS.
• Facciata aziendale - Modello AKA Manager, fornisce un punto di ingresso semplificato per il lavoro complesso. Ad esempio, in un'applicazione Rilevamento attività potrebbe essere presente una TaskManager classe con metodi come GetAllTasks() , GetTask(taskID) , SaveTask (task) e così via. La TaskManager classe fornisce una facciata alle operazioni interne di salvataggio/recupero effettivo di oggetti attività.
• Singleton : il modello Singleton fornisce un modo in cui può esistere solo una singola istanza di un oggetto specifico. Ad esempio, quando si usa SQLite nelle applicazioni per dispositivi mobili, si desidera solo un'istanza del database. L'uso del modello Singleton è un modo semplice per garantire questo problema.
• Provider : un modello coniato da Microsoft (probabilmente simile alla strategia o all'inserimento di dipendenze di base) per incoraggiare il riutilizzo del codice tra le applicazioni Silverlight, WPF e WinForms. Il codice condiviso può essere scritto su un'interfaccia o una classe astratta e le implementazioni concrete specifiche della piattaforma vengono scritte e passate quando viene usato il codice.
• Asincrona: non da confondere con la parola chiave Async, il modello asincrono viene usato quando è necessario eseguire il lavoro a esecuzione prolungata senza mantenere l'interfaccia utente o l'elaborazione corrente. Nel suo formato più semplice, il modello asincrono descrive semplicemente che le attività a esecuzione prolungata devono essere attivate in un altro thread (o astrazione di thread simile, ad esempio un'attività) mentre il thread corrente continua a elaborare e ascoltare una risposta dal processo in background e quindi aggiorna l'interfaccia utente quando vengono restituiti dati e o stato.

Ognuno dei modelli verrà esaminato in modo più dettagliato, in quanto il loro uso pratico è illustrato nei case study. Wikipedia contiene descrizioni più dettagliate dei modelli MVVM, MVC, Facciata, Singleton, Strategia e Provider (e dei modelli progettuali in genere).