2017-01-02 12 views
5

Przez kilka miesięcy zrobiłem sobie przerwę od kodowania i wróciłem i odkryłem zmiany w CoreData z Xcode8/iOS10/macOS Sierra.Prawidłowy sposób aktualizacji projektu Objective C dla podstawowych danych Xcode 8 Zmiany podklasy NSManagedObject

Próbowałem zrozumieć moją nową generację podklasy NSManagedObject w Objective C, ale w Internecie jest bardzo mało. Mam kilka rzeczy, które trzeba wyjaśniające zanim zacznę rozbiór mój projekt i brudząc rzeczy całkowicie ale pierwszy, niektóre rzeczy odkryłem z wywiercenie, które mogą być przydatne dla innych tam ...

gdzie rzeczy to Automatycznie generowane pliki na żywo ukryte głęboko w folderze DerivedData. Spójrz na USER-> Library-> Developer-> Xcode-> DerivedData-> ProjectName-lotsOfRandomLetters-> Build, a następnie kontynuuj otwieranie folderów, aż znajdziesz DerivedSources-> CoreDataGenerated.

Automatycznie generowane pliki nie pojawiają się w folderze projektu lub w nawigatorze, chociaż w przypadku wystąpienia błędu w jednym Xcode wyświetli się źródło.

miejsca Xcode generuje

Istnieją trzy ustawienia Codegen - ręczny/brak klasy definicji, a kategoria/rozszerzeń.

Kiedy an podmioty Codegen jest ustawiony na ręczny/brak (który był stary zachowanie) tworzenie podklasę NSmanagedObject użyciu redaktora> Utwórz NSManagedObject Podklasa generuje 4 pliki wewnątrz projektu ...

Entity + CoreDataClass.h i Entity + CoreDataClass.m i Podmiot + CoreDataProperties.h i Entity + CoreDataProperties.m

(poprzednia wersja Xcode 7 generowane Entity.h, Entity.m, Entity + CoreDataProperties.h i plików Podmiot + CoreDataProperties.m)

Jeśli e koder ntity jest ustawiony na Class Definition, Xcode automatycznie generuje te same 4 pliki w folderze danych pochodnych - nie projekt, pliki te są następnie oznaczone komentarzem informującym, że nie wolno ich zmieniać.

Xcode generuje 2 pliki, jeśli koder jednostki jest ustawiony na kategorię/rozszerzenie. Pliki te są oznaczone komentarzem informującym o tym, aby ich nie zmieniać. Są ...

Podmiot + CoreDataProperties.h i Entity + CoreDataProperties.m

nich plik 2 spodziewa się Entity.h plik będzie w projekcie i pokaże błąd w Xcode jeśli nieobecny. To jest jeden raz, że będziesz mógł zobaczyć źródło jednego z tych plików w Xcode.

Co w tych plikach

przycisk + CoreDataProperties plików wydają się być takie same jak te generowane poprzednia wersja Xcode generowane pliki z wyjątkiem jednego dodatkowo. Zawierają wszystkie atrybuty/właściwości obiektu/NSmanagedObject i metody obsługi podmiotów, które mają relację jeden do wielu lub wiele do wielu. Nowy dodatek to metoda dla metody fetchRequest podklasującej nową metodę fetchRequest programu NSmanageObject.

Pytania

1) klasa Definicja teraz oczywiste i najlepszy wybór dla Codegen gdy nie masz żadnych dodatkowych właściwości/funkcjonalności dodać do podklasy NSManagedObject, ponieważ automatycznie aktualizuje pliki dla Ciebie (kiedy zapisujesz projekt za pomocą cmd-s)?

2) Nazewnictwo plików z + CoreDataClass jest zgodne z konwencją dla kategorii w klasie, co oznaczałoby, że powinna istnieć klasa, dla której ma być rozszerzeniem.

Czy mam rację, zakładając, że pliki Entity + CoreDateClass .h/m są prostym zamiennikiem starych plików Entity.h/m? i że w rzeczywistości nie jest to kategoria, pomimo nazwy pliku?

3) Dla nowych podklas NSManagedObject powinienem importować Entity + CoreDataClass.h zamiast Entity.h?

4) Jeżeli chcę, aby mój projekt czytelne usuwając większość moich plików podklasowymi NSManagedObject, mogę tylko usunąć pliki w Xcode i ustawić podmioty Codegen do klasy definicja lub ...

