Arbetar med iPhone 5-skärmen

Denna handledning kommer att se över de steg som är nödvändiga för att se till att dina iOS-appar fortsätter att se bra ut när de visas på den nya iPhone 5-skärmen.


Ladda ner de senaste verktygen

För att skapa appar som är kompatibla med iOS 6 och iPhone 5 måste du se till att du har Xcode 4.5 (eller senare) och iOS 6 SDK installerad på din utvecklingsmaskin. När Xcode är öppen väljer du Xcode> Om Xcode från menyraden för att kontrollera den installerade versionen.

För att få de senaste verktygen måste du gå till Apple Developer Center efter att du registrerat dig som en Apple-utvecklare.

Jag rekommenderar att du tar det extra steget att installera både iOS 5.1 och iOS 5.0-simulatorerna och "kommandoradsverktygen" efter att du installerat den senaste versionen av Xcode. För att göra detta, välj Xcode> Inställningar och sedan gå till Nedladdningar flik. Installera de extra alternativen som anges. När du har gjort så ska fönstret se ut så här:


Använd en iPhone 5 Standard Launch Image

Du måste inkludera en bild som heter [email protected] i ditt projekt för att dra full nytta av iPhone 5-skärmen. Det kan verka som godtyckligt, men förekomsten av den här filen är vad som kommer att avgöra om din ansökan körs i brevlådsläge (dvs med svarta band över och under innehållet) eller i helskärmsläge.

Självklart är det [email protected] filen har också ett annat syfte: det blir standardbilden som visas när din applikation laddas på en iPhone 5. Det tjänar samma funktion som Default.png fil för iPhone / iPod touch-enheter utan näthinnan och [email protected] fil för iPhone 4 / 4S.

När du kör ett projekt i Xcode 4.5 utan [email protected] filen kan du få en automatisk popup som den här:

Om så är fallet, fortsätt och klicka på "Lägg till" för att få Xcode skapa en solid black launcher för dig, kom ihåg att ändra det senare till något mer lämpligt för din ansökan.

Om du inte ser Xcode-popupen kan du spara den här bilden på din dator och dra sedan den till Xcode-projektnavigationsområdet för att lägga till den i ditt projekt. En vanlig svart lanseringsbild är inte idealisk, men den uppfyller kravet och placerar din app i helskärmsläge.

Bygg och kör ditt projekt på en iPhone 5. Idealiskt bör du vara bra att gå utan ytterligare justeringar! Det finns dock ett antal anledningar till varför din app kanske inte ser rätt ut i den nya upplösningen. Den andra halvan av denna handledning kommer att täcka felsökningsapplikationer som misslyckas med att visa lämpligt efter att ha följt det här steget.


Övergång till dynamiska layouter

IOS-utvecklare har varit lite bortskämd i jämförelse med deras Android-peers när det gäller att visa layoutprogrammering. Till att börja med hade alla de ursprungliga iPhone- och iPod touch-skärmarna samma bildskärmsupplösning: 320x480 pixlar. När näthinnan som användes av iPhone 4 och 4S introducerades 2010 fördubblades bildskärmsupplösningen till 640x960 pixlar, men utvecklare var fortfarande kunna hänvisa till skärmstorlek i kod som 320x480. Varför? Eftersom iOS 4 Apple introducerade begreppet "logiska punkter" i UIKit. Dessa punkter kan mapa till fysiska pixlar dynamiskt via contentScaleFactor egenskapen hos UIView klass. De contentScaleFactor inställdes sedan logiskt spegla upplösningsändringen genom att defaulting till 1.0 på iPhone 3G / 3GS och 2.0 på 4 / 4S.

Att citera från Apples ritnings- och utskrivningsguide för iOS:


I IOS skiljer man mellan de koordinater du anger i din ritningskod och pixlarna för den underliggande enheten. När du använder inbyggd teckningsteknik som Quartz, UIKit och Core Animation, är rit koordinatutrymmet och vyens koordinatutrymme båda logiska koordinatutrymmen med avstånd mätta i punkter. Dessa logiska koordinatsystem avkopplas från enhetens koordinatutrymme som används av systemramarna för att hantera pixlarna på skärmen.

