iOS User Interfaces: Storyboards vs. NIBs vs. aangepaste Code

ik hoor vaak iOS-ontwikkelaars vragen een variant van dezelfde belangrijke vraag:

Wat is de beste manier om een gebruikersinterface in iOS te ontwikkelen: via Storyboards, NIBs of code?

antwoorden op deze vraag, expliciet of impliciet, hebben de neiging om aan te nemen dat er een elkaar uitsluitende keuze moet worden gemaakt, een keuze die vaak vooraf, vóór de ontwikkeling, wordt aangepakt.

ik ben van mening dat het antwoord in plaats daarvan de vorm van een of meer tegenvragen moet aannemen.

Wat is de” beste ” auto?

laat het me uitleggen met een off-topic voorbeeld. Stel dat ik een auto wil kopen en ik stel je een simpele vraag: “Wat is de beste keuze?”

kunt u werkelijk antwoorden door een model of zelfs een merk voor te stellen? Niet waarschijnlijk, tenzij je een Ferrari voorstelt. In plaats daarvan zou je waarschijnlijk antwoorden met een paar andere vragen, zoals:

• Wat is je budget?
• hoeveel zitplaatsen heeft u nodig?
• geeft u om brandstofverbruik?
• wat vindt u van sportwagens?

het is duidelijk dat er niet zoiets bestaat als een goede of slechte auto tenzij deze in een juiste context wordt geplaatst—er is gewoon een goede of slechte auto gebaseerd op specifieke behoeften.

terug naar iOS UI Design

net als bij ons Auto-onderzoek ontbreekt de vraag “Wat is de beste manier om een iOS UI te ontwikkelen” aan context. En verrassend genoeg hoeft het antwoord geen catch-all zaak te zijn.

in grote lijnen zijn er drie soorten benaderingen voor het ontwerpen van gebruikersinterfaces, elk met zijn voor-en nadelen, zijn fans en haters:

• iOS Storyboards: een visueel hulpmiddel voor het opmaken van meerdere toepassingsweergaven en de overgangen tussen deze.
• NIBs( of XIBs): elk NIB-bestand komt overeen met een enkel weergaveelement en kan worden opgemaakt in de Interface Builder, waardoor het ook een visueel hulpmiddel is. Merk op dat de naam “NIB” is afgeleid van de bestandsextensie (voorheen .nib en nu .xib, hoewel de oude uitspraak is blijven bestaan).
• aangepaste Code: geen GUI-tools, maar eerder het verwerken van alle aangepaste positionering, animatie, enz. programmatisch.

geen van deze opties zijn universeel beter dan alle andere (ondanks wat je zou kunnen horen).

Storyboards, bijvoorbeeld, zijn de nieuwste toevoeging aan de iOS UI toolkit. Ik heb gehoord dat ze de toekomst zijn, dat ze NIBs en aangepaste code UI ‘ s zullen vervangen. Ik zie Storyboards als een nuttig hulpmiddel, maar niet zozeer een vervanging als een aanvulling voor NIBs en aangepaste code. Storyboards zijn in sommige, maar niet in alle situaties de juiste keuze.

verder, waarom zou je statisch vasthouden aan een enkele optie als je ze allemaal kunt gebruiken( in hetzelfde project), het kiezen van het mechanisme dat het beste past bij het specifieke probleem bij de hand?

dit is een vraag die naar mijn mening op een hoger niveau kan worden veralgemeend en waarvan het antwoord hoog in mijn lijst van softwareontwikkelingsprincipes staat: er is geen universele taal, raamwerk of technologie die de universele beste keuze is voor elk softwareontwikkelingsprobleem. Hetzelfde geldt voor iOS UI design.

in deze iOS development tutorial gaan we elk van deze methoden verkennen en use cases introduceren waarin ze wel en niet zouden moeten worden gebruikt, evenals manieren waarop ze kunnen worden gemengd.

iOS Storyboards

een klassieke beginnersfout is het maken van een enorm projectbreed iOS Storyboard. Ook ik maakte deze fout toen ik voor het eerst begon te werken met Storyboards (waarschijnlijk omdat het een verleidelijke route is om te nemen).

