Ακούω συχνά Προγραμματιστές iOS Ρωτήστε κάποια παραλλαγή της ίδιας βασικής ερώτησης:

Ποιος είναι ο καλύτερος τρόπος για να αναπτύξετε ένα περιβάλλον χρήστη στο iOS: μέσω Storyboard, NIB ή κώδικα;

Οι απαντήσεις σε αυτήν την ερώτηση, ρητά ή σιωπηρά, τείνουν να υποθέτουν ότι υπάρχει μια αμοιβαία αποκλειστική επιλογή, μια που αντιμετωπίζεται συχνά εκ των προτέρων, πριν από την ανάπτυξη.

Είμαι της γνώμης ότι η απάντηση θα έπρεπε να έχει τη μορφή μιας ή περισσοτέρων μετρητής ερωτήσεις.

Ποιο είναι το 'καλύτερο' αυτοκίνητο;

Επιτρέψτε μου να εξηγήσω με ένα παράδειγμα εκτός θέματος. Ας πούμε ότι θέλω να αγοράσω ένα αυτοκίνητο και σας κάνω μια απλή ερώτηση: 'Ποια είναι η καλύτερη επιλογή;'

Μπορείτε πραγματικά να απαντήσετε προτείνοντας ένα μοντέλο, ή ακόμα και ένα μάρκα ; Δεν είναι πιθανό, εκτός αν προτείνετε μια Ferrari. Αντ 'αυτού, πιθανότατα θα απαντούσατε με μερικές άλλες ερωτήσεις, όπως:

• Ποιος είναι ο προϋπολογισμός σας;
• Πόσες θέσεις χρειάζεστε;
• Σας ενδιαφέρει η κατανάλωση καυσίμου;
• Πώς νιώθεις για τα σπορ αυτοκίνητα;

Είναι προφανές ότι δεν υπάρχει κάτι τέτοιο Καλός ή κακό αυτοκίνητο, εκτός αν έχει τοποθετηθεί σε κατάλληλο πλαίσιο - υπάρχει μόνο ένα καλό ή κακό αυτοκίνητο που βασίζεται σε συγκεκριμένες ανάγκες.

Επιστροφή στο iOS UI Design

Ακριβώς όπως με την έρευνα αυτοκινήτου μας, το 'Ποιος είναι ο καλύτερος τρόπος για να αναπτύξετε μια διεπαφή χρήστη iOS' η ερώτηση στερείται πλαισίου. Και εκπληκτικά, η απάντηση δεν χρειάζεται να είναι μια απλή περίπτωση.

Σε γενικές γραμμές, υπάρχουν τρεις τύποι προσεγγίσεων σχεδίασης διεπαφής χρήστη που μπορείτε να ακολουθήσετε, καθεμία με τα πλεονεκτήματα και τα μειονεκτήματά της, τους θαυμαστές και τους μίσους της:

• Πίνακες ιστοριών iOS : Ένα οπτικό εργαλείο για τον καθορισμό πολλαπλών προβολών εφαρμογών και των μεταβάσεων μεταξύ τους.
• NIBs (ή XIBs) : Κάθε αρχείο NIB αντιστοιχεί σε ένα στοιχείο προβολής και μπορεί να σχεδιαστεί στο Interface Builder, καθιστώντας το επίσης οπτικό εργαλείο. Σημειώστε ότι το όνομα 'NIB' προέρχεται από την επέκταση αρχείου (προηγουμένως .nib και τώρα .xib, αν και η παλιά προφορά έχει επιμείνει).
• Προσαρμοσμένος κωδικός : δηλαδή, όχι GUI εργαλεία, αλλά μάλλον, χειρισμός όλων των προσαρμοσμένων θέσεων, κινούμενων σχεδίων κ.λπ. μέσω προγραμματισμού.

Καμία από αυτές τις επιλογές δεν είναι καθολικά καλύτερα από οποιοδήποτε άλλο (παρά ό, τι μπορεί να ακούσετε).

πώς να σπάσετε έναν αριθμό pin πιστωτικής κάρτας

Πίνακες ιστοριών , για παράδειγμα, είναι η τελευταία προσθήκη στο κιτ εργαλείων διεπαφής χρήστη iOS. Μου έχουν πει ότι είναι το μέλλον, ότι θα αντικαταστήσουν NIB και UI προσαρμοσμένου κώδικα. Βλέπω Storyboard σαν ένα χρήσιμο εργαλείο, αλλά όχι τόσο πολύ αντικατάσταση έχω ένα συμπλήρωμα για NIBs και προσαρμοσμένο κώδικα. Τα storyboards είναι η σωστή επιλογή σε ορισμένες, αλλά όχι σε όλες τις περιπτώσεις.

Επιπλέον, γιατί θα πρέπει να παραμείνετε στατικά σε μια μόνο επιλογή όταν μπορείτε να τα χρησιμοποιήσετε όλα (στο ίδιο έργο), επιλέγοντας τον μηχανισμό που ταιριάζει καλύτερα στο συγκεκριμένο πρόβλημα;

