Quali sono le best practice e le linee guida dell'organizzazione della soluzione Xcode?

Question

Ci sono delle migliori pratiche per come organizzare la propria soluzione in Xcode

Questo è mio al momento dalla radice:

• una cartella per ogni quadro 3rd party per esempio KissXML
• Una cartella per la mia unità test
• Una cartella per quadri, i prodotti e le risorse
• Una cartella per MiaApp che ha sottocartelle per il modello, vista, di controllo, di database, file di supporto e di dominio.

Answer 1

mio è:

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 

Per il codice riutilizzabile su iOS Io uso le librerie statiche e aggiungere questi come progetti separati nello spazio di lavoro Xcode. Anche per il codice di terze parti, se non esiste un target di libreria statico, ne creo uno. In questo modo, considero il codice di terze parti allo stesso modo in cui tratto il mio codice libreria. Inoltre, non devo preoccuparmi della versione del codice di terze parti.

Ho trovato importante che Xcode rispecchi l'organizzazione del codice file del codice, almeno fino a un certo livello. Ho adottato questa pratica dopo aver letto this blog post. Non lo faccio sotto i livelli che ho elencato sopra, però. Questo aiuta quando condividi il codice su github, per esempio. Piuttosto che avere downloader o contributori devono scavare attraverso tutta la tua sorgente scaricata in una singola directory, è organizzata in bucket funzionali. Ho visto alcuni progetti in cui l'organizzazione Xcode è OK, ma ogni singolo file sorgente nel file system viene scaricato in una singola directory.

Answer 2

Anche se nessun metodo particolare, può essere privo di svantaggi, qui è quello che usiamo

1. Cartella per nucleo Application o modello. Ciò include sottocartelle per eventuali librerie di terze parti utilizzate e cartelle per classi specializzate modello . Ad esempio, ci sarebbe una cartella per la gestione del servizio web.

2. cartella per un modulo importante che includerebbe sotto-cartelle per ogni schermata contenente file di classe, pennini e le risorse (che possono comportare più sottocartelle secondo il bisogno).

3. Cartella per secondo modulo principale e così via ..

Questo modello ci serve uno scopo importante. Il nostro core dell'applicazione contiene elementi come la registrazione, la crittografia/decrittografia dei dati, ecc. Quindi è molto improbabile che venga modificato per molte applicazioni che sviluppiamo. Allo stesso modo ci sarebbero alcune applicazioni che avrebbero bisogno della funzionalità del modulo principale uno e aggiungere alcune altre cose. Pertanto questi tre gruppi di cartelle vengono mantenuti come repository separati nella subversion.

Ora, quando iniziamo un nuovo progetto, creiamo un nuovo repository per il progetto e lo colleghiamo al repository principale dell'applicazione e ad altri repository di moduli principali in base alle necessità. Quindi qualsiasi modifica apportata nel core dell'applicazione da un team di progetto si riflette anche in altri progetti. Lo stesso con altri moduli principali. Questo ci aiuta anche a raggiungere la completa modularità.

Ovviamente ci sarebbero degli svantaggi per questo schema, ma questo schema ci è adatto per molti anni :)