zoals de naam al aangeeft, is een Storyboard een bord met een verhaal om te vertellen. Het moet niet worden gebruikt om ongerelateerde verhalen te mengen in een groot volume. Een storyboard moet view controllers bevatten die logisch gerelateerd zijn aan elkaar—wat niet betekent dat elke view controller.

het is bijvoorbeeld zinvol om Storyboards te gebruiken bij het verwerken:

• een set weergaven voor authenticatie en registratie.
• a multi-step order entry flow.
• een wizard-achtige (d.w.z., tutorial) stroom.
• een set van weergaven (bijvoorbeeld Profiellijsten, profieldetails).

ondertussen moeten grote Storyboards worden vermeden, inclusief enkele app-brede Storyboards (tenzij de app relatief eenvoudig is). Voordat we dieper gaan, laten we eens kijken waarom.

de dwaasheid van grote iOS Storyboards

Grote Storyboards, anders dan moeilijk te bladeren en te onderhouden, voegen een laag van complexiteit toe aan een teamomgeving: wanneer meerdere ontwikkelaars tegelijkertijd aan hetzelfde storyboardbestand werken, zijn conflicten met Broncontrole onvermijdelijk. En terwijl een storyboard intern wordt weergegeven als een tekstbestand (een XML-bestand, eigenlijk), is samenvoegen meestal niet-triviaal.

wanneer ontwikkelaars broncode bekijken, schrijven ze het semantische betekenis toe. Dus wanneer ze handmatig samenvoegen, zijn ze in staat om beide kanten van een conflict te lezen en te begrijpen en dienovereenkomstig te handelen. Een storyboard, in plaats daarvan, is een XML-bestand beheerd door Xcode, en de Betekenis van elke regel code is niet altijd gemakkelijk te begrijpen.

laten we een heel eenvoudig voorbeeld nemen: stel dat twee verschillende ontwikkelaars de positie van een UILabel wijzigen (met behulp van autolayout), en de laatste pusht zijn verandering, het produceren van een conflict als dit (Let op de conflicterende id attributen):

<layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides><layoutGuides> <viewControllerLayoutGuide type="top"/> <viewControllerLayoutGuide type="bottom"/></layoutGuides>

de id zelf geeft geen enkele indicatie van de werkelijke betekenis, Dus je hebt niets om mee te werken. De enige zinvolle oplossing is om een van de twee kanten van het conflict te kiezen en de andere te verwerpen. Zijn er bijwerkingen? Wie weet? Jij niet.

om deze iOS interface ontwerp problemen te verlichten, is het gebruik van meerdere storyboards in hetzelfde project de aanbevolen aanpak.

wanneer Storyboards

Storyboards worden het best gebruikt met meerdere onderling verbonden weergavecontrollers, omdat hun belangrijkste vereenvoudiging de overgang tussen weergavecontrollers is. Tot op zekere hoogte kunnen ze worden gezien als een samenstelling van NIBs met visuele en functionele stromen tussen beeldcontrollers.

naast het vergemakkelijken van de navigatiestroom, is een ander duidelijk voordeel dat ze de standaardcode elimineren die nodig is om weergavecontrollers te openen, te pushen, te presenteren en te verwijderen. Bovendien worden beeldcontrollers automatisch toegewezen, zodat het niet nodig is om handmatig alloc en initte gebruiken.

tot slot, terwijl Storyboards het beste worden gebruikt voor scenario ‘ s met meerdere weergavecontrollers, is het ook verdedigbaar om een Storyboard te gebruiken bij het werken met een enkele tabelweergavecontroller om drie redenen:

• de capaciteit om de prototypes van de lijstcel op zijn plaats te ontwerpen helpt de stukken samen te houden.
• meerdere celsjablonen kunnen worden ontworpen in de bovenliggende tabelweergavecontroller.
• het is mogelijk om statische tabelweergaven te maken (een langverwachte toevoeging die helaas alleen beschikbaar is in Storyboards).

men zou kunnen stellen dat meerdere celsjablonen ook kunnen worden ontworpen met behulp van NIBs. In werkelijkheid, dit is gewoon een kwestie van voorkeur: sommige ontwikkelaars de voorkeur aan alles op één plaats, terwijl anderen niet schelen.

wanneer iOS-Storyboards niet gebruikt

enkele gevallen:

• de weergave heeft een ingewikkelde of dynamische lay-out, het best geïmplementeerd met code.
• de weergave is al geïmplementeerd met NIBs of code.

