paint-brush
Si të ndërtoni projektin tuaj Xcode për platforma të shumta në të gjithë ekosistemin e Applenga@darrylbayliss
165 lexime Histori e re

Si të ndërtoni projektin tuaj Xcode për platforma të shumta në të gjithë ekosistemin e Apple

nga Darryl Bayliss9m2025/02/12
Read on Terminal Reader

Shume gjate; Te lexosh

Mësoni se si të ndërtoni Projektin tuaj Xcode për platforma të shumta në të gjithë ekosistemin Apple.
featured image - Si të ndërtoni projektin tuaj Xcode për platforma të shumta në të gjithë ekosistemin e Apple
Darryl Bayliss HackerNoon profile picture
0-item
1-item

Në qershor 2023, ndërsa Apple njoftoi Vision Pro, pata një ide që mund të funksiononte mirë në kufje - një koleksion videosh të lakuara që luhen së bashku me përdorimin tuaj të përditshëm. Unë kisha tashmë një aplikacion që mund ta bënte këtë të quajtur Christmas Chill , diçka që e ndërtova kur u vu në dispozicion Apple TV i parë që mbështet një App Store. Ai përmban një koleksion videosh të ndara që mund t'i përdorni si një sfond festiv.


Çdo vit gjatë dimrit, kaloj disa ditë duke e përmirësuar atë, duke shtuar përmbajtje të re dhe duke përmirësuar bazën e kodeve. Një nga ndryshimet më të mëdha të bëra në projekt erdhi në dhjetor 2023, kur UI u migrua nga UIKit dhe Storyboards në SwiftUI.


Epo, kryesisht migruan. Më duhej një pamje e mbështetur nga AVPlayer e mbështjellë në një UIViewRepresentable . Një API e shkëlqyeshme që ofron ndërveprim midis UIKit dhe SwiftUI, nëse keni ndonjëherë nevojë.


Kisha hezituar disi të migroja më shpejt pasi kisha një kuptim të mirë të UI deklarative dhe konceptet e saj nga punët e tjera me React dhe Jetpack Compose . Kjo ndryshoi për mua me prezantimin nga Apple të Apple Vision Pro dhe mbështetjen e tij për SwiftUI. Christmas Chill ka qenë një projekt i këndshëm për të mbajtur të përditësuara njohuritë e mia të Apple Dev dhe unë isha i prirur të fitoja përvojë duke zgjeruar aplikacionin në pajisje të ndryshme.


Pasi përfundoi migrimi i vitit 2023 në SwiftUI për Chill-in e Krishtlindjeve, u nisa në vitin 2024 për të shtuar mbështetjen për Vision Pro. Më poshtë është se si shkova për këtë dhe çfarë ju rekomandoj nëse po përpiqeni të bëni të njëjtën gjë për aplikacionet tuaja.

Shtimi i një platforme të re

Për të filluar, projekti duhet të jetë në gjendje të ndërtojë për Vision Pro si një destinacion; ta bësh këtë është çuditërisht e lehtë! Brenda Xcode, zgjidhni skedarin .xcodeproj dhe në menynë rënëse Destinacionet e Mbështetura , klikoni butonin plus.


Destinacionet e mbështetura



Shfaqet një listë e të gjitha platformave të disponueshme të Apple. Zhvendosni mbi platformën e dëshiruar për të shtuar si destinacion, në këtë rast, Apple Vision, dhe më pas klikoni Apple Vision në seksionin e sapo shfaqur.


Shto Destinacionin e Apple Vision Pro



Do të shfaqet një dritare e vogël për t'ju informuar për ndryshimet që Xcode duhet të bëjë në objektiv. Klikoni Aktivizo .


Aktivizo mbështetjen e destinacionit


Më pas, ndërtoni aplikacionin duke përdorur Simulatorin visionOS. Nëse keni në dorë një Vision Pro, mund të gjeni udhëzime se si ta instaloni atë në pajisjen tuaj këtu .


Gjatë përpilimit, ka të ngjarë që Xcode të gjejë gabime të përpiluesit dhe/ose aplikacioni të rrëzohet. Kjo është e pritshme dhe një praktikë e durimit. Nga kjo pikë, ju duhet të rregulloni gabimet në projektin tuaj derisa aplikacioni të kompilohet dhe të mos rrëzohet më.


Në rastin tim, kjo zgjati rreth 30 minuta, pjesërisht falë punës së vështirë të migrimit të aplikacionit nga UIKit në SwiftUI më parë!

Blloqe të përpilimit të kushtëzuar

SwiftUI, në thelbin e tij, është një kuadër multiplatformësh, që do të thotë se vetëm duke përpiluar kodin SwiftUI për një platformë tjetër, ai do të ndryshojë pamjen e tij. Duke marrë parasysh stilin e platformës dhe metodat e ndryshme të ndërveprimit.


