Szerintem iszonyatosan zavaró, hogy egy Controller osztályban View-val kapcsolatos kód van. A storyboard már csak azért is jó mert “kiszervezi” a view-val kapcsolatos kódot egy külön “modulba”. Senki sem akar mondjuk egy 300 soros controller osztályban egy 100soros részt ami csak annyit csinál, hogy kipakolja az összes view-t, és beállítja a constraint-okat, egyszerűen ennek nem ott van a helye. A storyboardot meg további részekre lehet bontani storyboard reference-ekkel, és xib fájlokkal.
De itt nincs a Controller osztályban View kódja. A View saját osztályában van a kódja.
Ugyanúgy egyébként, mint most, pl az UICollectionViewCell a megjelenítő, ha megírod a saját Cell osztály kódjában a megjelenés vezérlését, akkor az UICollectionView source delegate osztályban (Controller) a cell érték bekérésekor csak meg kell adni az alapértelmezett adatokat. És ugyanúgy ebben a Controllerben is felül tudtad írni a megjelenést utólag, tehát amit írsz zavaró dolgot, az korábban is így volt. Ugyanakkor itt is lehetőség volt arra, hogy át lehet adni azt az objektumot, ami alapján meg fog jelenni az adott Cell. Most ugyanúgy van ez. Legalábbis a Tutorialok alapján így látom.
Most megnéztem az Apple oldalán a tutorialt és tényleg. Bár azért majd szokni kell, és kiváncsi leszek, hogy bonyolultabb UI-t is érdemes lesz e majd vele csinálni, vagy inkább csak az ilyen alapabb tableview-s dolgoknál lesz majd nagy előny.
Nah, ez a kérdés foglalkoztat engem is leginkább! :)
Megnéztem egy rakás videót SwiftUI témával kapcsolatban, még van legalább kettő, amit nem láttam. Ami biztos, hogy meg fogom tanulni (amúgy nyilván), mert iszonyatosan megkönnyíti a munkát. Ugyanakkor a kérdés már csak az, hogy ténylegesen mikor is fogok vele kiadni alkalmazást? Mert csak az új rendszerektől lesz támogatott, ami szeptemberben jelenik meg. És még most is támogatom az iOS 10-et. Persze nem kizárt, hogy előbb-utóbb meg fogom vonni az iOS 10 támogatátást a közeljövőben (mondjuk szeptembertől…). Ez azt jelenti, hogy iOS 11 lesz a minimum akkor. Tehát ha ezt a tendenciát folytatjuk, akkor kb 2 év múlva lesz az, amikor már talán nem fogom támogatni a jelenlegi iOS 12-t (bár valőszínűbb, hogy egyszerre vonom meg majd az iOS 11 és iOS 12 támogatást…).
Emlékszem ugyanez volt a baj az On Deamand Resources-szal. Alig vártam, hogy megszüntessük az iOS 8 támogatást akkoriban.
Van 4 framework, amit én írtam. A framework importálva a B frameworkbe. C frameworkbe importálva az A és B frameworkök egyaránt. D frameworkbe pedig az A,B és C framework van importalva.
Amikor Debug móddal használom a frameworköket egy alkalmazással, akkor minden cache törlése után max 10 perc után tudom is tesztelni a programot. Archive készítésekor (Release) egy óra alatt sem fordul le a D framework. Az A, B, C frameworkök kb 1 perc alatt lefordulnak. Az Xcode alatt ligában csak azt látom, hogy melyik paranccsal fog elfutni a fordítás, de van valahol konkrét log, hogy éppen melyik fájlt fordítja?
Fordítsd le a frameworkoket külön, és az elkészült .framework fájlokat tedd be az embedded binaries alá. Amikor az “utolsó”-t fordítod, ami az összes többit tartalmazza, akkor már csak azt az egyet kell fordítania, a többi már ugye korábban megvan.
1 óra az amúgy, hogy jön össze? :)
Tegnap sikerült foglalkoznom a dologgal. Úgy néz ki valamilyen Xcode hiba lesz. Archíválás közben létrejött DerivedData mappában nem jönnek létre a lefordított fájlok annak az egy frameworknek. Nem emlékszem pontosan, kb 8-10 fájlt hoz létre a projektnek/framework (persze külön Build mappában), és ebben a mappában csak 4 fájl jött létre. Egyszerűen megakadt a fordítás. Ami érdekes, hogy egyetlen egy fájl frissül időnként, kb 5 percenként, viszont az a build mappán kívül esik.
Build Settingsnél ennél az egy frameworknél kikapcsoltam a swift optimalizálást. Speed-re volt állítva, próbáltam Size optimalizálást is. Lényeg, hogy miután kikapcsoltam, 1 perc alatt lefordult ez az egy framework.
Csak megjegyzés képpen, kb 4,5 óráig hagytam futni legutóbb és akkor untam meg.
Ja, persze nem írtam korábban, de próbáltam minden törlést: Teljes DerivedData mappát valamint a ~/Library/Caches mappán belül is töröltem az Xcode fájlokat. Meg mindenféle Clean parancsokat futtattam.
Nekem is majdnem ugyanilyen hibám volt. Az történt, hogy ha archiváltam a frameworkot, (ha nincs archiválva, akkor hiába teszed be a projektbe ami használni fogja, debugban működni fog, de az app store connect el fogja utasítani.), akkor egy üres mappát kaptam.
Nekem ezt úgy sikerült megoldani, hogy a Build Settings>Deployment>Skip Install-t NO-ra állítottam. De ez is valami bug lehet.
Igen, érdekes, hogy sok helyen olvastam ezt a megoldást. Persze próbáltam én is, de nekem ez nem segített.
Viszont a release verziót Carthage segítségével rakom össze. Az összes projektet szépen verziószámozom és mindig változtatom minden egyes projektben a Cartfileban a dependencyt. Lehet nekem emiatt nem volt gondom ezzel.
Az Xcode 12.3-at egy-két napja feltetettem, de ez a verzió bugos, nem tudom mennyi telepítés érintett, az enyém biztosan. Catalina a rendszerem. Konkrétan néhány percenként elkezd szivárványkarikázni és kb fél-egy percig mint ha le lenne fagyva. Így kb lehetetlen dolgozni. Állítólag az a megoldás, hogy az összes fizikai teszt eszköznél ki kell venni a pipát, hogy hálózaton keresztül elérje az Xcode. Az Apple Tv-met nem tudtam kivenni. Ugyanakkor egyelőre ignore-ba tettem (az összes eszközt), meglátjuk ez hatékony-e vagy sem. szerk.: ez sem segített. Konkrétran komment írása közben fagyott meg fél percre.
Itt írnak róla néhányan: https://developer.apple.com/forums/thread/669529
Az App Store-ban lévő 13.2 -es verzió hibás, elszáll nálam és sokaknál ezzel a hibával (ha swiftpm használatban van):
Internal error: missingPackageDescriptionModule
Szóval App Storeból ne frissítsetek. 3 órát telepítette nekem, most kezdhetem újra 
Itt a fórum téma róla: https://developer.apple.com/forums/thread/696504?page=4
Ezen belül megtalálható, hogy a developer oldalról kell letölteni az aktuális verziót. (ugyanúgy 13.2) Viszont a fórumban olvastam valakinek, hogy ez meg crashelt nála buildnél.
Most fedeztem fel, hogy az Xcode 13. verziótól van benne “vim” mód. Azaz a forrás fájlokat úgy lehet szerkeszteni, mint a vimben, már aki ezt szereti. Persze a kettőspont nem működik, a / simán a saját keresőjét nyitja meg. Szóval azért (nyilván) nem teljes értékű vim.