Systemet kartlägger automatiskt punkter i vyens koordinatutrymme till pixlar i enhetens koordinatutrymme, men denna kartläggning är inte alltid en-till-en. Detta beteende leder till ett viktigt faktum att du alltid bör komma ihåg:

En punkt motsvarar inte nödvändigtvis en fysisk pixel.

Syftet med att använda punkter (och det logiska koordinatsystemet) är att tillhandahålla en konsekvent storlek på utgången som är enhetoberoende. För de flesta ändamål är den faktiska storleken på en punkt irrelevant. Målet med poäng är att tillhandahålla en relativt konsekvent skala som du kan använda i din kod för att ange storlek och position för visningar och renderat innehåll. Hur poäng är faktiskt kartlade till pixlar är en detalj som hanteras av systemramarna. På en enhet med en högupplöst skärm kan en linje som är en punkt bred faktiskt resultera i en rad som är två fysiska pixlar breda. Resultatet är att om du ritar samma innehåll på två liknande enheter, med bara en av dem som har en högupplöst skärm, tycks innehållet ungefär lika stort på båda enheterna.

Så som iOS-utvecklare har vi haft det ganska lätt tack vare denna innovation. Men med införandet av 640x1136px upplösningen på iPhone 5 kommer det att använda en vertikal storlek på 480 punkter inte längre fylla allt tillgängligt vertikalt utrymme.

För att se detta i åtgärd, antar att en programmerare försöker lägga till en anpassad bakgrundsvy programmatiskt till rotvynskontrollen av deras program. Låta att programmeraren skrev den här koden för att göra det:

 UIView * customBackgroundView = [[UIView alloc] initWithFrame: CGRectMake (0,0f, 0,0f, 320,0f, 480,0f)]; customBackgroundView.backgroundColor = [UIColor redColor]; customBackgroundView.autoresizingMask = UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth; [self.view addSubview: customBackgroundView];

Före iPhone 5 skulle ovanstående kodblock ha fungerat bra. De logiska punkterna 320x480 skulle kartlägga till 640x960 med standard 2,0-skalfaktorn för iPhone 4 / 4S. Men på iPhone 5 kommer höjden fortfarande att kartläggas till 960 pixlar och kommer upp kort:

Att lösa detta problem är ganska enkelt:

 UIView * customBackgroundView = [[UIView alloc] initWithFrame: CGRectMake (0.0f, 0.0f, self.view.frame.size.width, self.view.frame.size.height)]; customBackgroundView.backgroundColor = [UIColor redColor]; customBackgroundView.autoresizingMask = UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth; [self.view addSubview: customBackgroundView];

I detta scenario behövde vi bara dra storleken på den aktuella rotvyn dynamiskt för att placera den nya, anpassade bakgrundsbilden över hela området.

För ett annat exempel, låt oss anta att programmeraren ville skapa en ny vy programmerat i loadView: metod:

 - (void) loadView CGRect applicationFrame = [[UIScreen mainScreen] applicationFrame]; UIView * customView = [[UIView alloc] initWithFrame: applicationFrame]; customView.backgroundColor = [UIColor redColor]; customView.autoresizingMask = UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth; self.view = customView; 

De applicationFrame egendom av UIScreen kommer att returnera ramrektangelgränsen som används för fönstret för den aktuella applikationen, minus det område som upptas av statusfältet (om det är synligt). Du kan alternativt få bara den avgränsande rektangeln på skärmen med [[UIScreen mainScreen] gränser]. Båda värdena kommer att returneras i logiska punkter, inte pixlar.

Medan ovanstående kodexempel är användbara är de också något begränsade. I praktiken kan du behöva hantera mer komplexa scenarier som involverar dynamisk dimensionering av många undervisningar beroende på enhetens skärmhöjd.

Lyckligtvis finns det minst tre olika tillvägagångssätt som du kan använda för att göra det.

Visa Autoresizing