Αυτό είναι ένα ερώτημα που μπορεί, κατά τη γνώμη μου, να γενικευτεί σε υψηλότερο επίπεδο και του οποίου η απάντηση κατατάσσεται ιδιαίτερα στη λίστα με τις αρχές ανάπτυξης λογισμικού: Δεν υπάρχει καθολική γλώσσα, πλαίσιο ή τεχνολογία που είναι η καθολική καλύτερη επιλογή για κάθε πρόβλημα ανάπτυξης λογισμικού. Το ίδιο ισχύει και για τη σχεδίαση διεπαφής χρήστη iOS.

Σε αυτό το σεμινάριο ανάπτυξης iOS, θα εξερευνήσουμε καθεμία από αυτές τις μεθόδους και θα παρουσιάσουμε περιπτώσεις χρήσης στις οποίες πρέπει και πρέπει δεν να χρησιμοποιηθούν, καθώς και τρόπους με τους οποίους μπορούν να αναμειχθούν μαζί.

Πίνακες ιστοριών iOS

Ένα κλασικό λάθος για αρχάριους είναι να δημιουργήσει ένα τεράστιο iOS Storyboard σε όλο το έργο. Έκανα κι εγώ αυτό το λάθος όταν άρχισα να δουλεύω με το Storyboards (πιθανώς επειδή είναι μια δελεαστική διαδρομή).

Ένα κλασικό λάθος για αρχάριους είναι να δημιουργήσει ένα τεράστιο Storyboard σε ολόκληρο το έργο. Το Storyboard είναι ένας πίνακας με μια ιστορία να πει. Δεν πρέπει να χρησιμοποιείται για την ανάμειξη άσχετων ιστοριών σε έναν μεγάλο τόμο.

Όπως υποδηλώνει το όνομά του, το Storyboard είναι ένα πίνακας με μια ιστορία για να πει . Δεν πρέπει να χρησιμοποιείται για την ανάμειξη άσχετων ιστοριών σε έναν μεγάλο τόμο. Ένας πίνακας ιστοριών πρέπει να περιέχει ελεγκτές προβολής που σχετίζονται λογικά μεταξύ τους - κάτι που δεν σημαίνει κάθε ελεγκτής προβολής.

ερωτήματα πολυμέσων για όλες τις συσκευές

Για παράδειγμα, είναι λογικό να χρησιμοποιείτε Storyboard όταν χειρίζεστε:

• Ένα σύνολο προβολών για έλεγχο ταυτότητας και εγγραφή.
• Ροή καταχώρησης παραγγελίας πολλαπλών βημάτων.
• Μια ροή που μοιάζει με οδηγό (δηλαδή, φροντιστήριο).
• Ένα σύνολο προβολών κύριας λεπτομέρειας (π.χ. λίστες προφίλ, λεπτομέρειες προφίλ).

Εν τω μεταξύ, οι μεγάλοι πίνακες ιστορίας θα πρέπει να αποφεύγονται, συμπεριλαμβανομένων των μεμονωμένων πλακέτων σε ολόκληρη την εφαρμογή (εκτός εάν η εφαρμογή είναι σχετικά απλή). Πριν πάμε πιο βαθιά, ας δούμε γιατί.

Το Folly of Large iOS Storyboards

Μεγάλα Storyboards, εκτός από το ότι είναι δύσκολο να περιηγηθείτε και να διατηρήσετε, προσθέστε ένα επίπεδο πολυπλοκότητας σε ένα περιβάλλον ομάδας: όταν πολλοί προγραμματιστές εργάζονται ταυτόχρονα στο ίδιο αρχείο storyboard, οι συγκρούσεις ελέγχου πηγής είναι αναπόφευκτες . Και ενώ ένα storyboard εκπροσωπείται εσωτερικά ως αρχείο κειμένου (ένα αρχείο XML, στην πραγματικότητα), η συγχώνευση συνήθως δεν είναι ασήμαντη.

Όταν οι προγραμματιστές βλέπουν τον πηγαίο κώδικα, το αποδίδουν σημασιολογικά. Έτσι, όταν συγχωνεύονται χειροκίνητα, είναι σε θέση να διαβάσουν και να κατανοήσουν και τις δύο πλευρές μιας σύγκρουσης και να ενεργήσουν ανάλογα. Αντίθετα, ένα storyboard είναι ένα αρχείο XML που διαχειρίζεται ο Xcode και η έννοια κάθε γραμμής κώδικα δεν είναι πάντα εύκολο να γίνει κατανοητή.

Ας πάρουμε ένα πολύ απλό παράδειγμα: ας πούμε ότι δύο διαφορετικοί προγραμματιστές αλλάζουν τη θέση του a UILabel (χρησιμοποιώντας autolayout) και ο τελευταίος ωθεί την αλλαγή του, δημιουργώντας μια διένεξη σαν αυτή (παρατηρήστε τα αντικρουόμενα id χαρακτηριστικά):

id

