Vincoli di posizione, dimensione e catene di controlli

Al fine di generare il codice relativo ai vincoli di posizione, vincoli di dimensione e catene di controlli, è stato modificato il file XMLFiles.xpt: il layout radice di tutti i file di layout è stato cambiato da RelativeLayout a ConstraintLayout; successivamente è stata completamente riscritta la regola di traduzione della po- sizione e dimensione dei controlli, basandola sui nuovi elementi del model. Per

In altre parole, un vincolo su centerX si traduce in due constraint, uno su start e l’altro su end; un vincolo su centerY si traduce in constraint su top e bottom. Ad esempio, un PositionConstraint del model che allinea un controllo al centro orizzontale della finestra parent viene tradotto con due vincoli, uno Start-to-Start, l’altro End-to-End, tra il controllo e la finestra, indicata in Android con la key- word parent.

app:layout_constraintStart_toStartOf

app:layout_constraintStart_toEndOf

app:layout_constraintEnd_toStartOf

app:layout_constraintEnd_toEndOf

app:layout_constraintTop_toTopOf

app:layout_constraintTop_toBottomOf

app:layout_constraintBottom_toTopOf

app:layout_constraintBottom_toBottomOf

layoutEdge reference LayoutEdge

= parent_@id/[ID]

withParent=true

referenceElement (withParent=false)

Figura 4.3: Traduzione di PositionConstraint in Android

La traduzione dei vincoli di dimensione invece segue lo schema riportato in fi- gura 4.4: si può notare che, per quanto riguarda i vincoli fissi e la dimensio- ne di default (utilizzata in caso di mancanza di qualsiasi tipo di vincolo su una specifica dimensione), essi sono tradotti utilizzando gli attributi standard android:layout_width e android:layout_height; la traduzione dei vincoli percentuali e di rapporto, invece, sfrutta i vincoli presenti ancora una volta nel ConstrainLayout.

android:layout_width

android:layout_height fixed constraint & default dimension app:layout_constraintWidth_percent app:layout_constraintHeight_percent app:layout_constraintDimensionRatio percent constraint ratio constraint

Figura 4.4: Traduzione di DimensionConstraint in Android

Per quanto riguarda le ControlChain, esse si traducono in un’insieme di coppie di vincoli bidirezionali; ad esempio, una catena orizzontale formata da tre controlli avrà:

• due vincoli, uno End-to-Start tra il secondo controllo e il terzo, l’altro Start-

to-End tra il terzo controllo e il secondo;

• un vincolo End-to-End tra il terzo controllo e la finestra parent.

Oltre a questi vincoli di allineamento, si aggiungono gli attributi che caratterizza- no le catene dei diversi tipi. Si riportano di seguito questi attributi, esemplificati nel caso di catene orizzontali (per quelli delle catene verticali basta sostituire banalmente Horizontal con Vertical e "sinistro" con "superiore"):

• tutte le catene: il primo controllo della catena ne specifica il tipo, attraverso l’attributo app:layout_constraintHorizontal_chainStyle.

• Catene packed: il primo controllo della catena ne specifica il parametro bias, attraverso l’attributo app:layout_constraintHorizontal_bias; ogni controllo inoltre specifica il parametro spacing della catena, attraverso il proprio margine sinistro.

• Catene weighted: ogni controllo specifica il proprio parametro weight, at- traverso l’attributo app:layout_constraintHorizontal_weight e, come per le catene packed, specifica anche il parametro spacing della catena, attraverso il proprio margine sinistro.

Si ricorda infine che, nel caso la posizione di un controllo non sia vincolata su uno specifico asse (niente vincoli di posizione né il controllo fa parte di una catena su quell’asse), ne viene creato automaticamente uno a partire dagli attributi posX (asse orizzontale) o posY (asse verticale).

4.4.3.2 View controller, scene e menù: codice XML

Come anticipato nella sezione 3.4.6 del capitolo riguardante Protocode, si è scelto di dare il seguente significato a view controller e scene:

• i view controller rappresentano le porzioni di interfaccia utilizzabili per comporre una schermata (e riutilizzabili all’interno di diverse schermate); in Android sono quindi tradotti in Fragment.

• Le scene rappresentano le schermate dell’applicazione, ottenute dalla com- posizione dei view controller; in Android sono tradotte in Activity.

Sia Fragment che Activity consistono in file di layout che ne specificano l’aspetto e classi Java che ne implementano il comportamento; tuttavia, anche da questo punto di vista è stata effettuata una divisione funzionale dei due componenti:

• i Fragment conterranno, all’interno del proprio file di layout, tutti gli ele- menti grafici veri e propri dell’interfaccia dell’applicazione (vale a dire i controlli) e ne implementeranno il comportamento nella relativa classe Java;

