From 81afa60ca60e8260a6870fbb83820e381c40b388 Mon Sep 17 00:00:00 2001 From: Angelo Cassano Date: Thu, 7 Dec 2023 11:40:55 +0100 Subject: [PATCH] chore: sviluppo mobile - ingegneria del software per lo sviluppo mobile --- docs/it/sviluppo-mobile.md | 35 ++++++++++++++++++++++++++++++++--- 1 file changed, 32 insertions(+), 3 deletions(-) diff --git a/docs/it/sviluppo-mobile.md b/docs/it/sviluppo-mobile.md index 59cebc90..f0b7fde5 100644 --- a/docs/it/sviluppo-mobile.md +++ b/docs/it/sviluppo-mobile.md @@ -126,9 +126,38 @@ Il percorso di formazione e specializzazione di chi sviluppa su mobile è molto Sebbene non sia necessario verticalizzarsi su ognuna di queste competenze, è importante avere almeno un'infarinatura di base delle skill che possono poi essere interpretate da altri stakeholders all'interno del proprio team di sviluppo. Una formazione impostata su conoscenze Pi-Shaped in ambito mobile non può che portar giovamento nell'interazione con gli altri attori quali backend engineers, UI/UX designers, DevOps, eccetera. -## Pattern architetturali e design pattern +## Ingegneria del software per lo sviluppo mobile -TODO +Secondo [Wikipedia](https://it.wikipedia.org/wiki/Ingegneria_del_software), l' ingegneria del software è quella disciplina informatica che si occupa dei processi produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemi software. Si propone una serie di obiettivi legati all'evoluzione dello sviluppo del software (inteso come attività industriale) sia da un punto di vista tecnologico (per es. attraverso la definizione di nuovi linguaggi di programmazione) che metodologico (per esempio il perfezionamento dei modelli di ciclo di vita del software). + +Lo sviluppo mobile prevede di fatto la realizzazione di prodotti software, ed è per questo motivo che sarebbe buona prassi applicare i principi dell'ingegneria del software anche in questo ambito. Ogni linguaggio di programmazione, e quindi ogni SDK, predilige un subset di design pattern e pattern architetturali da utilizzare durante la realizzazione di applicazioni mobile. Elencarli tutti, soprattutto spiegando dettagliatamente il funzionamento e il comportamento di ogni singolo componente, non rientra fra gli obiettivi di questo capitolo. Ci limiteremo a fornire un'infarinatura generale sui principali componenti da utilizzare quando si sceglie di realizzare applicazioni per mobile. + +I pattern architetturali più utilizzati sono: + +- [Model-View-Controller](https://it.wikipedia.org/wiki/Model-view-controller): Il componente centrale del MVC, il modello, cattura il comportamento dell'applicazione in termini di dominio del problema, indipendentemente dall'interfaccia utente (view). Il modello gestisce direttamente i dati, la logica e le regole dell'applicazione. Una vista può essere una qualsiasi rappresentazione in output di informazioni, come un grafico o un diagramma. Sono possibili viste multiple delle stesse informazioni, come ad esempio un grafico a barre per la gestione e la vista tabellare per l'amministrazione. La terza parte, il controller, accetta l'input e lo converte in comandi per il modello e/o la vista. +- [Model-View-Viewmodel](https://it.wikipedia.org/wiki/Model-view-viewmodel): Questo pattern propone un ruolo più attivo della View rispetto a MVC: la View è in grado di reagire agli eventi, eseguire operazioni ed effettuare il binding con i dati. In questo contesto, alcune delle funzionalità del Controller vengono integrate nella View, che si basa su un'estensione del Model: il ViewModel. Il ViewModel è un Model esteso con funzionalità per la manipolazione dei dati e per l'interazione con la View +- Model-View-Presenter: Questo modello rappresenta un’evoluzione dell’MVC e si concentra sulla separazione tra la presentazione dei dati e la logica di business. La differenza principale tra MVC e MVP è la posizione della logica di presentazione. Nell’MVC, il Controller è responsabile della logica di presentazione, mentre nell’MVP è il Presenter ad essere dedicato a questo compito. +- Model-View-Intent (Android): L'architettura MVI è un pattern architetturale particolarmente utilizzato per la progettazione di interfacce utente in applicazioni basate su framework reattivi. Il modello rappresenta lo stato immutabile dell'applicazione, la view si occupa di visualizzare lo stato dell'applicazione e reagire agli input, e l'intent rappresenta le azioni o gli eventi che possono influenzare lo stato dell'applicazione. Il flusso di dati in MVI è unidirezionale: gli Intent vengono emessi dalla vista, elaborati dal modello per aggiornare lo stato e la vista viene quindi aggiornata per riflettere il nuovo stato. +- View-Interactor-Presenter (iOS): Introdotto come un'alternativa al popolare pattern MVC per migliorare la separazione delle responsabilità e rendere il codice più testabile e manutenibile. La View è passiva e si occupa solo di visualizzare i dati e trasmettere gli input dell'utente al Presenter, l'Interactor contiene la logica di business dell'applicazione. Gestisce il recupero e la manipolazione dei dati, rispondendo alle richieste provenienti dal Presenter. L'Interactor può comunicare con il Modello (se presente) per ottenere o aggiornare i dati. Il Presenter Si occupa di presentare i dati dalla logica di business (Interactor) alla Vista. Il Presenter riceve gli input dall'utente attraverso la View, comunica con l'Interactor per ottenere i dati necessari, e infine aggiorna la View con le informazioni pertinenti. Il pattern VIP può includere un quarto componente, il model, più semplice e privo di logica di business. Il flusso di dati nel VIP pattern è principalmente unidirezionale. +- View-Interactor-Presenter-Entity-Router (iOS): E' un'evoluzione del pattern VIP, ed introduce due nuovi elementi, l'Entity e il Router. L'Entity rappresenta gli oggetti di dominio dell'applicazione e può contenere la logica di business e sono trasferite tra l'Interactor e il Repository/DataManager. Il Router gestisce la navigazione tra le schermate dell'applicazione e può essere utilizzato per avviare nuovi moduli VIPER e per gestire la navigazione tra essi. Il pattern VIPER cerca di risolvere alcuni dei problemi di separazione di responsabilità che potrebbero sorgere in altre architetture. La chiara separazione delle componenti facilita la comprensione del codice, rende più semplice l'aggiunta di nuove funzionalità e favorisce la testabilità delle singole unità. + +I design pattern più utilizzati sono: + +- Repository: Incapsula la logica di accesso ai dati, fornendo un'interfaccia comune per recuperare o salvare dati da diverse fonti. +- Builder: Separa la creazione di un oggetto complesso dalla sua rappresentazione, consentendo la creazione di diverse rappresentazioni dell'oggetto con lo stesso processo di realizzazione. +- Observer: Definisce una dipendenza uno a molti tra oggetti in modo che quando uno degli oggetti cambia stato, tutti i componenti sottoscritti vengano notificati e aggiornati automaticamente. +- Dependency Injection: Fornisce un modo per fornire le dipendenze di un oggetto da parte di un'altra parte esterna, spesso attraverso l'iniezione di dipendenze tramite costruttore o metodi. +- Factory: Definisce un'interfaccia per la creazione di un oggetto, ma lascia la scelta della sua classe di implementazione alle sottoclassi, ritardandone l'inizializzazione a runtime. +- Adapter: Converte l'interfaccia di una classe in un'altra interfaccia che un client si aspetta di utilizzare, consentendo a classi incompatibili di lavorare insieme. +- Singleton: Assicura che una classe abbia una sola istanza e fornisce un punto di accesso globale a questa istanza. +- Facade: Fornisce un'interfaccia unificata a un insieme di interfacce in un sottosistema, semplificando così l'uso e la comprensione di quel sottosistema. +- Decorator: Aggiunge dinamicamente nuove responsabilità a un oggetto fornendo una serie di oggetti che racchiudono l'oggetto originale. +- Composite: Consente di trattare oggetti individuali e composizioni di oggetti in modo uniforme, permettendo la creazione di strutture gerarchiche. +- Command: Incapsula una richiesta come un oggetto, consentendo di parametrizzare le richieste e rendendo le operazioni annullabili. +- Strategy: Definisce una famiglia di algoritmi, incapsula ciascuno di essi e li rende intercambiabili. Consente all'algoritmo di variare indipendentemente dai clienti che lo utilizzano. +- State: Permette a un oggetto di modificare il suo comportamento quando il suo stato interno cambia. L'oggetto sembra mutare la sua classe. + +Anche i framework di sviluppo ibrido hanno la possibilità di interfacciarsi con pattern architetturali e design pattern di vario genere. La maggior parte dei framework ibridi di seconda generazione si basano su pattern che ruotano attorno alla definizione di stato. Ad esempio, su React Native i pattern di state management più utilizzati sono rispettivamente Redux, Hooks e MobX, mentre su Flutter troviamo BLoC, ChangeNotifier e Riverpod. ## Design system per mobile @@ -142,7 +171,7 @@ E' importante sempre tenere a mente che ci sono differenze sostanziali fra desig I principali linguaggi di design proprietari che possiamo utilizzare su mobile sono rispettivamente Material Design e Human Interface Guidelines, sebbene per quest'ultimo sarebbe più corretto identificarlo come UI kit che come linguaggio di design. -Material Design è un linguaggio di design sviluppato da Google nel 2014. Esso utilizza layout basati su griglie, animazioni e transizioni responsive, padding, ed effetti grafici come luci e ombre. Il principale obiettivo di Material Design è la definizione di un nuovo linguaggio visivo che combina principi di buon design con novità tecniche e scientifiche. La filosofia dietro al Material Design ha a che fare con componenti semplici disegnate con penna su carta e trasformati poi in elementi digitali. Con il passare degli anni, il Material Design si è evoluto dando alla luce prima il Material Design 2, e successivamente al Material Design 3 altresì noto come Material You. +Material Design è un linguaggio di design sviluppato da Google nel 2014. Esso utilizza layout basati su griglie, animazioni e transizioni responsive, padding, ed effetti grafici come luci e ombre. Il principale obiettivo di Material Design è la definizione di un nuovo linguaggio visivo che combina principi di buon design con novità tecniche e scientifiche. La filosofia dietro al Material Design ha a che fare con componenti semplici disegnate con penna su carta e trasformati poi in elementi digitali. Con il passare degli anni, il Material Design si è evoluto dando alla luce prima il Material Design 2, e successivamente il Material Design 3 altresì noto come Material You. Spostandoci sullo sviluppo mobile per iOS, non abbiamo un vero e proprio design system nonostante Apple abbia ben documentato il proprio processo di definizione delle interfacce grafiche, bensì uno UI kit composto da un insieme di componenti di sistema che ci consentono di disegnare interfacce grafiche interattive e vicine alla filosofia delle applicazioni di sistema di iOS/iPadOS. Fra queste componenti possiamo trovare label, input testuali, bottoni, checkbox e radio button, switch, selettori, liste, card, etc.