istnieje magia pod kaptur, który szuka podmiotu + CoreDataClass, gdy spróbujesz # importować entity.h, czy będę musiał przejść przez wszystkie odnośniki do #import entity.h i zmienić je na #import entity + CoreDataClass.h?

5) Czy mam rację, zakładając, że jeśli chcę podklasy NSManagedObject, w której chcę dodać właściwość i metodę, która powinna ustawić kodegenu na kategorię/rozszerzenie?

6) Jeśli wybiorę kategorię/rozszerzenie, muszę utworzyć własny plik podklasy NSmanagedObject, jego po prostu entity.h nie encja + CoreDataClass.h?

7) Jeśli entity + CoreDataClass.h jest nowym akceptowanym formatem nazewnictwa dla pliku entity.h, dlaczego wygenerowany plik kategorii/rozszerzenia szuka zwykłego pliku nazwa entity.h zamiast encji + plik CoreDataClass.h ? Czy to tylko sprzeczność dotycząca części Apples i coś, co powinienem zaakceptować, czy też brakuje mi czegoś, o czym powinienem wiedzieć?

Dziękuję.

+0

Znajdź odpowiedzi i link do odpowiedniego filmu WWDC [tutaj] (http://stackoverflow.com/a/39933534/1457385). – shallowThought

Odpowiedz

2

W porządku - sporo osób wyglądało i nie ma odpowiedzi, więc spróbuję odpowiedzieć sobie.

1) Tak - jeśli nie ma potrzeby dodawania dodatkowych właściwości/funkcjonalności do jednostki CoreData, należy przejść do definicji klasy. Tworzy to 4 pliki: Entity + CoreDataClass.h i Entity + CoreDataClass.m i Entity + CoreDataProperties.h oraz Entity + CoreDataProperties.m, ale nigdy nie zobaczysz ich, ponieważ są ukryte z dala od widoku wewnątrz folderu danych pochodnych. Jeśli chcesz sprawdzić nazwę atrybutu, możesz zajrzeć do głównego edytora danych, ponieważ nie będziesz mieć dostępu do tych plików.

2) Pliki Entity + CoreDateClass .h/m są prostym zamiennikiem starych plików Entity.h/m. Pomimo zastosowania konwencji nazewnictwa plików dla kategorii, nie są one kategoriami, nie pozwól, aby system nazewnictwa Apple wprowadzał Cię w błąd. Zajrzyj do pliku, a klasa jest zdefiniowana jako Entity not Entity + CoreDataClass.

3) Dla nowych podklas NSManagedObject (autogenerowanych z opcją "Definicja klasy") należy zaimportować element Entity + CoreDataClass.h zamiast Entity.h. W końcu "to importowany plik nie jest klasą zdefiniowaną w środku. Podczas korzystania z klasy jej tylko Entity not Entity + ...

4) Jeśli zdecydowałeś się zdeklopywać swój projekt, usuwając pliki podklasy NSManagedObject, a następnie zmieniając nazwy podmiotów na "Definicja klasy", będziesz musiał przejść przez projekt i zmienić wszystkie instrukcje importu, które się do niego odnoszą, dodając + CoreDataClass do nazwy pliku. Na szczęście nie jest to wielka sprawa, ponieważ Xcode i tak oznaczy je jako błędy, więc łatwo je znaleźć.

5) Tak - jeśli chcesz dodać właściwości lub funkcjonalność do podklasy NSManagedObject, użyj opcji "Kategoria/rozszerzenie" w kodeku.

6) Jeśli wybierzesz kategorię/rozszerzenie, musisz utworzyć własny plik podklasy NSmanagedObject, nazwij go Entity.h. NIE nadawaj nazwy Entity + CoreDataClass.h, ponieważ autogenerowany Entity + CoreDataProperty.h szuka importu pliku Entity.h.

7) Tak, to tylko nazwa niekonsekwencja ze strony Apple. Nie pozwól, by cię rzuciło, tak jak mnie.

I wreszcie, nie zapomnij ...

jeśli zejść trasę używając Codegen -> Kategoria/Extension, jeśli dodać dodatkowy relacji do podmiotu, trzeba będzie zaktualizować Entity .h plik. Na przykład, jeśli dodałeś relację do podklasy NSManagedObject o nazwie Car, musisz dodać @Class Car; do Entity.h.

Powiązane problemy