Το alloc από μόνη της δεν παρέχει καμία ένδειξη ως προς την πραγματική της σημασία, επομένως δεν έχετε τίποτα να εργαστείτε. Η μόνη ουσιαστική λύση είναι να επιλέξετε μία από τις δύο πλευρές της σύγκρουσης και να απορρίψετε την άλλη. Θα υπάρξουν παρενέργειες; Ποιός ξέρει? Οχι εσύ.

Για να διευκολυνθούν αυτά τα προβλήματα σχεδιασμού διεπαφής iOS, η χρήση πολλαπλών storyboard στο ίδιο έργο είναι η προτεινόμενη προσέγγιση.

Πότε να χρησιμοποιείτε Storyboard

Τα Storyboards χρησιμοποιούνται καλύτερα με πολλούς διασυνδεόμενους ελεγκτές προβολής, καθώς η βασική τους απλοποίηση είναι η μετάβαση μεταξύ ελεγκτών προβολής. Σε κάποιο βαθμό, μπορούν να θεωρηθούν ως σύνθεση NIB με οπτικές και λειτουργικές ροές μεταξύ ελεγκτών προβολής.

Τα Storyboards χρησιμοποιούνται καλύτερα με πολλούς διασυνδεόμενους ελεγκτές προβολής, καθώς η βασική τους απλοποίηση είναι η μετάβαση μεταξύ ελεγκτών προβολής.

Εκτός από τη διευκόλυνση της ροής πλοήγησης, ένα άλλο ξεχωριστό πλεονέκτημα είναι ότι εξαλείφουν τον κωδικό boilerplate που απαιτείται για την αναδυόμενη, ώθηση, παρουσίαση και απόρριψη ελεγκτών προβολής. Επιπλέον, οι ελεγκτές προβολής κατανέμονται αυτόματα, οπότε δεν χρειάζεται να κάνετε χειροκίνητα init και prepareForSegue:sender.

Τέλος, ενώ οι Storyboards χρησιμοποιούνται καλύτερα για σενάρια που περιλαμβάνουν πολλαπλούς ελεγκτές προβολής, είναι επίσης προστατευτικό να χρησιμοποιείτε Storyboard όταν εργάζεστε με μονόκλινο ελεγκτής προβολής πίνακα για τρεις λόγους:

• Η δυνατότητα σχεδιασμού πρωτοτύπων επιτραπέζιων κυττάρων στη θέση του βοηθά στη διατήρηση των κομματιών μαζί.
• Πολλαπλά πρότυπα κελιών μπορούν να σχεδιαστούν μέσα στον ελεγκτή προβολής γονικού πίνακα.
• Είναι δυνατή η δημιουργία στατικών προβολών πίνακα (μια πολυαναμενόμενη προσθήκη που δυστυχώς διατίθεται μόνο σε Storyboards).

Θα μπορούσε κανείς να υποστηρίξει ότι πολλά πρότυπα κυττάρων μπορούν επίσης να σχεδιαστούν χρησιμοποιώντας NIBs. Στην πραγματικότητα, αυτό είναι απλώς θέμα προτίμησης: ορισμένοι προγραμματιστές προτιμούν να έχουν τα πάντα σε ένα μέρος, ενώ άλλοι δεν ενδιαφέρονται.

Πότε Δεν να χρησιμοποιήσετε iOS Storyboards

Μερικές περιπτώσεις:

• Η προβολή έχει μια περίπλοκη ή δυναμική διάταξη, που εφαρμόζεται καλύτερα με κώδικα.
• Η προβολή έχει ήδη εφαρμοστεί με NIB ή κώδικα.

Σε αυτές τις περιπτώσεις, μπορούμε είτε να αφήσουμε την προβολή εκτός του Storyboard είτε να την ενσωματώσουμε σε ένα χειριστήριο προβολής. Το πρώτο σπάει την οπτική ροή του Storyboard, αλλά δεν έχει αρνητικές λειτουργικές συνέπειες ή επιπτώσεις στην ανάπτυξη. Το τελευταίο διατηρεί αυτήν την οπτική ροή, αλλά απαιτεί πρόσθετες προσπάθειες ανάπτυξης, καθώς η προβολή δεν είναι ενσωματωμένη στον ελεγκτή προβολής: απλώς ενσωματώνεται ως στοιχείο, επομένως ο ελεγκτής προβολής πρέπει να αλληλεπιδρά με την προβολή και όχι να την εφαρμόζει.

Γενικά πλεονεκτήματα και μειονεκτήματα

Τώρα που έχουμε νόημα για το πότε τα Storyboards είναι χρήσιμα στο iOS Σχεδιασμός διεπαφής χρήστη και προτού προχωρήσουμε στα NIB σε αυτό το σεμινάριο, ας δούμε τα γενικά πλεονεκτήματα και τα μειονεκτήματά τους.

Pro: Απόδοση