in die gevallen kunnen we de weergave buiten het Storyboard laten of insluiten in een weergavecontroller. De voormalige breekt de visuele stroom van het Storyboard, maar heeft geen negatieve functionele of ontwikkelingsimplicaties. De laatste behoudt deze visuele stroom, maar het vereist extra ontwikkelingsinspanningen omdat de weergave niet is geïntegreerd in de weergavecontroller: het is gewoon ingebed als een component, dus de weergavecontroller moet communiceren met de weergave in plaats van het te implementeren.

Algemene voors en tegens

nu we een gevoel hebben voor wanneer Storyboards nuttig zijn in iOS UI design, en voordat we verder gaan met NIBs in deze tutorial, laten we hun algemene voor-en nadelen doornemen.

Pro: Performance

intuïtief kunt u ervan uitgaan dat wanneer een Storyboard wordt geladen, alle beeldcontrollers onmiddellijk worden geïnstalleerd. Gelukkig is dit slechts een abstractie en niet waar van de daadwerkelijke implementatie: in plaats daarvan wordt alleen de initiële view controller, indien aanwezig, gemaakt. De andere weergavecontrollers worden dynamisch geïnstalleerd, hetzij wanneer een segue wordt uitgevoerd of handmatig vanuit code.

Pro: Prototypes

Storyboards vereenvoudigen het maken van prototypes en het bespotten van gebruikersinterfaces en flow. Eigenlijk kan een complete werkende prototype applicatie met uitzicht en navigatie eenvoudig worden geïmplementeerd met behulp van Storyboards en slechts een paar regels code.

Con: herbruikbaarheid

wanneer het gaat om verplaatsen of kopiëren, zijn iOS Storyboards slecht gepositioneerd. Een Storyboard moet samen met al zijn afhankelijke weergavecontrollers worden verplaatst. Met andere woorden, een single view controller kan niet afzonderlijk worden geëxtraheerd en elders opnieuw worden gebruikt als een enkele onafhankelijke entiteit; het is afhankelijk van de rest van het Storyboard om te functioneren.

Con: gegevensstroom

gegevens moeten vaak worden doorgegeven tussen weergavecontrollers wanneer een app overschakelt. Echter, de visuele stroom van het Storyboard is gebroken in dit geval als er geen spoor van dit gebeurt in de Interface Builder. Storyboards zorgen voor het omgaan met de stroom tussen beeldcontrollers, maar niet de stroom van gegevens. Dus, de bestemming controller moet worden geconfigureerd met code, overschrijven van de visuele ervaring.

in dergelijke gevallen moeten we vertrouwen op een prepareForSegue:sender, met een If / else-if skelet zoals dit:

- (void) prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender { NSString *identifier = ; if ("segue_name_1"]) { MyViewController *vc = (MyViewController *) ; ; } else if ("segue_name_2"]) { ... } else if ...}

ik vind deze benadering foutgevoelig en onnodig uitgebreid.

NIBs

NIBs zijn de oude (er) manier om iOS-interfaceontwerp uit te voeren.

in dit geval betekent “oud” niet “slecht”, “verouderd” of “verouderd”. In feite is het belangrijk om te begrijpen dat iOS-Storyboards geen universele vervanging zijn voor NIBs; ze vereenvoudigen alleen de UI-implementatie in sommige gevallen.

met NIBs kan elke willekeurige weergave worden ontworpen, die de ontwikkelaar vervolgens naar behoefte aan een weergavecontroller kan koppelen.

als we objectgeoriënteerd ontwerp toepassen op onze Ui ‘ s, dan is het zinvol om de weergave van een weergavecontroller op te splitsen in afzonderlijke modules, elk geà mplementeerd als een weergave met zijn eigen NIB-bestand (of met meerdere modules gegroepeerd in hetzelfde bestand). Het duidelijke voordeel van deze aanpak is dat elk onderdeel gemakkelijker te ontwikkelen, gemakkelijker te testen en gemakkelijker te debuggen is.

NIBs delen de merge conflict problemen die we zagen met Storyboards, maar in mindere mate, omdat NIB bestanden op kleinere schaal werken.

wanneer NIBs voor iOS UI-ontwerp

een subset van alle gebruiksgevallen zou zijn:

• modale weergaven
• eenvoudige login-en registratieweergaven
• Instellingen
• pop-upvensters
• Herbruikbare sjablonen
• herbruikbare tabelcelsjablonen

ondertussen…

wanneer NIBs

u moet vermijden om nibs voor:

• weergaven met dynamische inhoud, waarbij de lay-out aanzienlijk verandert, afhankelijk van de inhoud.
• weergaven die van nature niet gemakkelijk te ontwerpen zijn in de Interface Builder.
• bekijk controllers met ingewikkelde overgangen die vereenvoudigd kunnen worden met Storyboarding.

Algemene voors en tegens

meer in het algemeen nemen we de voors en tegens van het gebruik van NIBs door.

Pro: herbruikbaarheid

NIBs zijn handig wanneer dezelfde lay-out over meerdere klassen wordt gedeeld.

als eenvoudig gebruik kan een weergavesjabloon met een gebruikersnaam en een tekstveld voor wachtwoorden worden geà mplementeerd met de hypothetische weergaven TTLoginView en TTSignupView, die beide van dezelfde NIB afkomstig kunnen zijn. Het TTLoginView zou het wachtwoord veld moeten verbergen, en beide zouden overeenkomstige statische labels moeten specificeren (zoals ‘Enter your username’ Versus ‘Enter your password’), maar de labels zouden dezelfde basisfunctionaliteit en vergelijkbare lay-outs hebben.

Pro & Con: Performance

NIBs worden lui geladen, dus ze gebruiken geen geheugen totdat ze moeten. Hoewel dit een voordeel kan zijn, is er latentie aan het luie laadproces, waardoor het ook een nadeel is.

iOS Custom Code (Programmatic UIs)

elk iOS-interfaceontwerp dat kan worden gedaan met Storyboards en NIBs kan ook worden geïmplementeerd met raw-code (Er was natuurlijk een tijd dat ontwikkelaars niet de luxe hadden van zo ‘ n rijke set tools).

misschien nog belangrijker, wat niet kan worden gedaan met NIBs en Storyboards kan altijd worden geïmplementeerd met code—op voorwaarde, natuurlijk, dat het technisch haalbaar is. Een andere manier om ernaar te kijken is dat NIBs en Storyboards worden geïmplementeerd met code, dus hun functionaliteit zal natuurlijk een subset zijn. Laten we recht in de voor-en nadelen springen.

Pro: onder de motorkap

het grootste voordeel van het programmatisch maken van een iOS UI: als je weet hoe je een gebruikersinterface codeert, dan weet je wat er onder de motorkap gebeurt, terwijl hetzelfde niet noodzakelijk geldt voor NIBs en Storyboards.

om een vergelijking te maken: een rekenmachine is een nuttig hulpmiddel. Maar het is geen slechte zaak om te weten hoe je berekeningen handmatig uit te voeren.

Dit is niet beperkt tot iOS, maar tot elke visuele RAD-tool (bijvoorbeeld Visual Studio en Delphi, om er maar een paar te noemen). Visuele HTML RAD-omgevingen vertegenwoordigen een typisch borderline geval: ze worden gebruikt om (vaak slecht geschreven) code te genereren, beweren dat er geen HTML-kennis nodig is, en dat alles visueel kan worden gedaan. Maar geen webontwikkelaar zou een webpagina implementeren zonder zijn of haar handen vuil te maken: ze weten dat handmatig omgaan met de ruwe HTML en CSS zal leiden tot meer modulaire, efficiëntere code.

dus, het beheersen van de codering van iOS user interfaces geeft je meer controle over en een groter bewustzijn van hoe deze stukken in elkaar passen, wat je bovengrens als ontwikkelaar verhoogt.

Pro: wanneer Code de enige optie is

zijn er ook gevallen waarin aangepaste iOS-code de enige optie is voor UI-ontwerp. Dynamische lay-outs, waarbij weergaveelementen worden verplaatst en de stroom of lay-out aanzienlijk wordt aangepast op basis van inhoud, zijn typische voorbeelden.

Pro: Merge conflicten

hoewel NIBs en Storyboards aanzienlijk leden aan merge conflicten, heeft code niet dezelfde fout. Alle code heeft een semantische betekenis, Dus conflicten oplossen is niet moeilijker dan normaal.

Con: Prototyping

