Czy istnieją najlepszych praktyk w zakresie sposobu organizowania własnego rozwiązania w XcodeJakie są najlepsze praktyki i wskazówki dotyczące organizacji rozwiązania Xcode?
To jest moje w tej chwili od korzenia:
Kopalnia jest:
Main application
Model
Singletons
Helper+managers
Controllers // I keep nibs with their respective class files
View
Resources
images
plists
// ... groups from other types of resources if needed
Supporting files
Unit tests
Frameworks
Dla kodu wielokrotnego użytku na iOS używam biblioteki statyczne i dodać je jako odrębnych projektów w przestrzeni roboczej Xcode. Nawet w przypadku kodu innej firmy, jeśli nie istnieje statyczny cel biblioteki, utworzę go. W ten sposób traktuję kod strony trzeciej w taki sam sposób, w jaki traktuję swój własny kod biblioteki. Co więcej, nie muszę się martwić wersjonowaniem kodu innej firmy.
Znalazłem, że ważne jest, aby Xcode odzwierciedlał organizację systemu plików kodu, przynajmniej do pewnego poziomu. Przyjąłem tę praktykę po przeczytaniu this blog post. Nie robię tego jednak poniżej poziomów wymienionych powyżej. Pomaga to na przykład przy udostępnianiu kodu na githubie. Zamiast pobierania lub przekazywania przez wszystkich swoich źródeł do jednego katalogu, jest on podzielony na funkcjonalne segmenty. Widziałem kilka projektów, w których organizacja Xcode jest w porządku, ale każdy pojedynczy plik źródłowy w systemie plików jest zrzucany do jednego katalogu.
Chociaż żaden szczególny sposób może być pozbawiony wad, o to co używamy
Folder dla rdzenia aplikacji lub modelu. Obejmuje to podfoldery dla wszystkich użytych bibliotek stron trzecich i foldery dla wyspecjalizowanych klas modelu . Na przykład będzie folder do obsługi serwisów internetowych.
Folder dla jednego głównego modułu, który będzie zawierać podfoldery dla każdego ekranu zawierającego pliki klasy, śruty i zasobów (może to kolejne podfoldery w zależności od potrzeb).
Folder dla drugiego głównego modułu i tak dalej ..
Model ten służy nam jeden główny cel. Nasz rdzeń aplikacji zawiera elementy takie jak rejestrowanie, szyfrowanie/odszyfrowywanie danych itp. Jest więc mało prawdopodobne, aby zostały zmienione dla wielu aplikacji, które rozwijamy. Podobnie byłoby kilka aplikacji, które wymagałyby funkcjonalności głównego modułu i dodawania innych rzeczy. Dlatego te trzy grupy folderów są utrzymywane jako oddzielne repozytoria w subwersji.
Teraz, gdy rozpoczynamy nowy projekt, tworzymy nowe repozytorium dla projektu i łączymy je z repozytorium rdzeni aplikacji i innymi repozytoriami dużych modułów w zależności od potrzeb. Zatem wszelkie zmiany wprowadzone w rdzeniu aplikacji przez jeden zespół projektowy znajdują odzwierciedlenie również w innych projektach. To samo dotyczy innych głównych modułów. Pomaga nam to również osiągnąć pełną modułowość.
Oczywiście nie byłoby wad tego programu, ale ten system dobrze nam pasuje od wielu lat :)