È una cosa negativa creare viste a livello di programmazione?

Question

Quindi sono nuovo nello sviluppo di iOS e ho trovato più semplice scrivere le viste a livello di programmazione. Quindi le mie opinioni hanno UIViews, ScrollViews, UIButton, UILabel tutti creati e posizionati in modo programmatico. (Quindi non ho mai usato AutoLayouts).

Ora ho praticamente finito la mia app e voglio fare le viste iPad, e ho realizzato che forse era una cattiva idea farlo in questo modo.

Questa cattiva pratica o dovrei davvero utilizzare il layout automatico il più possibile?

Se è giusto farlo come lo sto facendo ora, qual è il modo corretto di aggiungere viste diverse per iOS e iPad? Ho visto questa risposta qui sotto su come trovare il dispositivo, è sufficiente una semplice istruzione if? - iOS: How to determine the current iPhone/device model in Swift?

Answer 1

Questo va bene, se avete abbastanza tempo, pazienza, buone capacità di calcolo e configurazioni di relazioni tra diversi elementi dell'interfaccia utente.

Tuttavia, l'utilizzo di Layout automatico è piuttosto utile e richiede molto tempo rispetto ai calcoli manuali.

Possiamo facilmente creare un'interfaccia dinamica e versatile che risponda in modo appropriato ai cambiamenti nelle dimensioni dello schermo, nell'orientamento del dispositivo e nella localizzazione con il minimo sforzo.

Adopting Auto Layout Read, per l'attuazione del Auto Layout nella vostra applicazione esistente

Answer 2

TL; DR

Dipende

---

Longer versione

Chiaramente una taglia non non va bene per tutti AutoLayout è piuttosto potente sia in Interface Builder che in codice (sia in formato linguaggio visivo, o semplice impostazione dei vincoli), ma a volte sembra che tu sia "sfregando l'orecchio destro con la mano sinistra" - ovvero quando aggiungi viste a livello di programmazione entra in gioco. Ma attenzione a non averlo diverso in ogni controller di visualizzazione: non vuoi introdurre troppa complessità nel tuo progetto, giusto?

Personalmente preferisco utilizzare AutoLayout il più possibile e ogni volta che non riesco più a utilizzarlo, o la StoryBoard View si incasina troppo con milioni di vincoli, provo a separare le viste in contenitori - fai in modo che il container sia ridimensionato da AutoLayout e avere le sottoview gestite dal codice.

Esempio sarebbe un Media Player personalizzato - forse voglio avere due strisce sotto e sopra il video - Potrei avere il video e due strisce estese UIView gestite dal AutoLayout. Ma le sottoview (controlli) nelle strisce stesse sarebbero aggiunte per codice. Mi dà il controllo sul mio codice ma ancora non presenta troppa complessità.

Answer 3

Utilizzo visualizzazioni programmatiche in un'app live ed è fantastico. Un sacco di persone che conosco anche noi.

Ecco un piccolo algoritmo che uso per scegliere tra i due metodi:

• State voi costruendo un'applicazione veloce per un cliente o un hobby?Usa lo storyboard con l'autolayout.
• Stai costruendo un progetto open source che verrà utilizzato da molte persone? Utilizza l'interfaccia utente programmatica
• Stai costruendo un'app a lungo termine? (1+ anno) Utilizza l'interfaccia utente programmatica

È anche più difficile creare un'app che dovrebbe essere ruotata senza ciclo automatico. Perché farlo con il codice richiede molto più lavoro che l'autolayout. La maggior parte delle buone app non usa comunque questa funzionalità, quindi non vedo molti problemi.

Un buon consiglio è di non usare mai le costanti durante la scrittura dell'interfaccia utente programmatica.

Se si sta per creare un pulsante di larghezza pari a 100 px, non digitare 100px in qualsiasi punto del codice. Calcola invece le dimensioni dello schermo e posiziona le viste principali in base alle dimensioni dello schermo. Quindi posizionare le visualizzazioni secondarie o secondarie in base alla posizione delle viste principali. Se lo fai correttamente, avrai un supporto per il layout multidevice più potente di quello automatico.

Ecco una piccola biblioteca che ho scritto, si prega di controllare e giocare con il codice di come metto la vista: https://github.com/goktugyil/CozyLoadingActivity/blob/master/CozyLoadingActivity.swift

Anche qui è un buon articolo mi piace di questo: http://www.toptal.com/ios/ios-user-interfaces-storyboards-vs-nibs-vs-custom-code

Answer 4

Prima di tutto - se vuoi sviluppare per iOS devi imparare l'autolayout. Ci sono già molti dispositivi diversi con different resolutions e forse lo saranno ancora di più in futuro.

Secondario: se si desidera lavorare in modo efficace con IB, è necessario leggere guide/guardare video tutorial e fare pratica. Potrebbe essere difficile iniziare, ma poi ti renderai conto che IB è potente, veloce e spesso il modo migliore per sviluppare la GUI. Spesso, ma non sempre!

vantaggi codice:

1. Facile da copia-incolla e riutilizzare GUI. Potrebbe essere fondamentale se hai diverse visualizzazioni simili o vuoi riutilizzare un vecchio codice.
2. Facile risolvere i conflitti di fusione e controllare i commit.
3. Più semplice per creare stili, ad esempio lo stesso carattere per tutte le etichette a seconda del paese.
4. Più potente (ci sono cose che non potrebbero essere fatte con IB) quindi devi usarlo a volte.

IB vantaggi:

1. Puoi see your GUI during development per diverse risoluzioni/localizzazioni in modo da non dover compilare ed eseguire un progetto su diversi dispositivi/simulatori di controllare è GUI ok o no. Inoltre IB ti mostrerà avvertimenti se dimentichi alcuni vincoli di Autolayout o ci sono conflitti. Risparmia molto tempo se hai una GUI complessa con vincoli di Autolayout non banali.
2. È molto più facile capire qualcun altro codice se è stato sviluppato in IB. Particolarmente importante per la GUI complessa: non è così facile trovare un'etichetta o un pulsante richiesti in poche centinaia di righe di codice.
3. piccolo bonus - se si desidera utilizzare un controllo personalizzato sviluppato tramite codice è possibile rendere IBInspectable e utilizzarlo senza problemi in IB

Proprio per riassumere - se non hai bisogno di benefici IB (ad esempio GUI è abbastanza semplice e non utilizza Autolayout) lo sviluppo di GUI tramite codice potrebbe essere più facile e veloce. Ma nel caso in cui devi supportare diverse risoluzioni e/o hai centinaia di linee di codice GUI in ciascun controller di visualizzazione, ti consiglio vivamente di provare IB.