Share
Welkom bij deel zes van de Mobiletuts + begin iOS-ontwikkelingsreeks. Deze aflevering behandelt de kernbegrippen van Xcode-foutopsporing. Het bevat een korte hoeveelheid software-foutopsporingstheorie en een oefentoepassing om het gebruik van onderbrekingspunten en de Xcode-foutopsporing aan te tonen. Het artikel wordt afgesloten met enkele algemene tips en praktische tips, evenals een lijst met nuttige bronnen die beschikbaar zijn om verder te leren.
Problemen met het bekijken van bovenstaande media? Toegang tot de volledige, hoogwaardige versie van deze video in het originele MOV-formaat.
In plaats van een nieuwe applicatie speciaal voor deze tutorial te bouwen, heb ik de FortuneCrunch-applicatie gebruikt die we in deel twee van deze serie hebben gemaakt en ik heb een aantal verschillende fouten in de broncode geïntroduceerd. Download BrokenCrunch, de kapotte versie van FortuneCrunch bij dit bericht, om mee te nemen terwijl ik laat zien hoe de Xcode-foutopsporingstools te gebruiken.
Voordat we beginnen met het daadwerkelijk debuggen van BrokenCrunch, laten we het even hebben over de theorie van het debuggen van software. Over het algemeen kunnen softwarefouten (ook wel "bugs" genoemd) als volgt worden ingedeeld:
Zoals de naam al aangeeft, treedt er een fout op tijdens het compileren wanneer u probeert de broncode van uw toepassing te compileren. In Xcode gebeurt dit wanneer u "Build and Run" of "Build and Debug" selecteert om uw toepassing op het apparaat of de simulator te starten. Wanneer een compileerfout wordt aangetroffen, wordt uw toepassing letterlijk niet gestart. Zoals we zullen zien, kunnen fouten in deze categorie voorkomen door onzinnige of onjuiste syntaxisinstructies of door problemen die zich voordoen in de koppelingsfase van uw applicatie-build. Over het algemeen zijn compilatietijdfouten de gemakkelijkste van de drie categorieën om te verhelpen, omdat de compiler meestal een zinvolle foutmelding of waarschuwing geeft die u op de hoogte brengt van de aard van het probleem.
Runtime-fouten treden op nadat uw toepassing is gecompileerd en gestart in de Simulator of op een apparaat. Een toepassingscrash of geheugenlek dat optreedt als gevolg van slecht objectgeheugenbeheer is een voorbeeld van een runtimefout.
Een logische fout treedt op tijdens de runtime-fase van een toepassing en resulteert in onverwacht of ongewenst toepassingsgedrag dat conflicteert met de beoogde uitkomst van de softwareontwikkelaar of projectparticipant. Een goed voorbeeld van een logische fout is een wiskundige formule die verkeerd is geïmplementeerd. Overweeg de stelling van Pythagoras:
Als een softwareontwikkelaar deze formule onbedoeld heeft geïmplementeerd als:
Het resultaat zou een logische fout zijn, maar hoogstwaarschijnlijk zou de toepassing niet crashen. Dat is wat logische fouten zo gevaarlijk maakt: de toepassing kan schijnbaar "bugvrij" zijn voor de ontwikkelaar terwijl deze in feite ongeldige of ongewenste uitvoer produceert.
Met deze theoretische kennis op zijn plek, opent u BrokenCrunch en laten we aan de slag gaan. Nadat u onze voorbeeldtoepassing hebt geladen, selecteert u Bouw> Build and Debug. U zult merken dat de toepassing niet kan worden gestart en dat de compiler een aantal fouten heeft gegenereerd. Selecteer om de resultaten van de poging tot compilatie te bekijken Bouw> Bouw resultaten.
Als u de vermelde fouten selecteert, gaat u rechtstreeks naar de regel met code waar de fout wordt gerapporteerd. Een belangrijk ding om in gedachten te houden is echter dat het aantal fouten dat door de compiler wordt gerapporteerd en de regelnummers van die fouten moeten worden beschouwd als de "beste schatting" van wat er mis is met uw applicatie, geen doorslaggevende uitspraak.
In feite kan één eenvoudige syntaxisfout ertoe leiden dat de compiler meerdere fouten meldt die schijnbaar geen verband houden met het probleem. Bekijk als voorbeeld de "Verwachte bracket vóór 'setImage'" foutlijn. Als u de betreffende regel bekijkt, zou u moeten constateren dat de syntaxis perfect is. Het blijkt dat het probleem hier niet op de regel is gemeld, maar de lijn er net boven. Zie je het probleem?
De NSLog () verklaring is niet beëindigd met een puntkomma. Dit betekent dat de compiler niet weet dat je van plan was om de regel te beëindigen na de laatste haakjes, en bekijkt alles vanuit NSLog tot de laatste sluitingsbeugel en puntkomma hierna UIControlStateNormal als één verklaring.
Voeg de puntkomma toe om het te voltooien NSLog uitspraak:
NSLog (@ "In crunchCookie");
Sla het bronbestand op en klik opnieuw op "Build and Debug". Twee van de drie oorspronkelijk weergegeven fouten zouden nu moeten worden opgelost.
Selecteer vervolgens de "Geen verklaring van eigendom" fout. Zoals je kunt zien, meldt deze fout dat de eigenschap die we proberen samen te voegen niet bestaat. Om dit te controleren, opent u het FortuneCrunchViewController.h-bestand waarin de eigenschap had moeten worden gedeclareerd. Als u lijn 17 bekijkt, is de syntaxis correct, maar we hebben een mismatch tussen de eigenschap die we hebben gedeclareerd en degene die we proberen te synthetiseren. Objective-C is een hoofdlettergevoelige taal, wat betekent dat de 'C' in cookie moet worden omgezet in hoofdletters om overeen te komen met de eigenschap die we proberen te synthetiseren. Werk de eigenschapsverklaring in het headerbestand bij om te lezen:
@property (nonatomic, retain) IBOutlet * fortuneCookieButton;
Sla het bronbestand op en bouw en debug opnieuw. Deze keer in plaats van de buildresultaten te openen Bouw> Build and Debug, Klik eenvoudig op het foutpictogram in de rechter benedenhoek van Xcode.
Eén stap vooruit, vier stappen terug. De fout met betrekking tot de regel voor het samenstellen van eigenschappen is weg, maar we hebben een geheel nieuwe lijst met fouten. Wat is er gebeurd?
Dit is een goed moment om kennis te nemen van de verschillende fasen die worden weergegeven in het venster Buildresultaten:
Merk op dat we één waarschuwing hebben onder het gedeelte "Compile" van de output van de buildresultaten. Dit is dezelfde sectie waarin onze eerdere fouten werden gerapporteerd. Nu de vorige drie fouten zijn opgelost, zijn we in staat geweest om van de compilatiefase naar de koppelingsfase van onze applicatie-build te gaan, en alle nieuwe fouten zijn fouten koppelen. Wanneer u een koppelingsfout tegenkomt, komt dit meestal doordat u probeert functies te gebruiken uit een framework dat u niet daadwerkelijk in uw toepassing hebt opgenomen. In dit geval verwijzen de Build-resultaten naar een functie genaamd _UIApplicationMain in het bestand main.o. Main.o is de gecompileerde machine-codeversie van main.m. Laten we de broncode in dat bestand eens bekijken. Op regel 13 ziet u een functieaanroep naar UIApplicationMain:
int retVal = UIApplicationMain (argc, argv, nil, nil);
UIApplicationMain is een centrale functie voor elke iOS-applicatie, maar hoe kun je er meer over ontdekken en uitvinden in welk kader het is opgenomen? Gelukkig wordt de iOS SDK geleverd met een aantal geweldige documentatie. Als u de optie (of alt) -knop ingedrukt houdt en dubbelklikt op de functienaam, start u een samenvatting van de officiële iOS SDK-documentatie waarin deze functie wordt besproken. Klik op het pictogram 'boek' in de rechterbovenhoek om de volledige beschikbare documentatie te bekijken. U kunt zien dat dit is gebeurd door de referentiedocumentatie van de functie voor het UIKit-framework te lanceren. Bingo, we hebben ons ontbrekende kader. Voordat we echter het framework aan het project toevoegen, zullen we een andere methode onderzoeken die je zou kunnen gebruiken voor het bepalen van de oorsprong van UIApplicationMain.
Sluit het documentatievenster. Houd nu de opdrachtknop ingedrukt en dubbelklik op de knop UIApplicationMain functie. U kijkt nu naar de bron van UIApplication.h, het bestand met de headerverklaring dat de bevat UIApplicationMain functie verklaring. Als u naar de bovenkant van het venster bladert, ziet u dat dit bestand meerdere andere UIKit-headers importeert en dat de opmerking bovenaan de framenaam 'UIKit' bevat.
Laten we verder gaan met het oplossen van deze koppelingsfouten door het UIKit-framework op te nemen. Klik hiervoor met de rechtermuisknop of klik op de map Frameworks in het deelvenster Groepen en bestanden en selecteer voeg> bestaande frameworks toe. Zoek het UIKit-framework op en klik op 'Toevoegen'. Als u ons werk wilt testen, selecteert u Build and Debug opnieuw.
Zoals u ziet, is de simulator met succes gestart en zijn we in staat om onze applicatie te bekijken. Dit betekent dat we alle fouten in de compileertijd in onze applicatie hebben opgelost.
Ga je gang en klik op de fortune-cookie ... Zoals je ziet, resulteert het klikken in de cookie in een runtime-fout en is de applicatie gecrasht. Het bericht linksonder in het Xcode-scherm is niet erg nuttig, dus laten we het van dichterbij bekijken door de console open te maken.
Op de console wordt zowel een oproepstapel weergegeven van wat er gebeurde in onze programma-uitvoering op het moment van de crash, als een meer gedetailleerde uitleg: "Beëindigen app vanwege niet-afgevangen uitzondering ... FortuneCrunchViewController cookieCruncher: niet-herkende selector verzonden naar instantie." Dit bericht betekent dat onze knop de verkeerde selector roept voor de gebeurtenis die we hebben geactiveerd door op de cookie te klikken. Omdat de interface voor FortuneCrunch is gebouwd in Interface Builder, laten we het Interface Builder XIB-bestand voor "FortuneCrunchViewController" openen om van dichterbij te bekijken.
Selecteer de cookieknop en beheer klik of rechtsklik om een lijst met verbonden acties weer te geven:
U kunt zien dat de gebeurtenis Touch Up Inside verwijst naar een doel dat niet bestaat, aangegeven door de gele tekst. Verwijder het niet-bestaande "cookieCruncher" -doel en verbind touchUpInside opnieuw met de eigenaar van het bestand door het "crunchCookie" -doel te selecteren dat in de vervolgkeuzelijst verschijnt. Sla uw werk op in Interface Builder, schakel terug naar Xcode en start de toepassing opnieuw.
Opnieuw klikken op de fortune-cookie resulteert in een runtime-fout. Deze keer is het consolebericht niet zo nuttig, het wordt gewoon weergegeven "EXC_BAD_ACCESS".
Kijk opnieuw naar de buildresultaten door te selecteren Bouw> Bouw resultaten. Heb je de waarschuwing eerder opgemerkt? Compilerwaarschuwingen zijn vaak een aanwijzing voor een potentiële runtimefout, maar omdat er niets mis is met de feitelijke syntaxis van de regel waarvoor de waarschuwing wordt gegeven, kan de compiler de applicatie nog steeds met succes bouwen. Natuurlijk zijn er tijden dat een compilerwaarschuwing een "valse vlag" is en niet resulteert in een run-time fout, maar meer dan 95% van de tijd, als de compiler een waarschuwing heeft gegeven dat je iets verkeerd doet.
Klik op de waarschuwing om naar de regel in uw broncode te springen waar deze zich heeft voorgedaan.
De waarschuwing verwijst naar incompatibele aanwijzertypen. Zie je het probleem? De methode imageNamed verwacht een NSString-object, maar deze coderegel levert de methode een letterlijke tekenreeks in C-stijl. Voeg het "@" -symbool toe om dit een Objective-C-reeks te maken:
[fortuneCookieButton setImage: [UIImage imageNamed: @ "cookie-closed.png"] forState: UIControlStateNormal];
Sla uw voortgang op en voer de applicatie opnieuw uit.
Deze keer, wanneer je op de fortune cookie klikt, kom je een logische fout tegen: de applicatie crasht niet en het label "Happy iPhone Hacking" verschijnt zoals verwacht, maar de achtergrondafbeelding blijft de gesloten cookie.
Om dit op te lossen, laten we eens kijken naar de functie die verantwoordelijk is voor de overgang: (IBAction) crunchCookie. Regel 19 is verantwoordelijk voor het wijzigen van de achtergrondafbeelding en je kunt zien dat de nieuwe achtergrondafbeelding wordt ingesteld op "cookie-closed.png". Als u kijkt naar cookie-gesloten in de map Resources, ziet u dat dit in feite hetzelfde beeld is dat wordt weergegeven wanneer de app voor het eerst wordt geladen. We moeten die regel wijzigen om over te schakelen naar "cookie-crunched.png":
[fortuneCookieButton setImage: [UIImage imageNamed: @ "cookie-crunched.png"] forState: UIControlStateNormal];
Bouw de toepassing opnieuw en voer deze uit ... en als u nu op de cookie tikt, wordt de verwachte achtergrondafbeelding weergegeven met het label correct weergegeven.
Gefeliciteerd! U hebt zojuist het proces doorlopen van het corrigeren van compilatiefouten, runtime-fouten en logische fouten in een toepassing. Al die tijd hebben we nauwelijks gebruik gemaakt van de krachtige tools voor foutopsporing die voor u beschikbaar zijn met Xcode.
Om verder te gaan met onze verkenning van de meer geavanceerde debuggingtools die beschikbaar zijn, proberen we de FortuneCrunch-app uit te breiden om het een beetje interessanter te maken. In plaats van de statische reeks "Happy iPhone Hacking!" Weer te geven, elke keer dat de cookie wordt gecrackt, laten we een array van meerdere bouwen NSString waarden die kunnen worden weergegeven.
Schakel terug naar Xcode en open het FortuneCrunchViewController.h-bestand. Voeg het volgende gegevenslid toe:
NSArray * fortuinen;
Deze array wordt gebruikt om onze willekeurige fortune-strings te houden.
Voeg nu de volgende methodehandtekening toe:
-(NSString *) generateRandomFortune;
Deze regel verklaart een nieuwe methode in onze klasse die zal worden gebruikt om een willekeurig fortuin uit onze fortuinen-array te selecteren.
Schakel vervolgens over naar FortuneCrunchViewController.m. Aangezien deze klasse wordt geïnitieerd vanuit ons XIB-bestand, moeten we de .overschrijving negeren initWithCoder methode en wijs de array toe die we in het .h-bestand hebben gedeclareerd en initialiseer deze met een aantal nieuwe fortuinen:
-(id) initWithCoder: aDecoder self = [super initWithCoder: aDecoder]; if (self) fortunes = [[NSArray alloc] initWithObjects: @ "Wie vuil gooit verliest terrein.", @ "Een gesloten mond verzamelt geen voeten.", @ "Help! Ik ben een gevangene in een bakkerij! ", Nihil]; terugkeer zelf;
Nu we een nieuwe hebben gemaakt NSArray, vergeet niet om het in de dealloc methode:
-(void) dealloc [fortunes release];
Laten we verder gaan met het coderen van de generateRandomFortune functie:
-(NSString *) generateRandomFortune int chosen_index = arc4random ()% 3 * 10; return [fortuinen objectAtIndex: chosen_index];
Deze regels genereren eenvoudigweg een nieuw, willekeurig indexnummer dat we gebruiken om de bijbehorende fortune-reeks te retourneren.
Pas ten slotte de crunchCookie methode om een van onze willekeurige fortuinen te gebruiken in plaats van de statische tekst "Happy iPhone Hacking!":
fortuneLabel.text = [zelf genererenRandomFortune];
Bouw en voer de applicatie uit na het opslaan van deze wijzigingen. Als u op de cookie klikt, maakt u een runtime-fout. Om uit te zoeken waarom dit gebeurt, gebruiken we de Xcode-foutopsporing en aangepaste breekpunten.
Een breekpunt is een vlag die naar uw toepassing stuurt dat de uitvoering van het programma moet "pauzeren" wanneer de lijn met het breekpunt wordt bereikt. Als u uw toepassing in de "Build and Debug-modus" uitvoert, kunt u breekpunten gebruiken. Om een onderbrekingspunt in te stellen, klikt u gewoon in de editor "goot" op de lijn waar u een onderbrekingspunt wilt activeren. Om erachter te komen wat er in onze applicatie gebeurt, gaan we ons breekpunt op de NSLog regel, net nadat de crunchCookie-methode wordt genoemd:
Bouw en debug de applicatie met dit nieuwe breekpunt op zijn plaats.
Nadat de toepassing is geladen, klikt u op de cookie. Als u in de linkeronderhoek van Xcode kijkt, ziet u het statusbericht "Stopped at breakpoint 1". Dit betekent dat de debugger met succes de uitvoering van het programma heeft gestopt bij het onderbrekingspunt dat u hebt ingesteld. U zult ook opmerken dat een rode pijl de huidige regel van uitvoering aangeeft waar de foutopsporing het programma heeft "gepauzeerd".
Dus, wat kun je doen met de debugger? Meer dan kan worden behandeld in een enkele tutorial. Er zijn echter drie fundamentele acties die u op dit moment kunt ondernemen: stap over, stap in en stap uit. Al deze opties zijn beschikbaar voor u via de ingebouwde debugger-menubalk.
Als u op de knop "Stap over" op het foutopsporingsmenu in de code drukt, ziet u dat de uitvoering van het programma doorgaat naar de volgende regel. "Stap over" zal gewoon de uitvoering van regels per regel voortzetten binnen de huidige methode, maar het zal uw code-uitvoering niet volgen als het naar een andere methode gaat. Als u de code-uitvoering daadwerkelijk wilt volgen in andere methodeaanroepen in uw code, moet u de knop "Stap in" gebruiken.
Zoals je kunt zien, heeft stap in feite ons in de generateRandomFortune methode, en dat is precies wat we willen. Klik opnieuw op "Stap over" om te zien wat er gebeurt wanneer arc4random () wordt genoemd. Zou het niet leuk zijn als we wisten waar de variabele selected_index zojuist op was ingesteld? Gelukkig kunnen we dat! Een van de beste functies van het gebruik van de debugger is de mogelijkheid om eenvoudig muisvariabelen te gebruiken om snel hun waarde te zien.
Het is duidelijk dat de chosen_index waarde is veel groter dan de lengte van onze array. Anders dan in sommige andere programmeertalen, retourneert de randomiseringsfunctie die we gebruiken een geheel getal, dus het is niet nodig om van een decimaal naar een geheel getal te converteren door de waarde met 10 te vermenigvuldigen. Werk de te lezen regel bij:
int selected_index = arc4random ()% 3;
We zijn klaar met het aanbrengen van wijzigingen in deze functie, dus gebruik de knop "Step Out" om deze subfunctie te verlaten en terug te keren naar crunchCookie. Merk op dat hoewel we het niet zagen, de rest van de functie als normaal wordt uitgevoerd.
Houd tot slot rekening met de breekpuntknop "Activeren / Deactiveren" en de knop "Doorgaan met uitvoeren" op de menubalk van de in-code-debugger. "Doorgaan met uitvoeren" zorgt ervoor dat de uitvoering van het programma gewoon door kan gaan. Je kunt het beschouwen als de knop "ongedaan maken". Ga je gang en druk hier nu op.
Voordat we verdergaan met het uitschakelen van breekpunten, is er nog een probleem dat moet worden aangepakt: wat je zojuist hebt meegemaakt, wordt de "in-code debugger" genoemd. Het is zeer krachtig, maar er zijn ook twee andere debugging-modi voor u beschikbaar: het volledige debugger-venster en het mini-debugger-perspectief.
Om toegang te krijgen tot het volledige foutopsporingsvenster, klikt u op het pictogram "foutopsporing" op de menubalk van de in-code-debugger. Dit venster bevat aanzienlijk meer informatie dan de foutopsporing in de code. Aan de linkerkant heb je een stack-trace die de context van de uitvoering van het programma toont (je hebt ook de mogelijkheid om uit een van de momenteel voortgebrachte threads te kiezen). Rechts ziet u een snel overzicht van de verschillende variabelen die momenteel in het geheugen worden bewaard. Als u een andere call-stacksignatuur selecteert, verandert uw weergave in de foutopsporing. U kunt de lay-out van het Debugger-venster wijzigen door naar Uitvoeren> Debugger-weergave.
Ten slotte is de mini-debugger nog een ander debugging-perspectief dat voor u beschikbaar is. Ik gebruik dit perspectief zelden, maar het is beschikbaar voor jou Uitvoeren> Mini-foutopsporing.
Omdat we zojuist de fout hebben opgelost die is geïntroduceerd in onze willekeurige fortuincode, hebben we de debugger niet langer nodig. Breekpunten uitschakelen. Maar voordat we de applicatie opnieuw bouwen, kunnen we de lettergrootte van ons waarzegetiket aanpassen.
Open Interface Builder, selecteer het label en verander het lettertype in het infovenster in Arial Black, 9 punt, en selecteer vervolgens het vakje "Aanpassen om te passen" en verander de minimale tekengrootte naar 6 punt. Bouw het project nu opnieuw en voer het uit.
Voila! Onze applicatie functioneert nu zoals wij het bedoeld hebben.
Nu u kennis hebt gemaakt met de basisprincipes van het gebruik van de Debugger in Xcode, kunt u overwegen de volgende richtlijnen toe te passen in uw workflow voor dagelijkse ontwikkeling:
Hoewel de simulator een nuttige methode is om een toepassing te testen tijdens de ontwikkelingsfase van uw product, is deze geen vervanging voor testen op een fysiek apparaat. Dit komt omdat de Simulator en een iOS-apparaat op belangrijke en fundamentele manieren van elkaar verschillen. De simulator draait bijvoorbeeld duidelijk binnen OS X en het bestandssysteem op OS X is niet hoofdlettergevoelig. Het bestandssysteem op iOS is echter hoofdlettergevoelig. Dus refererend aan het bestand koekje-CRUNChed.png, in plaats van koekje-crunched.png, werkt prima in de simulator, maar faalt op een echt iOS-apparaat. Een andere belangrijke overweging is dat de simulator veel meer geheugen beschikbaar heeft dan een daadwerkelijk apparaat, en dit feit zal vaak een grote invloed hebben op de gebruikerservaring. Ten slotte zijn niet alle standaardtoepassingen die met iOS worden geleverd beschikbaar in de simulator, inclusief de programma's Kaarten en de App Store. Dit betekent dat u met de Maps-app geen code kunt uitproberen die routeaanwijzingen genereert of in de simulator applicaties in de App Store cross-promoot. Dit zijn slechts enkele van de verschillen die er zijn. Ik raad ten stelligste aan om te testen op zoveel fysieke iOS-apparaten die zoveel mogelijk verschillende doelgerichte versies van iOS gebruiken.
De Clang Static Analyzer is een speciale statische C / Objective-C-analysetool die wordt geleverd met Xcode. Deze tool kan uw code analyseren op fouten of inconsistenties die anders onopgemerkt zouden blijven.
Hoewel de details van de werking van de analyser buiten het bestek van dit artikel vallen, is het gebruik ervan gelukkig heel eenvoudig. Om een statische analyse van uw code uit te voeren, selecteert u eenvoudigweg Bouw> Build and Analyse uit het Xcode build-menu.
Als u meer wilt weten over hoe de "Build and Analyse" -optie werkt, kunt u online informatie over Static Code Analysis en de Clang Static Analyzer lezen..
In deze zelfstudie hebben we geleerd hoe breekpunten werken door projectspecifieke breekpunten in onze code in te stellen. Naast projectspecifieke onderbrekingspunten kunt u met Xcode ook 'globale' onderbrekingspunten instellen die van toepassing zijn op alle iOS-projecten die u in Xcode maakt. Een globaal breekpunt instellen op objc_exception_throw stelt u in staat om de foutopsporing automatisch te starten wanneer zich een uitzondering (een type runtime-fout) voordoet. Als u meer wilt weten over de voordelen van deze aanpak en hoe u deze in code kunt implementeren, raadpleegt u mijn iOS-snel tip voor objc_exception_throw en wereldwijde breekpunten.
Zoals eerder in deze zelfstudie is vermeld, moet de overgrote meerderheid van de compilerwaarschuwingen die zijn uitgegeven, worden opgelost voordat u uw project start en er mag nooit een scenario zijn wanneer de code compilerwaarschuwingen genereert moet blijven ongewijzigd om een toepassing goed te laten werken. Daarom bevelen sommige programmeurs aan om alle compilerwaarschuwingen als fouten te behandelen, waardoor ze worden gedwongen om te worden opgelost als onderdeel van het normale ontwikkelingsproces.
Voor alle, behalve enkele marginale gevallen, ondersteun ik dit idee en Xcode maakt het eenvoudig te implementeren. Ga naar Project> Projectinstellingen bewerken en selecteer vervolgens het tabblad Opbouwen. Typ 'Waarschuwing behandelen' in de zoekbalk en u ziet een booleaanse waarde met de naam 'Waarschuw waarschuwingen als fouten'. Vink dit vakje aan om de functie in te schakelen.
Een andere stap die u kunt nemen om de kans te vergroten dat uw aanvraag wordt geaccepteerd de eerste keer dat u deze bij de iTunes Store indient, is door de 'Build and Validate'-vlag in te schakelen in de instellingen van de project-build. Typ 'valideren' in het zoekvak van het tabblad met de build-instellingen van het project en selecteer vervolgens 'Build Product valideren'. Deze optie voert een aantal tests uit die door de beoordelaars van Apple zijn uitgevoerd, waardoor u mogelijk een afwijzing van de App Store kunt voorkomen. Opgemerkt moet worden dat het aanvinken van dit vakje geen garantie is dat uw app de beoordeling van de App Store zal passeren, maar het is beter dan niets.
Naast de console, de resultaten en de Debugger, zijn er een paar andere geweldige hulpprogramma's voor het opsporen van fouten en optimalisatie waarmee u rekening moet houden bij uw ontwikkelingsinspanningen. Lees voor meer informatie de documentatie voor de volgende hulpmiddelen:
Dit was een wervelende tour van debuggen met de iOS SDK. Er is nog veel meer dat kan worden gedaan, maar hopelijk is deze les voldoende geweest om u te helpen de bugs in uw eigen applicaties sneller op te lossen en betere software te schrijven! Als u meer wilt weten over sommige van de geavanceerde tools die in deze zelfstudie worden besproken, zoals Instruments, Shark of SpinControl, of als u meer wilt weten over debuggen in het algemeen, laat dan hieronder een reactie achter en laat het me weten!
Accentsconagua