het is moeilijk om erachter te komen hoe een lay-out eruit zal zien totdat je het in actie ziet. Verder kun je niet visueel positioneren weergaven en besturingselementen, dus het vertalen van lay-out specs in een tastbare weergave kan veel langer duren, in vergelijking met NIBs en Storyboards die u een onmiddellijke preview van hoe dingen zullen maken geven.

Con: Refactoring

Refactoring code die lang geleden of door iemand anders is geschreven, wordt ook veel ingewikkelder: wanneer elementen worden gepositioneerd en geanimeerd met aangepaste methoden en magische getallen, kunnen debugsessies lastig worden.

Pro: Performance

in termen van performance zijn Storyboards en NIBs onderhevig aan de overhead van het laden en ontleden; en uiteindelijk worden ze indirect vertaald in code. Onnodig te zeggen, dit gebeurt niet met code-made UI ‘ s.

Pro: Herbruikbaarheid

elk beeld dat programmatisch wordt geïmplementeerd, kan op een herbruikbare manier worden ontworpen. Laten we een paar use cases bekijken:

• twee of meer standpunten delen een gemeenschappelijk gedrag, maar ze zijn iets anders. Een basisklasse en twee subklassen lossen het probleem elegant op.
• een project moet worden gevorkt, met als doel het creëren van een enkele codebasis, maar het genereren van twee (of meer) verschillende toepassingen, elk met specifieke aanpassingen.

hetzelfde UI-ontwerpproces zou veel ingewikkelder zijn met NIBs en Storyboards. Template bestanden niet overerving toestaan, en de mogelijke oplossingen zijn beperkt tot de volgende:

• dupliceer de penpunt en Storyboard bestanden. Daarna hebben ze aparte levens en geen relatie met het oorspronkelijke bestand.
• overschrijf het uiterlijk en gedrag met code, wat in eenvoudige gevallen kan werken, maar in andere gevallen tot significante complicaties kan leiden. Zware overrides met code kunnen ook visueel ontwerp nutteloos maken en evolueren tot een constante bron van hoofdpijn, bijv., wanneer een bepaalde controle wordt weergegeven een manier in de Interface Builder, maar ziet er heel anders uit wanneer de app wordt uitgevoerd.

wanneer Code

moet worden gebruikt het is vaak een goede aanroep om aangepaste code te gebruiken voor het ontwerp van de iOS-gebruikersinterface wanneer u:

• dynamische lay-outs.
• weergaven met effecten, zoals afgeronde hoeken, schaduwen, enz.
• elk geval waarin het gebruik van NIBs en Storyboards ingewikkeld of onhaalbaar is.

wanneer Code

niet wordt gebruikt, kunnen in het algemeen altijd met code gemaakte UI ‘ s worden gebruikt. Ze zijn zelden een slecht idee, dus ik zou een hier zetten.

hoewel NIBs en Storyboards enkele voordelen aan de tabel brengen, heb ik het gevoel dat er geen redelijk nadeel is dat ik in een lijst zou plaatsen om het gebruik van code te ontmoedigen (behalve misschien luiheid).

Eén Project, meerdere Tools

Storyboards, NIBs en code zijn drie verschillende tools voor het bouwen van iOS-gebruikersinterface. We hebben geluk dat we ze hebben. Fanatici van programmatische UI ‘ s zullen waarschijnlijk geen rekening houden met de andere twee opties: code laat je alles doen wat technisch mogelijk is, terwijl de alternatieven hun beperkingen hebben. Voor de rest van de ontwikkelaars die er zijn, de Xcode leger mes biedt drie tools die kunnen worden gebruikt in een keer, in hetzelfde project, effectief.

Hoe, vraagt u? Zoals je wilt. Hier zijn enkele mogelijke benaderingen:

• groepeer alle gerelateerde schermen in afzonderlijke groepen en implementeer elke groep met een eigen afzonderlijk Storyboard.
• ontwerp niet-herbruikbare tabelcellen op hun plaats met een Storyboard, in de tabelweergavecontroller.
• ontwerp herbruikbare tabelcellen in penpunten om hergebruik aan te moedigen en herhaling te voorkomen, maar laad deze penpunten via aangepaste code.
• ontwerp aangepaste weergaven, besturingselementen en tussen objecten met behulp van NIBs.
• gebruik code voor zeer dynamische weergaven, en meer in het algemeen voor weergaven die niet gemakkelijk te implementeren zijn via Storyboards en NIBs, terwijl het huisvesten van weergaveovergangen in een Storyboard.