Ndërsa kjo ndihmon për të bërë përparim të shpejtë gjatë zhvillimit, ju mund të dëshironi më shumë kontroll mbi mënyrën se si shfaqet aplikacioni dhe të përfitoni nga pikat e forta të secilës platformë individuale. Një shembull i mirë janë aftësitë e zhytjes së Vision Pro; SwiftUI ofron një API për këtë nëpërmjet ImmersiveSpace , një API e disponueshme vetëm për visionOS.


Nëse jeni përpjekur të përdorni këtë API gjatë përpilimit të projektit për Apple TV, Xcode do të shfaqë një gabim duke informuar se kjo API nuk është e disponueshme.


Pra, cila është zgjidhja për të shmangur këtë situatë? Përgjigja vjen nga përdorimi i blloqeve të përpilimit të kushtëzuar . Blloqet e përpilimit janë seksione të kodit që ofrojnë udhëzime se kur përpiluesi duhet të përpilojë kodin brenda bllokut.


Ndërsa ata mbështesin një sërë kushtesh, gjëja më e dobishme për nevojat tona është të zbulojmë se për cilën platformë po përpilohet kodi. Ju mund ta bëni këtë me vetëm disa rreshta kodi:


 var body: some Scene { #if os(tvOS) WindowGroup { HStack { Text("I am running on tvOS!") } } #elseif os(visionOS) ImmersiveSpace(id: "MyImmersiveSpace") { } #endif }


Një veçori e bukur që Xcode bën për të mbështetur blloqet e kompilimit të kushtëzuar është të bëjë të qartë se çfarë kodi do të përpilohet në varësi të platformës së zgjedhur për përpilim. Gjithashtu do të zbehet pak kodi që nuk do të përpilohet.


Blloqe të përpilimit të kushtëzuar

Injektimi i varësisë përmes fazave të ndërtimit

Një nga truket më të dobishme që kam gjetur është përdorimi i fazave të ndërtimit të Burimeve të Përpilimit dhe Burimeve të Kopjimit si një formë e injektimit të varësisë. Këto procese funksionojnë kur ndërtohet aplikacioni dhe mund të gjenden nën skedën e Fazave të Ndërtimit në Projektin Xcode.


Ndërtimi i fazave


Përpilimi i Burimeve bën vështirësinë e përpilimit të kodit tuaj burimor në kodin e makinës. Pavarësisht nëse është Swift, Objective-C, apo edhe C/C++.

Copy Bundle Resources kopjon të gjitha burimet e lidhura për objektivin e aplikacionit në paketën e aplikacionit . Një lloj kontejneri për të gjithë kodin dhe burimet e aplikacionit, duke përfshirë imazhe, video, vargje të lokalizueshme dhe më shumë.


Këto dy faza të ndërtimit u japin shumë fleksibilitet aplikacioneve pasi çdo objektiv i ri ofron fazat e veta të ndërtimit, duke përfshirë dy hapat e mësipërm. Aplikacionet Whitelabel që ofrojnë një mënyrë për bizneset për të personalizuar përmbajtjen e tyre përdorin këtë teknikë, ndër të tjera.


Ju mund të gjeni se dëshironi të ofroni përmbajtje të ndryshme për aplikacionet tuaja, në varësi të platformës në të cilën ato funksionojnë. Le t'i përdorim këto faza të ndërtimit në avantazhin tonë dhe të ofrojmë dy burime të ndryshme të përmbajtjes për ta bërë këtë.


Së pari, le të përdorim njëProtokoll Swift për të siguruar një kontratë që pret të përmbushet nga një strukturë ose klasë.


 protocol ContentManager { var content: [Content] { get } }


Më pas, le të hedhim një vështrim në dy zbatues të protokollit. Këtu është e para:


 class TargetAppAContentManager : ContentManager { var content: [Content] { return [ Content(name: TargetAppAContentIdentifier.videoOneName.rawValue, image: TargetAppAImagePreviewIdentifier.videoOnePreview.rawValue, video: TargetAppAImageVideoIdentifier.videoOneVideo.rawValue), Content(name: TargetAppAContentIdentifier.videoTwoName.rawValue, image: TargetAppAImagePreviewIdentifier.videoTwoPreview.rawValue, video: TargetAppAImageVideoIdentifier.videoTwoVideo.rawValue), Content(name: TargetAppAContentIdentifier.videoThreeName.rawValue, image: TargetAppAImagePreviewIdentifier.videoThreePreview.rawValue, video: TargetAppAImageVideoIdentifier.videoThreeVideo.rawValue), ] return contentToShow } }


TargetAppAContentManager është zbatimi konkret i përdorur për objektivin e parë të aplikacionit. Ai siguron një grup Content , i cili i referohet emrave të burimeve që gjenden në paketën e aplikacionit për objektivin.


 class TargetAppBContentManager : ContentManager { var content: [Content] { return [ Content(name: TargetAppBContentIdentifier.videoOneName.rawValue, image: TargetAppBImagePreviewIdentifier.videoOnePreview.rawValue, video: TargetAppBImageVideoIdentifier.videoOneVideo.rawValue), Content(name: TargetAppBContentIdentifier.videoTwoName.rawValue, image: TargetAppBImagePreviewIdentifier.videoTwoPreview.rawValue, video: TargetAppBImageVideoIdentifier.videoTwoVideo.rawValue), Content(name: TargetAppBContentIdentifier.videoThreeName.rawValue, image: TargetAppBImagePreviewIdentifier.videoThreePreview.rawValue, video: TargetAppBImageVideoIdentifier.videoThreeVideo.rawValue), ] } }


Tjetra është TargetAppBContentManager , zbatimi konkret i përdorur për objektivin e dytë të aplikacionit. Duket shumë e ngjashme me zbatimin e parë, përveç aplikacionit B, identifikuesit janë të ndryshëm.


Me të dyja implementimet e krijuara, tani mund t'u referoheni atyre në mënyrë indirekte në kodin tuaj duke vendosur llojin e objektit në ContentManager . Shikoni shembullin ViewModel më poshtë:


 @Observable class VideoListViewModel { var contentManager: ContentManager init(contentManager: ContentManager) { self.contentManager = contentManager } }


ViewModel pret që një lloj ContentManager të kalojë përmes iniciatorit të tij. ViewModel mund të kalohet nga secili lloj i ContentManager dhe të vazhdojë të funksionojë siç pritej. Kjo gjithashtu do të thotë që ViewModel mund të ripërdoret në të dy objektivat e aplikacionit.


Gjëja e fundit që duhet bërë është të siguroheni që Menaxher i saktë i Përmbajtjes të shtohet në fazën e Përpilimit të Burimeve. Në këtë rast, aplikacionit A i kalon TargetAppAContentMananger si pjesë e burimeve të tij dhe aplikacionit B i kalon TargetAppBContentManager .


Shto menaxherin e përmbajtjes në fazën e ndërtimit të përpilimit të burimeve

Shtimi i burimeve të paketës së aplikacionit

Gjëja e fundit që mbetet për të bërë është të siguroheni që çdo paketë aplikacioni të përmbajë burime me emra që përputhen me identifikuesit e përdorur nga aplikacioni. Mënyra më e lehtë është të kontrolloni fazën e ndërtimit të Copy Bundle Resources të çdo objektivi të aplikacionit dhe të siguroheni që burimet të referohen nga menaxheri i përmbajtjes. Nëse jo, atëherë tërhiqni ato nga projekti juaj Xcode në fazën e burimeve të kopjimit.


Kjo kërkon pak kohë dhe kujdes për t'u testuar, pasi nuk merrni një gabim në kohën e përpilimit nëse një burim i referuar nuk është i disponueshëm në paketë. Gjatë ekzekutimit, do të keni një përplasje!


Një mënyrë e mirë për të automatizuar kontrollin është të shkruani një test njësie për të konfirmuar që të gjitha burimet që i referohen nga ContentManager janë të ruajtura në paketë. Nëse testi dështon kur ekzekutohet, atëherë e dini që mungon një burim në paketë.

Ku të shkoni më tej?

Nëse keni arritur deri këtu, duhet të keni një ide të mirë se si ta sillni aplikacionin tuaj në platformat e tjera të Apple.


Për të përmbyllur këtë postim, unë do t'ju lë me disa këshilla dhe burime që rekomandoj:


  1. Nëse shtoni mbështetjen e Apple Vision në një aplikacion ekzistues, fillimisht migroni sa më shumë nga kodi juaj nga UIKit në SwiftUI. Pasi të keni parë shpejtësinë e një aplikacioni ekzistues që punon në Vision Pro kur migrohet në SwiftUI, është e dobishme të jeni në gjendje të mbështeteni.


  2. Lexoni udhëzimet e Apple për sjelljen e aplikacioneve ekzistuese në visionOS . Ai ofron këshilla dhe sugjerime të dobishme se si ta bëni atë dhe si të përfitoni nga veçoritë e visionOS.


  3. Nëse po mendoni të filloni vetë një aplikacion të ri multiplatformë, ekziston një skedë Multiplatform i disponueshëm në Xcode, që ofron një numër modelesh aplikacionesh për t'u përdorur. Ekziston edhe një video nga WWDC 2022 mbi këtë temë.


  4. Nëse dëshironi të shihni shembuj të aplikacioneve që funksionojnë nëpër platforma të shumta, ju rekomandoj të shikoni aplikacionet e mia personale Christmas Chill dhe Ocean Chill . Këto janë dy aplikacione që punojnë në tvOS dhe Vision Pro, të ndërtuara nga një bazë e vetme kodi. (Mbështetja tvOS për Ocean Chill vjen së shpejti!)