Share
Het coderen van een iOS-app is hard werken, dus is het logisch dat ontwikkelaars hun best doen om de bochten in te korten en manieren te vinden om hun app zo snel mogelijk online te krijgen. Maar een succesvolle app zal nog lang bestaan - dat betekent jarenlange bugfixing, functie-uitbreidingen en het werken met andere coders.
In dit artikel deel ik drie dingen om tijdens de ontwikkeling van iOS uit de buurt te blijven, zodat je apps eenvoudiger te bouwen en gemakkelijker te onderhouden zijn.
Hoewel variabelen waarschijnlijk veelzijdiger zijn dan constanten, is het toch geen goed idee om variabelen in te stellen als u in plaats daarvan een constante kunt gebruiken. Dus wat is er zo geweldig aan constanten? Een aantal dingen eigenlijk!
Een van de beste dingen over constanten is hun leesbaarheid. Laten we een voorbeeld bekijken: u schrijft een app van het type e-commerce. Misschien wilt u een lokaal btw-tarief van 8,75% toevoegen, maar andere ontwikkelaars weten niet wat dat getal betekent. Laten we een voorbeeld bekijken:
Steven, een ontwikkelaar, komt aan boord van je team en hij is een codeerninja, maar hij woont in een overzees overzees land. In dit land bestaat er geen omzetbelasting (gelukkige Steven), en daarom weet hij er niets van.
Als u een variabele zou gebruiken voor uw btw-tarief, zou hij deze in slechts één regel code kunnen wijzigen en de resultaten hiervan kunnen uw app ernstig schaden. Gewoon het sleutelwoord veranderen van var naar laat zou de compiler hem laten weten dat de waarde niet kan worden veranderd, en hij zou beseffen dat je van plan was om onveranderlijk te zijn.
Een andere manier dat laat is handig als u naar een waarde in uw code verwijst. Als u een app maakt, wilt u misschien een bepaald kleurenschema. In plaats van uw kleuren te kopiëren en plakken waar ze nodig zijn, kunt u een constante gebruiken om naar die specifieke kleur te verwijzen.
Op deze manier, als je de kleur zou veranderen, zou je hem gewoon op één plek moeten veranderen in plaats van elke verwijzing naar de kleur te vinden en deze meerdere keren te veranderen.
Wanneer u een singleton maakt, moet u ook een gedeeld exemplaar van de klasse maken. U doet dit meestal door een a te declareren statisch laat binnenkant van de klasseverklaring. Hierna zou u de constante een naam geven en deze aan een instantie van de klasse toewijzen en deze in uw app gebruiken.
Voeg daar nog aan toe, als je een instantie van een reguliere klas (bijvoorbeeld een instantie) wilt instantiëren (misschien een instantie van) ViewController.swift, u zou een constante creëren en deze aan een instantie van uw gewenste klasse toewijzen, zodat u een referentie krijgt die u gemakkelijk kunt gebruiken in het gehele bestand. Dit is weer een geweldig gebruik van constanten.
Zoals je kunt zien, zijn er veel redenen waarom constanten geweldig zijn. Ze verhogen de codele leesbaarheid, ze zijn handig voor het opslaan van onveranderlijke waarden, en het is duidelijk dat ze niet zo nutteloos zijn als je denkt. Doe jezelf een plezier door de gewoonte te krijgen constanten zoveel mogelijk te gebruiken en ze alleen in variabelen te veranderen als je absoluut hun waarden moet muteren - het zal je een betere programmeur maken.
Optionals zijn een zeer krachtige functie van Swift. Het zijn gewoon typen zoals int en Draad, geannoteerd door een vraagteken na de typeaangifte. Als u een variabele als een optionele string wilt declareren, schrijft u gewoon:
var someVariable: String?
Dit vertelt de compiler dat er een waarde kan zijn of dat er helemaal geen waarde is. Draad? en Draad worden beschouwd als twee verschillende typen.
Denk aan optionals als een geschenkdoos. Zoals ik al zei, kan deze geschenkdoos al dan niet een waarde hebben en als u erachter wilt komen, moet u eerst de optionele uitpakken. Er zijn veel manieren om dit te doen:
Deze handeling (uitgevoerd met een uitroepteken) wordt de Bang Operator genoemd. Gebruik het niet! Het is nooit een goed idee om het uitpakken van uw variabelen af te dwingen. Als de waarde van de optionele waarde die u probeert uit te pakken nul is (niets), crasht uw app en wie wil dat? Hoe dan ook, laten we naar het volgende codeblok kijken:
var someVariable: String? var somethingElse: String = "hallo" func setupApp () self.somethingElse = self.someVariable!
In dit voorbeeld zou de app crashen omdat we nooit een waarde hebben gedefinieerd voor someVariable, en we proberen het toe te wijzen aan een variabele van het type Draad. Dit verslaat het hele doel van optionals, die er zijn om ons te beschermen tegen fouten als deze!
Laten we eens kijken naar enkele van de juiste manieren om met deze situatie om te gaan.
Dit is een van de meest populaire methoden om met optionals om te gaan. In deze methode wijst u eenvoudig een optionele waarde toe aan een constante met behulp van een als uitspraak. Als de optionele kan worden uitgepakt, de compiler wordt de sluiting, en u kunt de constante die is gemaakt gebruiken. Anders val je in een anders verklaring en beweer dat er niets is gebeurd. Laten we hier een voorbeeld van bekijken:
Accentsconagua
var someVariable: String? var somethingElse: String = "hallo" func setupApp () if let theThing = someVariable self.somethingElse = self.someVariable! else print ("error")Met hetzelfde voorbeeld als de vorige keer, maar met optionele binding in plaats daarvan, kunnen we zien dat de compiler in plaats van crashen de else-instructie invoert en een "fout" afdrukt.
Een andere veel voorkomende manier om optionals veilig uit te pakken, is optionele chaining. Dit is een prima manier om nulwaarden schoon te vermijden en in één regel code. Wanneer u deze methode gebruikt en een nulwaarde tegenkomt, wordt die regel code gewoon gestopt om uit te voeren. Hier is een voorbeeld van:
var someClass: SomeClass? = SomeClass () var somethingElse: String? func setupApp () self.somethingElse = someClass? .createString ()
Kort gezegd, als SomeClass is nul, de hele regel zal niet worden uitgevoerd, en de waarde van iets anders zal nul worden. Als er een waarde is, zoals het voorbeeld hierboven, wordt deze aan de variabele toegewezen iets anders. In beide gevallen crasht de app niet.
Deze methode verwerkt optionals met een enkele regel, maar in tegenstelling tot de bovenstaande methode, jij nodig hebben om een standaard of "anders" -geval aan te bieden (in het geval dat het optionele nihil blijkt te zijn). Laten we een voorbeeld bekijken:
var someVariable: String? var somethingElse: String = "hallo" func setupApp () self.somethingElse = someVariable ?? "fout"
Hoewel dit een beetje cryptisch lijkt, betekent het eenvoudig dat als het linkerhandschrift een waarde heeft (met andere woorden, nul is), het zal worden gebruikt. Als het nul is, wordt de standaardinstructie gebruikt, in dit geval een string met een harde codering. Het is vermeldenswaard dat de juiste verklaring moet van een niet-nul en niet-optioneel type zijn (anders zou het doel hiervan worden verslagen).
Een andere veel voorkomende fout is dat u uw code niet zodanig structureert dat deze duurzaam, onderhoudbaar en efficiënt is. Veel mensen proppen al hun code in hun ViewController klassen, en dit kan uw code moeilijk maken om te veranderen en te debuggen.
Hoe cliché dit ook klinkt, dit is echt de basis van hoe je je app programmeert. Laten we zeggen dat je een huis bouwt, je droomhuis. Dit huis is vijf verdiepingen hoog, dus als je geen sterke basis bouwt en de blauwdrukken volgt, zal het waarschijnlijk gewoon omvallen.
De basis van een iOS-app is het ontwerppatroon dat u kiest. Laten we kijken naar twee van de meest gebruikte patronen.
Het Model-View-Controller of MVC-ontwerppatroon scheidt elk deel van uw code in drie delen: het model, het aanzicht en de controller.
Er zijn veel variaties hiervan, zoals MVVM en MVP. Het is de moeite waard om ze te lezen,maar het principe is vergelijkbaar met MVC, dus we zullen ze hier niet behandelen. Dit worden allemaal ontwerppatronen genoemd en ze maken onze code modulair.
Laten we kijken naar een ander ontwerppatroon dat een aanvulling kan zijn op het app-patroon dat u wilt gebruiken.
Een singleton is een enkele instantie van een klasse die te allen tijde in het geheugen aanwezig is. Dus waarom geven we hierom? Nou, laten we zeggen dat je een app bouwt die verbinding maakt met een database. U hebt een plaats nodig om al uw gegevensserviceverbindingen te plaatsen. Dit zou een perfecte plek zijn om singletons te gebruiken. Kijk naar de onderstaande code; het laat je zien hoe je een singleton construeert:
// Declaratieklasse DataService static var shared = DataService () func createUser () // Call-site DataService.shared.createUser ()
Als u deze eenvoudige tips volgt, is uw app gemakkelijker te onderhouden en zijn bugs duidelijker om te vinden voordat uw klanten het doen.
In dit artikel zagen we drie fouten die ontwikkelaars van iOS-apps maken die codering misschien gemakkelijker lijken te maken, maar op de lange termijn eigenlijk veel meer werk kosten.
Vergeet niet dat het bouwen van een app slechts een deel van de uitdaging is - u moet ook fouten oplossen, functies toevoegen en de code delen met andere ontwikkelaars. Door het volgen van best practices zoals het gebruik van constanten, het correct omgaan met optionals en het gebruik van architecturale patronen, wordt uw app eenvoudiger te bouwen en gemakkelijker te onderhouden.
Kijk terwijl je hier bent naar enkele van onze andere berichten over de ontwikkeling van iOS-apps!