om te sluiten, laten we eens kijken naar een laatste voorbeeld dat het allemaal aan elkaar verbindt.

een eenvoudige Use Case

zegt dat we een basic messaging app willen ontwikkelen met verschillende weergaven:

• een lijst met gevolgde vrienden (met een herbruikbare celsjabloon om de gebruikersinterface consistent te houden in toekomstige lijsten).
• een profieldetailweergave, samengesteld in afzonderlijke secties (inclusief profielinformatie, statistieken en een werkbalk).
• een lijst met berichten die zijn verzonden naar en ontvangen van een vriend.
• een nieuw berichtformulier.
• een tagwolkweergave die de verschillende tags weergeeft die in gebruikersberichten worden gebruikt, waarbij elke tag evenredig is in grootte aan het aantal keren dat deze is gebruikt.

bovendien willen we dat de weergaven als volgt verlopen:

• Als u op een item in de lijst met gevolgde vrienden klikt, worden de profielgegevens van de betreffende vriend weergegeven.
• de profielgegevens tonen de profielnaam, het adres, de statistieken, een korte lijst van de meest recente berichten en een werkbalk.

om deze iOS-app te implementeren, zullen alle drie Onze UI-tools van pas komen, omdat we:

• een Storyboard met vier weergavecontrollers (de lijst, details, lijst met berichten en nieuw berichtformulier).
• een afzonderlijk NIB-bestand voor de herbruikbare profiellijst celsjabloon.
• drie afzonderlijke NIB-bestanden voor de weergave van de profieldetails, één voor elk van de afzonderlijke secties die het samenstellen (profieldetails, statistieken, laatste drie berichten), om een betere onderhoudbaarheid mogelijk te maken. Deze NIBs worden geïnstalleerd als weergaven en vervolgens toegevoegd aan de view controller.
• aangepaste code voor de tag cloud view. Deze weergave is een typisch voorbeeld van een die niet kan worden ontworpen in de Interface Builder, noch door StoryBoards noch NIBs. In plaats daarvan, het is volledig geïmplementeerd door middel van code. Om de visuele stroom van het Storyboard te behouden, kiezen we ervoor om een lege weergavecontroller toe te voegen aan het Storyboard, de tag cloud view te implementeren als een standalone weergave en programmatisch de weergave toe te voegen aan de weergavecontroller. Het is duidelijk dat de view ook in de view controller kan worden geïmplementeerd in plaats van als een standalone view, maar we houden ze gescheiden voor beter hergebruik.

een echt basismodel zou eruit kunnen zien:

met dat, we hebben geschetst van de basisconstructie van een redelijk geavanceerde iOS-app waarvan de kern views binden onze drie primaire benaderingen van UI design. Onthoud: er is geen binaire beslissing te nemen, omdat elk gereedschap zijn sterke en zwakke punten heeft.

inpakken

zoals onderzocht in deze turtorial, voegen Storyboards een merkbare vereenvoudiging toe aan iOS UI design en visual flow. Ze elimineren ook boilerplate code; maar dit alles komt op een prijs, betaald in flexibiliteit. NIBs, ondertussen, bieden meer flexibiliteit door zich te concentreren op een enkele weergave, maar zonder visuele flow. De meest flexibele oplossing is natuurlijk code, die nogal onvriendelijk en inherent niet-visueel is.

als dit artikel je intrigeerde, raad ik je ten zeerste aan om het grote debat van Ray Wenderlich te bekijken, 55 minuten goed besteed aan een discussie over NIBs, Storyboards en code-made UI ‘ s.

tot slot wil ik één ding benadrukken: vermijd het gebruik van het onjuiste iOS UI design tool ten koste van alles. Als een weergave niet ontwerpbaar is met een Storyboard, of als het op een eenvoudigere manier kan worden geïmplementeerd met NIBs of code, gebruik dan geen Storyboard. Evenzo, als een weergave is niet ontwerpbaar met behulp van penpunten, gebruik Geen penpunten. Deze regels, hoewel eenvoudig, zal een lange weg te gaan in uw opleiding als ontwikkelaar.