Διαισθητικά, μπορείτε να υποθέσετε ότι όταν φορτώνεται ένα Storyboard, όλοι οι ελεγκτές προβολής του δημιουργούνται αμέσως. Ευτυχώς, αυτό είναι απλά μια αφαίρεση και δεν ισχύει για την πραγματική εφαρμογή: αντ 'αυτού, δημιουργείται μόνο ο αρχικός ελεγκτής προβολής, εάν υπάρχει. Οι άλλοι ελεγκτές προβολής δημιουργούνται δυναμικά, είτε όταν εκτελείται ένα τμήμα είτε χειροκίνητα από κώδικα.

Pro: Πρωτότυπα

Το Storyboards απλοποιεί το πρωτότυπο και το κοροϊδεύοντας των διεπαφών χρήστη και ροή. Στην πραγματικότητα, μια πλήρης εφαρμογή πρωτότυπου εργασίας με προβολές και πλοήγηση μπορεί εύκολα να εφαρμοστεί χρησιμοποιώντας Storyboards και μόνο μερικές γραμμές κώδικα.

Με: Επαναχρησιμοποίηση

Όταν πρόκειται για μετακίνηση ή αντιγραφή, οι Πίνακες ιστορίας iOS δεν έχουν καλή θέση. Ένα Storyboard πρέπει να μετακινηθεί μαζί με όλους τους εξαρτημένους ελεγκτές προβολής. Με άλλα λόγια, ένας ελεγκτής μεμονωμένης προβολής δεν μπορεί να εξαχθεί ξεχωριστά και να επαναχρησιμοποιηθεί αλλού ως μεμονωμένη ανεξάρτητη οντότητα. εξαρτάται από το υπόλοιπο του Storyboard για να λειτουργήσει.

Με: Ροή δεδομένων

Τα δεδομένα πρέπει συχνά να διαβιβάζονται μεταξύ των ελεγκτών προβολής όταν πραγματοποιείται μετάβαση μιας εφαρμογής. Ωστόσο, η οπτική ροή του Storyboard είναι σπασμένη σε αυτήν την περίπτωση, καθώς δεν υπάρχει κανένα ίχνος αυτού στο Interface Builder. Το Storyboards φροντίζει να χειρίζεται τη ροή μεταξύ ελεγκτών προβολής, αλλά όχι τη ροή δεδομένων. Έτσι, ο ελεγκτής προορισμού πρέπει να διαμορφωθεί με κώδικα, υπερισχύοντας της οπτικής εμπειρίας.

Το Storyboards φροντίζει να χειρίζεται τη ροή μεταξύ ελεγκτών προβολής, αλλά όχι τη ροή δεδομένων.

Σε τέτοιες περιπτώσεις, πρέπει να βασιστούμε σε ένα - (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = [segue identifier]; if ([identifier [email protected] 'segue_name_1']) { MyViewController *vc = (MyViewController *) [segue destinationViewController]; [vc setData:myData]; } else if ([identifier [email protected] 'segue_name_2']) { ... } else if ... } , με έναν σκελετό if / else-if όπως:

TTLoginView

Θεωρώ ότι αυτή η προσέγγιση είναι επιρρεπής σε λάθη και περιττή ρήξη.

NIBs

Τα NIBs είναι ο παλιός (er) τρόπος εκτέλεσης του σχεδιασμού διεπαφής iOS.

Σε αυτήν την περίπτωση, το 'παλιό' δεν σημαίνει 'κακό', 'ξεπερασμένο' ή 'καταργημένο'. Στην πραγματικότητα, είναι σημαντικό να κατανοήσουμε ότι τα iOS Storyboards δεν αποτελούν καθολική αντικατάσταση των NIB. απλώς απλοποιούν την εφαρμογή UI το μερικοί θήκες.

Με τα NIBs, μπορεί να σχεδιαστεί οποιαδήποτε αυθαίρετη προβολή, την οποία ο προγραμματιστής μπορεί στη συνέχεια να επισυνάψει σε έναν ελεγκτή προβολών ανάλογα με τις ανάγκες.

Αν εφαρμόσουμε αντικειμενοστραφή σχεδίαση στα περιβάλλοντα χρήστη μας, τότε είναι λογικό να σπάσουμε την προβολή ενός ελεγκτή προβολής ξεχωριστές ενότητες , το καθένα υλοποιείται ως προβολή με το δικό του αρχείο NIB (ή με πολλαπλές ενότητες ομαδοποιημένες στο ίδιο αρχείο). Το σαφές πλεονέκτημα αυτής της προσέγγισης είναι ότι κάθε στοιχείο είναι πιο εύκολο να αναπτυχθεί, πιο εύκολο στη δοκιμή και πιο εύκολο να εντοπιστεί ο εντοπισμός σφαλμάτων.

Τα NIB μοιράζονται τα προβλήματα σύγκρουσης συγχώνευσης που είδαμε με τους Storyboards, αλλά σε μικρότερο βαθμό, καθώς τα αρχεία NIB λειτουργούν σε μικρότερη κλίμακα.

πώς να επενδύσετε στο elon musk

Πότε να χρησιμοποιείτε NIBs για iOS UI Design

Ένα υποσύνολο όλων των περιπτώσεων χρήσεων θα ήταν:

• Modal προβολές
• Απλές προβολές σύνδεσης και εγγραφής
• Ρυθμίσεις
• Αναδυόμενα παράθυρα
• Επαναχρησιμοποιήσιμα πρότυπα προβολής
• Επαναχρησιμοποιήσιμα πρότυπα κελιών πίνακα

Εν τω μεταξύ…

Πότε Δεν για χρήση NIBs

Θα πρέπει να αποφύγετε τη χρήση NIB για:

• Προβολές με δυναμικό περιεχόμενο, όπου η διάταξη αλλάζει σημαντικά ανάλογα με το περιεχόμενο.
• Οι απόψεις που από τη φύση τους δεν είναι εύκολα σχεδιασμένες στο Interface Builder.
• Δείτε ελεγκτές με περίπλοκες μεταβάσεις που θα μπορούσαν να απλοποιηθούν με το Storyboarding.

Γενικά πλεονεκτήματα και μειονεκτήματα

Γενικότερα, ας δούμε τα πλεονεκτήματα και τα μειονεκτήματα της χρήσης NIBs.

Pro: Επαναχρησιμοποίηση

Τα NIB είναι χρήσιμα όταν μοιράζεται την ίδια διάταξη σε πολλές κατηγορίες.

Ως απλή περίπτωση χρήσης, ένα πρότυπο προβολής που περιέχει ένα όνομα χρήστη και ένα πεδίο κειμένου κωδικού πρόσβασης θα μπορούσε να εφαρμοστεί με το υποθετικό TTSignupView και TTLoginView απόψεις, οι οποίες θα μπορούσαν να προέρχονται από το ίδιο NIB. Το

θα πρέπει να αποκρύψει το πεδίο κωδικού πρόσβασης και και οι δύο θα πρέπει να καθορίσουν τις αντίστοιχες στατικές ετικέτες (όπως 'Εισαγάγετε το όνομα χρήστη σας' έναντι 'Εισαγάγετε τον κωδικό πρόσβασής σας'), αλλά οι ετικέτες θα έχουν την ίδια βασική λειτουργικότητα και παρόμοιες διατάξεις.

Pro & Con: Απόδοση

Τα NIB είναι φορτωμένα με τεμπέλη , ώστε να μην χρησιμοποιούν τη μνήμη μέχρι να το κάνουν. Αν και αυτό μπορεί να είναι ένα πλεονέκτημα, υπάρχει καθυστέρηση στη διαδικασία της τεμπέλης φόρτωσης, καθιστώντας την και κάτι μειονέκτημα.

Προσαρμοσμένος κώδικας iOS (UI μέσω προγραμματισμού)

Οποιος Σχεδιασμός διεπαφής iOS που μπορεί να γίνει με το Storyboards και τα NIB μπορούν επίσης να εφαρμοστούν με ακατέργαστο κώδικα (υπήρχε, φυσικά, μια εποχή, όταν οι προγραμματιστές δεν είχαν την πολυτέλεια ενός τόσο πλούσιου συνόλου εργαλείων).

Αυτό που δεν μπορεί να γίνει με NIB και Storyboards μπορεί πάντα να εφαρμοστεί με κώδικα.

Ίσως το πιο σημαντικό, αυτό που δεν μπορεί να γίνει με NIB και Storyboards μπορεί πάντα να εφαρμοστεί με κώδικα — υπό την προϋπόθεση, φυσικά, ότι είναι τεχνικά εφικτό. Ένας άλλος τρόπος να το δούμε είναι ότι τα NIBs και το Storyboards υλοποιούνται με κώδικα, οπότε η λειτουργικότητά τους θα είναι φυσικά ένα υποσύνολο. Ας πηδήσουμε κατευθείαν στα υπέρ και τα μειονεκτήματα.

Pro: Under the Hood

Το μεγαλύτερο πλεονέκτημα της δημιουργίας διεπαφής χρήστη iOS μέσω προγραμματισμού: εάν ξέρετε πώς να κωδικοποιήσετε μια διεπαφή χρήστη, τότε ξέρετε τι συμβαίνει κάτω από την κουκούλα , ενώ το ίδιο δεν ισχύει απαραίτητα για τα NIB και το Storyboards.

Για να κάνετε μια σύγκριση: μια αριθμομηχανή είναι ένα χρήσιμο εργαλείο. Αλλά δεν είναι κακό να γνωρίζουμε πώς να κάνουμε υπολογισμούς με μη αυτόματο τρόπο.

Αυτό δεν περιορίζεται σε iOS, αλλά σε οποιοδήποτε οπτικό εργαλείο RAD (π.χ. Visual Studio και Delphi, για να αναφέρουμε μόνο μερικά). Τα οπτικά περιβάλλοντα HTML RAD αντιπροσωπεύουν μια τυπική οριακή γραμμή: χρησιμοποιούνται για τη δημιουργία (συχνά κακώς γραμμένου) κώδικα, ισχυριζόμενοι ότι δεν απαιτείται γνώση HTML και ότι όλα μπορούν να γίνουν οπτικά. Ωστόσο, κανένας προγραμματιστής ιστού δεν θα εφάρμοζε μια ιστοσελίδα χωρίς να λερώσει τα χέρια του: γνωρίζουν ότι ο μη αυτόματος χειρισμός του ακατέργαστου HTML και του CSS θα οδηγήσει σε πιο αρθρωτό, πιο αποτελεσματικό κώδικα.

