Share
Wat je gaat creërenNaast ontwikkeling van functies en bugfixes, moeten iOS-ontwikkelaars bijhouden wat er jaarlijks op WWDC wordt aangekondigd. Te midden van de opmerkelijke nieuwe SDK's die zijn aangekondigd, zijn er enkele wijzigingen die iOS-ontwikkelaars moeten implementeren om hun apps platform-compatibel te houden.
Nu Swift is geëvolueerd naar versie 4, samen met verbeteringen en veranderingen die naar de iOS SDK zelf komen, moeten ontwikkelaars de veranderingen doornemen en een strategie bedenken voor het updaten van hun codebases. Alles zonder een van hun bestaande functies en functionaliteiten te breken! Het komt allemaal neer op het stellen van prioriteiten voor uw project: wat is het minimum dat u moet doen om uw iOS 11-compatibele app te maken? Wat is het eenvoudigste geval dat u kunt doen aan uw project-stakeholder of projectmanager?
Vitale functies staan voorop, en de volgende zijn de leuke, maar niet vereiste verbeteringen die iOS 11 met zich meebrengt, van het optimaliseren van je toepassing tot de visuele esthetiek die de interactie en functionaliteit van je app verder zal verrijken. Met dat in gedachten, zal deze tutorial je helpen bij het nemen van de stappen om je app te upgraden, waarbij je een pragmatische aanpak kiest voor vereiste en optionele verbeteringen.
Dit artikel geeft u een overzicht van de wijzigingen die nodig zijn om uw app voor iOS 11 bij te werken, van architecturale tot visuele wijzigingen evenals wijzigingen in de publicatie van de App Store. Bovendien organiseert deze tutorial de secties, beginnend bij de vereiste veranderingen en de vereiste reikwijdte en inspanning, tot de leuke, maar niet noodzakelijke functies die uw app verbeteren als gevolg van iOS 11.
In deze tutorial behandelen we het volgende:
Deze tutorial veronderstelt een gemiddelde kennis van Swift of Objective-C en Xcode, evenals bekendheid met de belangrijkste iOS SDK's (bijvoorbeeld UIKit en Core Foundation).
Zoals bij elke iteratie van iOS, zijn de belangrijkste wijzigingen meestal de architecturale. Met iOS 11 gaat het om migreren naar Swift 4, dus het bijwerken van de bouwinstellingen voor Xcode 9 is de eerste taak die we zullen bekijken.
Belangrijk | Verplicht
Voor degenen die vorig jaar van Swift 2 naar 3 moesten migreren, was dat proces buitengewoon pijnlijk en veel van de wijzigingen braken de bestaande codebase. Gelukkig is dit niet het geval om over te schakelen van Swift 3.2 naar 4, omdat de meeste kansen eerder als additief dan als afkeurend worden beschouwd en als gevolg daarvan voert de Xcode 9-migratietool een bewonderenswaardige taak uit door uw code over te zetten naar de nieuwste Swift.
Bovendien zul je, in tegenstelling tot eerdere versies, niet gedwongen worden om de upgrade naar 4 in één keer uit te voeren. Dat wil zeggen, Xcode-projecten ondersteunen gelijktijdig zowel Swift 4 als Swift 3.2, wat betekent dat je één doelwit in je project kunt compileren onder Swift 3.2 en een ander compileert in Swift 4. Het migratietool laat je weten welke klassen en functies het succesvol heeft gemigreerd en voor welke handmatige tussenkomst u moet oplossen in de vorm van fouten of waarschuwingen.
De fouten betekenen dat u iets moet repareren dat niet achterwaarts compatibel is, terwijl veel van de waarschuwingen zullen aangeven dat er in Swift 4 een nieuwe manier is om iets te doen, zoals nieuwe API-wijzigingen. Los de fouten op en geef prioriteit aan de bovengenoemde waarschuwingen als een afzonderlijke taak.
Ga naar voor toegang tot de migratietool Bewerken> Converteren> Naar huidige Swift-syntaxis in Xcode en volg de aanwijzingen en selecteer het doel (de doelen) die u in dit stadium wilt migreren.
Met de migratietool kunt u het minimumwerk bepalen dat u moet doen om uw app opnieuw te compileren. Daarom is het niet verwonderlijk dat de aanbevolen beste werkwijze is om uw app van 3 naar 4 stapsgewijs te migreren, met name in grote projecten, het testen en converteren van doel per doel. U hoeft niet alles tegelijk te migreren en u kunt uw migratiepad stapsgewijs plannen, waar en wanneer nodig.
We zullen hierna snel bekijken wat de veranderingen in Swift 4 zijn die niet verplicht zijn om te implementeren, maar goed om te weten.
Belangrijk | Verplicht
Een andere belangrijke verandering in iOS 11 is dat alle apps in de App Store nu 64-bits moeten zijn, omdat 32-bits apps niet langer worden ondersteund en feitelijk zelfs niet werken op apparaten met iOS 11. Dit Het zou geen verrassing moeten zijn dat Apple al een tijdje ontwikkelaars waarschuwt, maar in het geval dat je app nog steeds niet is overgestapt, kun je de richtlijnen van Apple volgen voor het converteren van je app naar een 64-bit binair getal.
Niet belangrijk | facultatief
Naast het verplichte werk dat u nodig hebt om ervoor te zorgen dat uw doel voldoet aan de Swift 4-norm, kunt u uw bestaande code herschrijven om de nieuwe Swift API-wijzigingen te gebruiken, die worden opgesplitst volgens de volgende verbeteringen op API-niveau:
String heeft in Swift 4 veel aandacht gekregen, met als meest opvallende verandering terug naar Swift 1.0, waar Strings opnieuw als verzamelingen worden gedefinieerd, dus je kunt een String-object van teken tot teken (SE-0163) herhalen met een for loop. Andere opmerkelijke wijzigingen in de klasse Strings zijn onder meer:
Accentsconagua
unicodeScalars eigendom aan KarakterWoordenboeken en sets, als onderdeel van collecties, zijn ook vernieuwd in Swift 4, te beginnen met het filteren van woordenboeken, die tot nu toe een array van tuples retourneerden bestaande uit sleutel / waardeparen. Om toegang te krijgen tot een specifiek element, zou u het volgende subscript gebruiken, zoals in een array:
listOfCars [4] .value
In Swift 4 krijg je in plaats daarvan een woordenboek terug, wat zorgt voor een meer consistente syntaxis, en vervolgens krijg je toegang tot het geretourneerde woordenboek zoals je een normaal woordenboek zou doen. Hetzelfde gebeurt nu voor de kaart() functie, waarbij u ook een woordenboek terugkrijgt. Nieuw voor subscripties met woordenboektoegang, u kunt een standaardwaarde opgeven voor het geval de sleutel niet bestaat, waardoor uw code veiliger is.
laat tomTheCat = animal ["name", standaard: "id"]
De rest van de wijzigingen voor collecties omvatten:
MutableCollection.swapAt (_: _ :)Ten slotte zijn er enkele diverse veranderingen die het vermelden waard zijn als onderdeel van deze versie met betrekking tot de taal:
U kunt de volledige lijst met wijzigingen en originele voorstellen vinden op Swift.org.
iOS 11-gebruikers van de App Store zouden al gemerkt hebben dat het een compleet nieuw ontwerp met hele nieuwe secties is, dat ontwikkelaars nieuwe manieren biedt om hun apps te promoten en met hun gebruikers te communiceren..
We beginnen met een kijkje in het nieuwe marketingpictogram dat u nu moet uploaden met uw app-updates.
Verplicht | Hogere prioriteit
Vanaf iOS 11 moet je voor elke nieuwe inzending, een nieuwe of bestaande app toevoegen icon-1024.png-een 1024x1024 marketing pictogram. Handig genoeg hoeft u het pictogram niet via iTunes Connect in te dienen, maar via Xcode viagaan naar Images.xcassets en het toevoegen van de juiste grootte afbeelding, op dezelfde manier als je je andere iconen beheert:
Het marketingpictogram wordt gebruikt als onderdeel van het nieuwe App Store-ontwerpproces om een groter afbeeldingspictogram weer te geven dat uw app in het gedeelte Vandaag vertegenwoordigt, of in andere gedeelten waarin de app-afbeelding is vergroot.
Optioneel | Lagere prioriteit
Apple heeft het proces van in-app-aankopen prominenter en transparanter gemaakt, zodat gebruikers alle in-app-inkoopopties rechtstreeks op hetzelfde niveau als het app-productdisplay kunnen bekijken en zelfs een in-app-aankoop voor de app kunnen starten. app tijdens het downloaden van de daadwerkelijke app. Denk aan een abonnement-app waarbij gebruikers die uw app downloaden mogelijk al hun abonnement willen kopen. iOS 11 maakt dit sneller en handiger.
Vanaf iOS 11 kunnen ontwikkelaars maximaal 20 in-app-aankopen promoten, zoals abonnementen op de productpagina van hun app. Deze aankoopopties worden ook weergegeven in de zoekresultaten.
Het promoten van in-app-aankopen kan ook het downloaden van uw app stimuleren. Wanneer een gebruiker uw app niet heeft geïnstalleerd maar een gepromote in-app-aankoop wil kopen, ontvangen ze een prompt om de app eerst te downloaden. Nadat de app is gedownload, wordt de transactie voortgezet in de app. (Appel)
Om een grotere zichtbaarheid van uw in-app-aankooppromotie mogelijk te maken, moet u in iTunes Connect de volgende metadata opnemen:
Raadpleeg voor meer informatie over het promoten van uw in-app-aankoop Officiële richtlijnen van Apple evenals die van Apple Richtlijnen voor productpagina's.
Optioneel | Lagere prioriteit
Iets dat zeker al veel eerder had moeten gebeuren en Android-ontwikkelaars al geruime tijd genoten hebben, is de mogelijkheid om direct te reageren op opmerkingen van gebruikers. Vanaf iOS 11 kunnen ontwikkelaars nu ook rechtstreeks reageren op de beoordelingen en opmerkingen van hun gebruikers. Hoewel dit geen technische wijzigingen vereist en deelname is optioneel, ontwikkelaars via iTunes Connect (App > Activiteit > ratings) kan zowel op lof als op kritiek reageren.
Geïndividualiseerde ontwikkelaarsreacties kunnen worden gebruikt om sterkere en meer intieme relaties op te bouwen, diepere betrokkenheid aan te moedigen, door te laten zien dat hun feedback wordt beoordeeld en waarop wordt gereageerd en er actief naar hen wordt geluisterd. Als u op opmerkingen wilt reageren, gaat u naar iTunes Connect waar u de feedback kunt bekijken en individueel kunt reageren.
Naast de nieuwe functie voor ontwikkelaarscommentaar heeft Apple ook een nieuwe geformaliseerde SDK verstrekt om gebruikers te vragen apps te beoordelen en beoordelen. De nieuwe SKStoreReviewController moet worden gebruikt in plaats van derden of gebruikers handmatig om recensies vragen, omdat Apple wil dat het besturingssysteem de frequentie van de prompts en hun visuele uiterlijk kan regelen. Apple beperkt daarom prompts tot niet meer dan drie keer in een periode van 365 dagen.
Implementeren SKStoreReviewController, importeer eenvoudig StoreKit en bel requestReview () zoals hieronder getoond:
... import StoreKit ... SKStoreReviewController.requestReview () ...
Hoewel Apple de andere methoden om gebruikers om feedback te vragen niet helemaal heeft verbannen, verwacht dat dit in de nabije toekomst zal veranderen, dus het is het beste dat je eraan denkt om de prompt-to-review-engine van Apple het komende jaar te implementeren..
Raadpleeg de richtlijnen voor beoordelingen, beoordelingen en reacties van Apple voor meer informatie.
Optioneel | Lagere prioriteit
Een andere zeer nuttige functie van iOS 11 voor ontwikkelaars is de mogelijkheid om hun apps stapsgewijs aan gebruikers beschikbaar te stellen. Apple noemt dit gefaseerd vrijgeven, en het is bedoeld om het risico van overbelasting van de productieomgeving in één keer te verminderen, maar in plaats daarvan de release-updates over een periode van zeven dagen uit te rollen.
Onder Versie vrijgeven in iTunes Connect is er een nieuw gedeelte genaamd Gefaseerde release voor automatische updates, wat je de mogelijkheid geeft om ofwel onmiddellijk vrij te geven ofwel gedurende de periode van zeven dagen. Ontwikkelaars zijn ook in staat de gefaseerde uitrol tot 30 dagen te stoppen, wat normaal zou gebeuren als een groot probleem wordt ontdekt en gerapporteerd.
De gefaseerde uitrol weerhoudt gebruikers er niet van om de update handmatig uit de App Store te krijgen, maar is eerder gericht op gebruikers die de automatische downloadinstelling van iOS gebruiken in de App Store.
Laten we vervolgens de visuele wijzigingen bekijken die werden geïntroduceerd als onderdeel van iOS 11, terwijl we zowel de belangrijke als de minder belangrijke onderwerpen doornemen.
Na het bekijken van de architecturale wijzigingen in de app store publishing voor iOS 11, zijn we nu klaar om de visuele veranderingen te ontleden en u te helpen bepalen welke UI-wijzigingen eerst moeten worden aangepakt.
Hoewel we zeker onze iOS-apps kunnen bouwen zonder de wijzigingen in deze sectie door te voeren, en alleen de architecturale en App Store-wijzigingen aanpakken, wilt u misschien eerst zorgen dat uw app de nieuwe iPhone X visueel ondersteunt. Dit betekent wijzigingen in de navigatiebalken om de nieuwe fysieke 'notch' aan de top aan te pakken.
Met dat in gedachten, zullen we eerst kijken naar het bijwerken van uw gebruikersinterface voor de iPhone X, gevolgd door enkele andere snelle wijzigingen die ervoor zorgen dat uw app modern en up-to-date is.
Verplicht | Hogere prioriteit
Een van de belangrijkste taken bij het bijwerken van uw iOS-app is zorgen dat uw app er goed uitziet en goed werkt op de nieuwere apparaten, zonder uw eerdere apparaatondersteuning te schenden. Daarom heeft Apple heel hard gewerkt om ontwikkelaars gereedschappen te bieden zoals Auto Layout om te ontwerpen voor schermagnische lay-outs, of het nu de iPhone 4, 5C of de 6 en 6 Plus is. Vanaf dit jaar hebben we nu een telefoon die niet alleen nieuwe dimensies heeft, maar ook een fysieke inkeping heeft bovenaan.
Merk op dat we geen rechthoekige viewport meer hebben en met de nieuwe inkeping aan de bovenkant voor de fysieke sensoren, hoe raadt Apple aan om daarmee om te gaan? Om te beginnen wil Apple niet dat je zwarte balken bovenaan plaatst om de inkeping te verbergen! In plaats daarvan pleiten ze ervoor dat ontwikkelaars het omarmen.
Niet maskeren of speciale aandacht vestigen op belangrijke display-functies. Probeer niet de afgeronde hoeken, het sensorhuis of de indicator van het apparaat te verbergen voor toegang tot het startscherm door zwarte balken boven en onder aan het scherm te plaatsen. Gebruik geen visuele versieringen zoals haakjes, randen, vormen of instructietekst om speciale aandacht te vestigen op deze gebieden. (iOS Human Interface Guidelines)
U moet ontwerpen voor de ervaring op volledig scherm, waarbij u gebruikmaakt van het omlijstingloze ontwerp van het nieuwe apparaat terwijl u delen van uw gebruikersinterface niet verdoezelt met de afgeronde hoeken van het apparaat of de sensorbehuizing (inkeping).
Het goede nieuws is, Apple's door het systeem geleverde UI-elementen van UIKit zoals de UINavigationBar is al conform en past zich direct aan de nieuwe ontwerpvereisten aan. Voor aangepaste UI-elementen moet u echter zelf het conformiteitswerk doen.
Als je naar de afbeeldingen van de iPhone 4.7 kijkt in vergelijking met de nieuwe iPhone X hierboven, zul je merken hoe de statusbalk nu anders is geïmplementeerd, te beginnen met de hoogte, die is gegroeid van de historische 20 pt naar 44 pt op de iPhone X.
Apple suggereert dat app-ontwikkelaars die hun statusbalk hebben verborgen, die beslissing in het licht van de iPhone X zouden moeten heroverwegen en deze alleen in de liggende modus, niet in de portretmodus moeten verbergen.
Maak ten slotte gebruik van de lay-outgidsen voor veilige gebieden door Auto-indelingen als primaire maatregel te gebruiken om ervoor te zorgen dat uw app binnen de juiste marges past, zodat er geen visuele obstakels zijn, zoals het onderlappen van de statusbalk of navigatiebalk.
Twee uitstekende hulpmiddelen om u op weg te helpen met het ontwerpen voor de iPhone X zijn de volgende WWDC-video's:
Optioneel | Lagere prioriteit
Een van de meest besproken nieuwe SDK's op de WWDC van dit jaar is slepen en neerzetten. Dit is iets wat desktopgebruikers al heel lang gewend zijn, maar door de afwezigheid op het iOS-platform hebben de iPad en iPhone nooit echt multi-tasking omarmd. In iOS 11 is dit veranderd, omdat de nieuwe iOS UI-elementen ondersteunt die niet alleen binnen hetzelfde scherm worden gesleept, maar van de ene applicatie naar de andere.
Door gebruik te maken van de multi-touch-engine van iOS, kunnen gebruikers moeiteloos inhoud op een natuurlijke manier verplaatsen tussen apps op de iPad (of gewoon binnen hetzelfde scherm op de iPhone) door een afbeelding, bestand, tekst of specifieke gebruikersinterface-element te slepen en vast te houden om te slepen het. Dit is al in het hele systeem geïntegreerd in iOS, waardoor gebruikers bijvoorbeeld tekst vanuit Safari naar de Herinnerings-app van het dock kunnen slepen om een nieuw herinneringsitem te maken.
Dit is niet als verplicht gemarkeerd voor implementatie, maar omdat het snel een te verwachten gedrag zal worden vanwege de prevalentie ervan, wordt gesuggereerd dat u dit eerder vroeger dan later probeert te prioriteren, zodat u de UX van uw app kunt maken voldoen aan het nieuwe UX-gedrag van het standaardsysteem.
UIKit wordt geleverd met ondersteuning voor slepen en neerzetten, voor componenten zoals UITables en UICollectionViews, maar je moet de elementen overbruggen en aanpassen met code, zodat andere componenten de gesleepte component kunnen ontvangen. Dit kan een beetje ingewikkeld zijn, en het valt buiten het bestek van dit artikel, maar ik zal ondersteuning voor drag & drop vollediger behandelen in een vervolgpost volgende week.
Voor nu, kort gezegd, zou je drag & drop in je toevoegen en ondersteunen ViewController's viewDidLoad () methode, door de twee afgevaardigden hieronder te implementeren:
class ViewController: UIViewController, UITableViewDataSource, UITableViewDelegate, UITableViewDropDelegate, UITableViewDragDelegate ... func viewDidLoad () ... firstTableView.dragDelegate = self // Je associeert de drag-delegate met deze table secondTableView.dropDelegate = self // Je associeert de drop-gedelegeerde met deze tabel firstTableView.dropDelegate = self secondTableView.dragDelegate = self firstTableView.dragInteractionEnabled = true secondTableView.dragInteractionEnabled = true ... ... func tableView (_ tableView: UITableView, itemsForBeginning session: UIDragSession, at indexPath: IndexPath) -> [UIDragItem] // ( 1) Slepen wordt gestart func tableView (_ tableView: UITableView, performDropWith coordinator: UITableViewDropCoordinator) // (2) Drop wordt gestart
Houd ons in de gaten voor ons aankomende artikel over het toevoegen van Drag-and-Drop-ondersteuning aan je iOS 11-app.
Optioneel | Lagere prioriteit
Laten we tot slot eens kijken naar de resterende UIKit-wijzigingen die nieuw zijn voor iOS 11, te beginnen met de UINavigationBar, die enkele opmerkelijke verbeteringen heeft, inclusief de integratie van SearchViewController en grote titels. Vervolgens bekijken we de verbeteringen aan UITableView, van de nieuwe en verbeterde veegacties tot tabelweergave cellen automatisch automatisch aanpassen.
We hebben al eerder navigatiebars aangeraakt bij het bespreken van de iPhone X en hoe deze is uitgelijnd met de nieuwe statusbalkdimensies. Daarnaast bevat de nieuwe eigentijdse ontwerpstijl waarvoor in iOS wordt gepleit nieuwe grotere titels in navigatiebalken, voor het eerst te zien in de Apple Music App in iOS 10 en sindsdien een vastgesteld ontwerppatroon voor alle andere systeem-apps in iOS..
De grotere titeltekst geeft meer nadruk op de context van het scherm in een navigatiebalk en helpt gebruikers te oriënteren op het actieve tabblad tijdens het navigeren door de verschillende tabbladen. De grootte van de titeltekst is niet statisch, maar krimpt eerder als de gebruiker naar beneden scrolt en teruggaat naar de pre-iOS 11-stijl. Omgekeerd zal, wanneer u in een scrolweergave naar beneden trekt, de titeltekst enigszins toenemen.
Gebruik een grote titel wanneer u extra nadruk op context moet geven. In sommige apps kan de grote, vetgedrukte tekst van een grote titel helpen mensen te oriënteren terwijl ze bladeren en zoeken. In een lay-out met tabbladen kunnen grote titels bijvoorbeeld helpen om het actieve tabblad te verduidelijken en de gebruiker te informeren wanneer ze naar de top zijn geschoven. Telefoon gebruikt deze aanpak, terwijl muziek grote titels gebruikt om inhoudsgebieden zoals albums, artiesten, afspeellijsten en radio te onderscheiden. Een grote titel gaat over naar een standaardtitel wanneer de gebruiker begint te scrollen. Grote titels zijn niet logisch in alle apps en mogen nooit concurreren met inhoud. Hoewel de Klok-app een indeling met tabbladen heeft, zijn grote titels niet nodig omdat elk tabblad een duidelijke, herkenbare lay-out heeft. (iOS Human Interface Guidelines))
Als ontwikkelaar is het aan jou om te beslissen of en wanneer je de grote tekststijl wilt implementeren, gebaseerd op de Human Interface Guidelines van Apple, en Apple beveelt je aan om de grote teksttitels alleen te gebruiken voor navigatieschermen op het hoogste niveau in plaats van alle niveaus. Als u grote tekst wilt inschakelen, voegt u eenvoudig de volgende eigenschap toe aan uw UINavigationController:
navigationController? .navigationBar.prefersLargeTitles = true
Hiërarchisch zullen zowel de hoofd- en detailweergavecontrollers onder de navigatiebalk de grote tekstmodus standaard hebben ingeschakeld vanwege oudervererving, en zoals zojuist vermeld, is het raadzaam om alleen de navigatieschermen op het hoogste niveau de grote tekstmodus te laten implementeren. Om de overerving van grote tekst in uw detailscherm te onderdrukken, gaat u naar uw weergaveregelaar en voegt u het volgende toe aan de initialisatie (deze moet worden ingesteld op initialisatietijd):
required init? (coder aDecoder: NSCoder) super.init (coder: aDecoder) navigationItem.largeTitleDisplayMode = .never
De largeTitleDisplayMode hierboven wordt ingesteld op .nooit. Zonder die regel is de standaardinstelling .automatisch, Dit is waar de detailaanzicht-controller de eigenschappen van zijn bovenliggende weergave-controller overerft.
Zoeken kan nu rechtstreeks in navigatiebalken worden geïntegreerd zonder de koppeling te hoeven maken UISearchViewController bijvoorbeeld met de subject view controller (en de tabelheaderweergave) afzonderlijk. Vanaf iOS 11 kun je de zoekbalk elegant inbedden in de navigatiebalk:
navigationItem.searchController = UISearchController (searchResultsController: nil)
U moet zich ook conformeren aan UISearchResultsUpdating om te reageren op zoektermen, natuurlijk. Terwijl iOS automatisch de zoekbalk verbergt op basis van het aantal rijen in uw tabelweergave, kunt u de zoekbalk te allen tijde zichtbaar maken door te schakelen tussen:
navigationItem.hidesSearchBarWhenScrolling = false
Ten slotte bekijken we twee nieuwe en onderscheidende functies die zijn geïntroduceerd in UITableViews vanaf iOS 11: automatische aanpassing en verbeterde veegacties. Self-sizing is al in iOS 8 geïntroduceerd om de last te verlichten van ontwikkelaars die tabelweergavecellen handmatig moeten aanpassen, met de mogelijkheid om de cellen dynamisch te laten passen op de inhoud van de rij met behulp van Auto Layout. Tot nu toe moest u expliciet om automatisch aanpassen vragen met behulp van:
tableView.rowHeight = UITableViewAutomaticDimension tableView.estimatedRowHeight = 100
Vanaf iOS 11 is het standaard ingeschakeld en ingesteld zonder extra code, maar je hebt nog steeds de mogelijkheid om, indien nodig, je eigen rijhoogte expliciet aan te geven. iOS 11 heeft ook nieuwe toonaangevende en trailing swipe-acties tot stand gebracht, die veel voorkomen in veel systeem-apps, zoals de eigen Mail-app van Apple.
Behalve dat u links of rechts kunt vegen, kunt u ook afbeeldingen toevoegen om aan deze acties te koppelen. U implementeert twee deelnemersmethodes als onderdeel van de UIContextualAction, voor toonaangevende en achterliggende veegacties:
override func tableView (_ tableView: UITableView, leadingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? let trash = UIContextualAction (style: .normal, title: "Delete") action, view, completionHandler in print ("Delete") completionHandler (true) delete.backgroundColor = UIColor.red delete.image = UIImage (named: "delete") laat actionGroup = UISwipeActionsConfiguration (acties: [delete]) actionGroup.performsFirstActionWithFullSwipe = false return actionGroup ... negeer func tableView (_ tableView: UITableView, leadingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? let archive = UIContextualAction (style: .normal, title: "Archive") action, view, completionHandler in print ("Read") completionHandler (true) archive.backgroundColor = blue archive.image = UIImage (named: "archive ") let move = UIContextualAction (style: .normal, title:" Move ") action, view, completionHandler in print (" Move ") completionHandler (true) move.backgroundColor = purple move.image = UIImage (named:" move ") laat actionGroup = UISwipeActionsConfiguration (acties: [archive, move]) actionGroup.performsFirstActionWithFullSwipe = false return actionGroupMet behulp van de bovenstaande code kunt u meer dan één contextuele actie maken en deze toevoegen aan de UISwipeActionsConfiguration groeperingsinstantie, voor meer dan één actie. Dit is een eenvoudige maar boeiende verbetering om een grotere elasticiteit in uw tabelaanzichten te krijgen, met minimale codewijzigingen, en hoewel het niet verplicht is, is het de moeite waard om er een paar uur aan toe te kennen in uw sprintplanningsbord.
In dit bericht heb ik je een overzicht gegeven van de veranderingen in de architectuur, de App Store en de visuele componenten van iOS 11, zodat je een idee hebt van wat je onmiddellijk moet doen en wat je later kunt uitstellen tijd. Migratie naar iOS 11 en Swift 4 zal een stuk eenvoudiger zijn dan in de updates van voorgaande jaren.
Naast de aanstaande veranderingen die moeten worden aangebracht, hebben we ook de Swift 4-wijzigingen doorgenomen die snaren en verzamelingen verbeteren, evenals de visuele verbeteringen aan UITableView en zoek controller. Dit zou het voor u eenvoudiger moeten maken om uw werk te plannen om uw app te updaten!
Blijf op de hoogte voor mijn aankomende bericht over het implementeren van slepen en neerzetten voor je iOS 11-apps, en bekijk in de tussentijd een aantal van onze andere berichten over nieuwe wijzigingen in iOS en Swift!