Di seguito verrà descritta la traduzione di view controller, scene e menù in file di layout XML (che avviene per mezzo di regole presenti nel file XMLFiles.xpt); la traduzione degli stessi nelle relative classi Java verrà spiegata nella sezione suc- cessiva (essa avviene invece tramite regole contenute nel file activities.xpt). L’organizzazione dei file di layout generati è stata definita seguendo le linee gui- da di Android: il layout del menù viene generato in un file a parte nominato app_menu.xml; il layout di ciascun Fragment viene generato in un file chiamato fragment_VC_NAME.xml; per i layout delle Activity invece sono state seguite le seguenti regole:

• le Activity senza menù (generate a partire da scene che non sono raggiunte dal Navigation di un MenuItem) hanno un solo file di layout, nominato activity_SCENE_NAME.xml, che specifica l’aspetto della ActionBar e lascia il resto dello spazio libero per i fragment che saranno inseriti;

• le Activity con menù (generate a partire da scene che sono raggiunte dal Navigation di un MenuItem) hanno due file di layout:

– app_bar_SCENE_NAME.xml: definisce l’aspetto della ActionBar e lascia

il resto dello spazio libero per i fragment;

– activity_SCENE_NAME.xml: ha come layout radice il DrawerLayout,

che serve per visualizzare il menù (inserisce nella ActionBar il pulsante per richiamarlo), e include il precedente file che specifica il contenuto dell’Activity e il file app_menu.xml che specifica l’aspetto del menù. A questo schema generale va inoltre aggiunto che:

• le Activity generate da scene di tipo multiVC hanno un ulteriore file di layout, content_SCENE_NAME.xml, che specifica la posizione e dimensione di ciascun fragment incluso (le Activity generate dagli altri tipi di scene non ne hanno bisogno dal momento che contengono un oggetto ViewPager, inserito nello spazio libero lasciato dal file di layout che specifica la ActionBar, che si occupa di visualizzare un Fragment alla volta);

• le Activity generate da scene che hanno un tipo diverso per smartphone e per tablet avranno alcuni dei file di layout appena descritti duplicati in due versioni, una appunto per telefono e una per tablet: Android permet- te infatti di definire più file di layout con lo stesso nome (quindi utilizzati per la stessa Activity) ma all’interno di cartelle differenti, una per il lay- out da applicare nel caso "generale" e le altre per i layout da applicare su dispositivi con caratteristiche specifiche. Le linee guida di Android defini- scono tablet un dispositivo con larghezza (in dp) maggiore o uguale a 600

dp e per questo motivo MobileCodeGenerator, per applicazioni con alme-

no un’Activity differenziata su smartphone e tablet, genera due cartelle di layout, una generale dal nome layout e l’altra specifica per i tablet, dal nome layout-sw600dp; il nome non è arbitrario ma assegnato secondo una sintassi specifica e significa smaller width uguale a 600 dp, cioè i file di

typeTablet avrà dunque alcuni file di layout duplicati in due versioni e posizionati nelle due directory appena definite; il sistema si occuperà auto- maticamente, a runtime, di scegliere il layout appropriato al dispositivo sul quale l’applicazione è in esecuzione.

La figura 4.5 mostra uno schema riassuntivo dei file di layout generati.

Activity (scene) di tipo singleVC e singleVCTab Senza menù activity_SCENE_NAME.xml(*) (CoordinatorLayout) └─ <ViewPager> Con menù activity_SCENE_NAME.xml (DrawerLayout) └─ app_bar_SCENE_NAME.xml(*) (CoordinatorLayout) └─ <ViewPager>

Activity (scene) di tipo multiVC Senza menù activity_SCENE_NAME.xml(*) (CoordinatorLayout) └─ content_SCENE_NAME.xml (ConstraintLayout) ├─ <fragment ...> ├─ ... └─ <fragment ...> Con menù activity_SCENE_NAME.xml (DrawerLayout) └─ app_bar_SCENE_NAME.xml(*) (CoordinatorLayout) └─ content_SCENE_NAME.xml (ConstraintLayout) ├─ <fragment ...> ├─ ... └─ <fragment ...>

(*) layout duplicati per scene con typeSmartphone ≠ typeTablet Fragment (view controller)

fragment_VC_NAME.xml (ConstraintLayout) Contiene tutti i controlli del view controller, con relativi constraint

{ specifica la ActionBar { visualizza un fragment alla volta

{ specifica la ActionBar { visualizza un fragment alla volta

{ specifica il menù

{ specifica il menù

{ specifica la ActionBar { specifica la ActionBar

Contiene i tag <fragment>, che importano i view controller della scena nella Activity, con relativi constraint

Contiene i tag <fragment>, che importano i view controller della scena nella Activity, con relativi constraint Menù

app_menu.xml (menu) { contiene i MenuItem

Figura 4.5: File di layout di un’Activity per Android generati da MCG 4.0