Έτσι, η εξειδίκευση της κωδικοποίησης των διεπαφών χρήστη iOS σάς δίνει περισσότερο έλεγχο και μεγαλύτερη συνειδητοποίηση του πώς ταιριάζουν αυτά τα κομμάτια, γεγονός που αυξάνει το ανώτατο όριο ως προγραμματιστή.

Pro: Όταν ο κώδικας είναι η μόνη επιλογή

Υπάρχουν επίσης περιπτώσεις στις οποίες ο προσαρμοσμένος κώδικας iOS είναι η μόνη επιλογή για το σχεδιασμό διεπαφής χρήστη. Οι δυναμικές διατάξεις, όπου τα στοιχεία προβολής μετακινούνται και η ροή ή η διάταξη προσαρμόζονται σημαντικά με βάση το περιεχόμενο, αποτελούν τυπικά παραδείγματα.

Pro: Συγχώνευση συγκρούσεων

Ενώ τα NIB και Storyboards υπέφεραν σημαντικά από συγκρούσεις συγχώνευσης, ο κώδικας δεν έχει το ίδιο σφάλμα. Όλος ο κώδικας έχει σημασιολογική σημασία, επομένως η επίλυση διενέξεων δεν είναι πιο δύσκολη από το συνηθισμένο.

Με: Πρωτότυπο

Είναι δύσκολο να καταλάβεις πώς θα φαίνεται μια διάταξη μέχρι να την δεις σε δράση. Επιπλέον, δεν μπορείτε να τοποθετήσετε οπτικά τις προβολές και τα στοιχεία ελέγχου, επομένως η μετάφραση των προδιαγραφών διάταξης σε μια απτή προβολή μπορεί να διαρκέσει πολύ περισσότερο, σε σύγκριση με τα NIB και το Storyboards που σας δίνουν μια άμεση προεπισκόπηση του πώς θα αποδώσουν τα πράγματα.

Με: Ανακατασκευή

Ο επαναπροσδιορισμός κώδικα που γράφτηκε πριν από πολύ καιρό ή από κάποιον άλλο γίνεται επίσης πολύ πιο περίπλοκος: όταν τα στοιχεία τοποθετούνται και κινούνται με προσαρμοσμένες μεθόδους και μαγικούς αριθμούς, οι συνεδρίες εντοπισμού σφαλμάτων μπορούν να γίνουν επίπονες.

javascript λάβετε χρονική σήμανση από την ημερομηνία

Pro: Απόδοση

Όσον αφορά την απόδοση, οι Storyboards και οι NIB υπόκεινται σε γενικά έξοδα φόρτωσης και ανάλυσης. και στο τέλος μεταφράζονται έμμεσα σε κώδικα. Περιττό να πούμε, αυτό δεν συμβαίνει με UI κατασκευασμένα από κώδικα.

Pro: Επαναχρησιμοποίηση

Κάθε προβολή που υλοποιείται μέσω προγραμματισμού μπορεί να σχεδιαστεί με επαναχρησιμοποιήσιμο τρόπο. Ας δούμε μερικές περιπτώσεις χρήσης:

• Δύο ή περισσότερες προβολές έχουν κοινή συμπεριφορά, αλλά είναι ελαφρώς διαφορετικές. Μια βασική τάξη και δύο υποκατηγορίες επιλύουν το πρόβλημα κομψά.
• Ένα έργο πρέπει να είναι διχαλωτό, με σκοπό τη δημιουργία μιας ενιαίας βάσης κώδικα, αλλά τη δημιουργία δύο (ή περισσότερων) διαφορετικών εφαρμογών, καθεμία με συγκεκριμένες προσαρμογές.

Η ίδια διαδικασία σχεδίασης διεπαφής χρήστη θα ήταν πολύ πιο περίπλοκη με τα NIB και Storyboards. Τα αρχεία προτύπων δεν επιτρέπουν την κληρονομιά και οι πιθανές λύσεις περιορίζονται στα ακόλουθα:

• Αντιγράψτε τα αρχεία NIB και Storyboard. Μετά από αυτό, έχουν ξεχωριστές ζωές και δεν έχουν σχέση με το αρχικό αρχείο.
• Παράκαμψη της εμφάνισης και της συμπεριφοράς με κώδικα, ο οποίος μπορεί να λειτουργεί σε απλές περιπτώσεις, αλλά μπορεί να οδηγήσει σε σημαντική επιπλοκή σε άλλες. Οι βαριές παρακάμψεις με κώδικα μπορούν επίσης να καταστήσουν το οπτικό σχέδιο άχρηστο και να εξελιχθεί σε μια συνεχή πηγή πονοκεφάλων, π.χ. όταν ένας συγκεκριμένος έλεγχος εμφανίζει έναν τρόπο στο Interface Builder, αλλά φαίνεται εντελώς διαφορετικός όταν εκτελείται η εφαρμογή.