De UIView fast egendom autoresizingMask är ett enkelt men ändå effektivt sätt att se till att undervisningsobjekten justeras dynamiskt i förhållande till deras övervakning. I det ovanstående kodbiten använde jag detta för att se till att både bredden och höjden på det anpassade bakgrundsbildobjektet skulle skala på lämpligt sätt med orienteringsändringar:

 customBackgroundView.autoresizingMask = UIViewAutoresizingFlexibleHeight | UIViewAutoresizingFlexibleWidth;

Observera att autoresizingMask egendom kan styras visuellt från Xcode / Interface Builder också.

De flesta applikationer som använder UIKit-kontroller och standardbehållare ska kunna fungera bra på iPhone 5 genom att kombinera variabla värden för bildframställning (som visat tidigare) och ställa in intelligenta autoresceringsegenskaper på undervyer.

Mer information finns i den officiella Apple-dokumentationen och visningsprogrammeringsguiden.

Auto Layout System

Det nya Auto Layout-systemet som introducerades med iOS 6 ger en avancerad metod för att styra visningsplacering. Auto Layout använder ett system med begränsningar för att förklara och tillämpa visa relationer. Den enda nackdelen med att använda Auto Layout är att den inte är kompatibel med iOS 5 och tidigare.

Ytterligare täckning av Auto Layout ligger utanför ramen för denna handledning. De som vill lära sig mer bör konsultera Apples Cocoa Auto Layout Guide och WWDC 2012 Introduktion till Auto Layout-session.

Enhetsprovning

Ett annat tillvägagångssätt som antas av vissa är att försöka kontrollera om den nuvarande enheten är en iPhone 5 vid körning. Den mest avancerade versionen av det här jag har hittat är från det här svaret på StackOverflow.

Följande är en något modifierad version av makronen som skapades i StackOverflow-inlägget:

 #define IS_IPHONE ([[[UIDevice currentDevice] modell] isEqualToString: @ "iPhone"]) #define IS_IPOD ([[[UIDevice currentDevice] modell] isEqualToString: @ "iPod touch"]) #definierad IS_HEIGHT_GTE_568 [[UIScreen mainScreen] ] .size.height> = 568.0f #define IS_IPHONE_5 (IS_IPHONE && IS_HEIGHT_GTE_568)

Det första och det andra makroet kontrollerar om den aktuella enheten är en iPhone eller iPod touch genom att använda UIDevice klass.

Det tredje makrokontrollen kontrollerar om skärmens höjd är större än eller lika med flytpunktsvärdet 568. Återkalla ovanifrån att [[UIScreen mainScreen] gränser] meddelandet kommer att returnera programfönsterets gränsvärde i logiska punkter och att 568 logiska punkter kommer att kartläggas till 1136 pixlar med standardvyn contentScaleFactor av 1,0.

Slutligen kombinerar det fjärde makro två av de tidigare makronen till en IS_IPHONE_5 makro som (för tillfället) bara ska returneras SANT om koden körs på en iPhone 5. Du kan använda den slutliga versionen i din egen kod så här:

 om (IS_IPHONE_5) NSLog (@ "Hej, det här är en iPhone 5! Tja, kanske ... vilket år är det?");  else NSLog (@ "Bummer, det här är inte en iPhone 5 ..."); 

Även om ovanstående tillvägagångssätt är potentiellt användbart är det också felaktigt. Till exempel, vad händer om iPhone 6 släpps med helt nya dimensioner? Jag skulle råda emot att använda denna metod om möjligt. Istället håller du dig vid Autoresizing Masks eller Auto Layout om du kan göra en av dessa tillvägagångssätt.


Sammanfatta

Denna handledning har förklarat de olika metoderna som finns för att rymma den förstorade iPhone 5-skärmen. Om du har kämpat med att anpassa dig till den nya skärmstorleken har du förhoppningsvis funnit innehållet användbart!

Lämna gärna feedback som du har i kommentarfältet nedan. Du kan också ansluta mig till Twitter, Google Plus eller LinkedIN. Skål!