Πότε να χρησιμοποιήσετε τον κωδικό

Είναι συχνά καλή κλήση να χρησιμοποιείτε προσαρμοσμένο κώδικα για τη σχεδίαση διεπαφής χρήστη iOS όταν έχετε:

• Δυναμικές διατάξεις.
• Προβολές με εφέ, όπως στρογγυλεμένες γωνίες, σκιές κ.λπ.
• Κάθε περίπτωση στην οποία η χρήση NIB και Storyboards είναι περίπλοκη ή ανέφικτη.

Πότε Δεν για χρήση κώδικα

Σε γενικές γραμμές, μπορούν να δημιουργηθούν κωδικοί UI πάντα να χρησιμοποιηθούν. Είναι σπάνια μια κακή ιδέα, οπότε θα έβαλα εδώ.

Παρόλο που τα NIBs και Storyboards φέρνουν κάποια πλεονεκτήματα στο τραπέζι, πιστεύω ότι δεν υπάρχει λογικό μειονέκτημα που θα έβαζα σε μια λίστα για να αποθαρρύνω τη χρήση κώδικα (εκτός ίσως από την τεμπελιά).

μάθουν την κωδικοποίηση c++

Ένα έργο, πολλαπλά εργαλεία

Τα Storyboards, τα NIB και ο κωδικός είναι τρία διαφορετικά εργαλεία για τη δημιουργία διεπαφής χρήστη iOS. Είμαστε τυχεροί που τους έχουμε. Οι φανατικοί των διεπαφών χρήστη μέσω προγραμματισμού πιθανότατα δεν θα λάβουν υπόψη τις άλλες δύο επιλογές: ο κώδικας σάς επιτρέπει να κάνετε ό, τι είναι τεχνικά δυνατό, ενώ οι εναλλακτικές έχουν τους περιορισμούς τους. Για τους υπόλοιπους προγραμματιστές εκεί έξω, το μαχαίρι στρατού Xcode παρέχει τρία εργαλεία που μπορούν να χρησιμοποιηθούν ταυτόχρονα, στο ίδιο έργο, αποτελεσματικά.

Πώς ρωτάς; Ωστόσο, σας αρέσει. Ακολουθούν ορισμένες πιθανές προσεγγίσεις:

• Ομαδοποιήστε όλες τις σχετικές οθόνες σε ξεχωριστές ομάδες και εφαρμόστε κάθε ομάδα με το δικό της ξεχωριστό Storyboard.
• Σχεδιάστε μη επαναχρησιμοποιήσιμα κελιά πίνακα στη θέση τους με ένα Storyboard, μέσα στον ελεγκτή προβολής πίνακα.
• Σχεδιάστε επαναχρησιμοποιήσιμα κελιά πίνακα σε NIBs για να ενθαρρύνετε την επαναχρησιμοποίηση και να αποφύγετε την επανάληψη, αλλά φορτώστε αυτά τα NIB μέσω προσαρμοσμένου κώδικα.
• Σχεδιάστε προσαρμοσμένες προβολές, στοιχεία ελέγχου και αντικείμενα ανάμεσα σε αυτά χρησιμοποιώντας NIB.
• Χρησιμοποιήστε κώδικα για εξαιρετικά δυναμικές προβολές και γενικότερα για προβολές που δεν είναι εύκολα εφαρμόσιμες μέσω Storyboards και NIBs, ενώ μεταβατικές προβολές στέγασης σε Storyboard.

Για να κλείσουμε, ας δούμε ένα τελευταίο παράδειγμα που τα συνδέει όλα μαζί.

Μια απλή θήκη χρήσης

Ας πούμε ότι θέλουμε να αναπτύξουμε μια βασική εφαρμογή ανταλλαγής μηνυμάτων με πολλές διαφορετικές προβολές:

• Μια λίστα με φίλους που ακολουθούνται (με ένα επαναχρησιμοποιήσιμο πρότυπο κελιού για να διατηρείται το UI συνεπές σε μελλοντικές λίστες).
• Μια προβολή λεπτομερειών προφίλ, που αποτελείται από ξεχωριστές ενότητες (συμπεριλαμβανομένων πληροφοριών προφίλ, στατιστικών στοιχείων και γραμμής εργαλείων).
• Μια λίστα μηνυμάτων που αποστέλλονται και λαμβάνονται από έναν φίλο.
• Μια νέα φόρμα μηνύματος.
• Μια προβολή cloud tag που εμφανίζει τις διαφορετικές ετικέτες που χρησιμοποιούνται στα μηνύματα χρήστη, με κάθε ετικέτα ανάλογη σε μέγεθος με τον αριθμό των φορών που χρησιμοποιήθηκε.

Επιπλέον, θέλουμε να ρέουν οι προβολές ως εξής:

• Κάνοντας κλικ σε ένα στοιχείο στη λίστα των φίλων που ακολουθείτε εμφανίζονται οι σχετικές λεπτομέρειες του προφίλ του φίλου σας.
• Οι λεπτομέρειες του προφίλ δείχνουν το όνομα του προφίλ, τη διεύθυνση, τα στατιστικά στοιχεία, μια σύντομη λίστα με τα πιο πρόσφατα μηνύματα και μια γραμμή εργαλείων.

Για την εφαρμογή αυτής της εφαρμογής iOS, και τα τρία εργαλεία διεπαφής χρήστη θα είναι χρήσιμα, όπως μπορούμε να χρησιμοποιήσουμε:

• Ένα Storyboard με τέσσερις ελεγκτές προβολής (λίστα, λεπτομέρειες, λίστα μηνυμάτων και νέα φόρμα μηνυμάτων).
• Ένα ξεχωριστό αρχείο NIB για το πρότυπο κελιού λίστας επαναχρησιμοποιήσιμων προφίλ.
• Τρία ξεχωριστά αρχεία NIB για την προβολή λεπτομερειών προφίλ, ένα για καθένα από τα ξεχωριστά τμήματα που το συνθέτουν (λεπτομέρειες προφίλ, στατιστικά στοιχεία, τελευταία τρία μηνύματα), για να επιτρέπεται καλύτερη συντήρηση. Αυτά τα NIB θα δημιουργηθούν ως προβολές και στη συνέχεια θα προστεθούν στον ελεγκτή προβολής.
• Προσαρμοσμένος κωδικός για την προβολή cloud tag. Αυτή η προβολή είναι ένα τυπικό παράδειγμα ενός που δεν μπορεί να σχεδιαστεί στο Interface Builder, ούτε μέσω του StoryBoards ούτε των NIB. Αντ 'αυτού, εφαρμόζεται πλήρως μέσω κώδικα. Προκειμένου να διατηρηθεί η οπτική ροή του Storyboard, επιλέγουμε να προσθέσουμε έναν κενό ελεγκτή προβολής στο Storyboard, να εφαρμόσουμε την προβολή cloud tag ως αυτόνομη προβολή και να προσθέσουμε μέσω προγραμματισμού την προβολή στο χειριστήριο προβολής. Σαφώς, η προβολή θα μπορούσε επίσης να εφαρμοστεί μέσα στον ελεγκτή προβολής και όχι ως αυτόνομη προβολή, αλλά τα διατηρούμε χωριστά για καλύτερη επαναχρησιμοποίηση.

Ένα πραγματικά βασικό μακέτα μπορεί να μοιάζει με:

Με αυτό, έχουμε περιγράψει τη βασική κατασκευή ενός λογικά εξελιγμένη εφαρμογή iOS των οποίων οι βασικές απόψεις συνδέουν τις τρεις βασικές μας προσεγγίσεις Σχεδιασμός διεπαφής χρήστη . Θυμηθείτε: δεν πρέπει να ληφθεί δυαδική απόφαση, καθώς κάθε εργαλείο έχει τα πλεονεκτήματα και τις αδυναμίες του.

Τυλίγοντας

Όπως εξετάζεται σε αυτό το turtorial, το Storyboards προσθέτει μια αξιοσημείωτη απλοποίηση ios Σχεδιασμός διεπαφής χρήστη και οπτική ροή. Εξαλείφουν επίσης τον κωδικό λέβητα. αλλά όλα αυτά έρχονται σε τιμή, με ευελιξία. Τα NIB, εν τω μεταξύ, προσφέρουν περισσότερη ευελιξία εστιάζοντας σε μία μόνο προβολή, αλλά χωρίς οπτική ροή. Η πιο ευέλικτη λύση, φυσικά, είναι ο κώδικας, ο οποίος τείνει να είναι μάλλον εχθρικός και εγγενώς μη οπτικός.

Εάν αυτό το άρθρο σας ενδιέφερε, σας συνιστώ ανεπιφύλακτα να παρακολουθήσετε η μεγάλη συζήτηση από τον Ray Wenderlich, 55 λεπτά που ξοδεύτηκαν καλά για μια συζήτηση για NIB, Storyboards και UIS με κώδικα.

Κλείνοντας, θέλω να τονίσω ένα πράγμα: Αποφύγετε τη χρήση του ακατάλληλου εργαλείου σχεδίασης διεπαφής χρήστη iOS με κάθε κόστος . Εάν μια προβολή δεν μπορεί να σχεδιαστεί με Storyboard ή εάν μπορεί να εφαρμοστεί με NIB ή κώδικα με απλούστερο τρόπο, όχι χρησιμοποιήστε ένα Storyboard. Ομοίως, εάν μια προβολή δεν μπορεί να σχεδιαστεί με χρήση NIB, μην χρησιμοποιείτε NIB. Αυτοί οι κανόνες, αν και απλοί, θα προχωρήσουν πολύ στην εκπαίδευσή σας ως προγραμματιστής.