Differenza tra framework e libreria statica in xcode4 e come chiamarli

133

Sono abbastanza nuovo per xcode e goal-c. Voglio fare una domanda molto semplice.

Ho visto che quando "collega i binari alle librerie" nelle impostazioni del progetto, ci sono differenze riguardo al framework e alle librerie, importate da altri progetti nell'area di lavoro.

Prima domanda, perché esiste un framework? E perché c'è una biblioteca? La mia libreria non può essere un framework?

E poi, da un file .h , come posso chiamare le classi dalla mia libreria statica importata?

Suppongo che ci debba essere un prefisso, ma non sono riuscito a trovarlo. Né "ProjName / Myclass.h" funzionano.

Per favore, sii il più specifico possibile.

Grazie

objective-c xcode4 static-libraries

— Leonardo
fonte

Non è una domanda di base

— Masih

Risposte:

140

Il più grande vantaggio di un framework rispetto alle librerie statiche è che agiscono come un modo pulito di impacchettare il binario della libreria compilata e tutte le intestazioni correlate. Possono essere inseriti nel tuo progetto (proprio come i framework integrati dell'SDK come Foundation e UIKit) e dovrebbero funzionare (la maggior parte delle volte).

La maggior parte dei framework contiene librerie dinamiche; i framework creati in Xcode utilizzando il modello Mac Framework creeranno una libreria dinamica. L'iPhone non supporta i framework dinamici, motivo per cui è diventato comune invece che le librerie riutilizzabili di codice iOS vengano distribuite come librerie statiche.

Le librerie statiche vanno bene, ma richiedono un po 'di lavoro extra da parte dell'utente. Devi collegare il tuo progetto alla libreria e devi copiare i file di intestazione nel tuo progetto o fare riferimento ad essi da qualche parte impostando i percorsi di ricerca dell'intestazione appropriati nelle impostazioni di compilazione.

Quindi: in sintesi, la mia opinione è che il modo migliore di distribuire la tua biblioteca sia come framework. Per creare un framework "statico" per iOS, puoi essenzialmente prendere un framework normale e sostituire il binario con la tua libreria statica compilata. Questo è il modo in cui distribuisco una delle mie librerie, Resty ed è così che intendo distribuire le mie librerie in futuro.

Potresti voler guardare il Rakefile fornito in quel progetto (nel caso in cui non sei a conoscenza, Rake è l'equivalente di Make di Ruby). Ho una manciata di compiti per compilare il mio progetto (usando xcodebuild) e confezionarli come framework statico per iOS. Dovresti trovarlo utile.

In alternativa, potresti voler utilizzare questi modelli Xcode 4 per creare un framework iOS.

Aggiornamento 9 dicembre 2013 : questa è una risposta popolare, quindi ho pensato di modificare per dire che la mia prima scelta per la distribuzione delle biblioteche è cambiata. La mia prima scelta per qualsiasi libreria di terze parti come consumatore o produttore è CocoaPods. Distribuisco le mie librerie utilizzando CocoaPods e offro una libreria statica precompilata con intestazioni come opzione di fallback.

— Luke Redpath
fonte

Quindi le librerie possono essere statiche e dinamiche, e i framework sono semplicemente un gruppo di librerie, che possono anche essere dinamiche o statiche, è questa la comprensione corretta?

— Tony

Sembra che la destinazione del framework Xcode ti permetta anche di copiare le intestazioni, ma non raggruppare le risorse. Le librerie statiche distribuite possono contenere anche intestazioni?

— Tony

Domanda di follow-up: importa se hai costruito un framework usando Debug o Distribution? Perché altrimenti la distribuzione ha un ingombro minore.

— Aldrich Co,

@ GoRoS sì; in effetti ho appena fatto un po 'di lavoro per un client rendendo disponibile il loro SDK privato usando CocoaPods. Il trucco è avere un repository pubblico con la libreria statica compilata, le intestazioni e il podspec che puntano a questo e un repository privato con la tua sorgente. Idealmente, avresti una sorta di CI / automazione per controllare il tuo repository privato, compilare e aggiornare il tuo repository pubblico, mantenendo i due sincronizzati. Utilizzare i tag per taggare le versioni con versione effettiva nel repository pubblico (e probabilmente anche nel repository privato, in modo da sapere quale sorgente di commit è stata utilizzata per creare la versione pubblica).

— Luke Redpath,

@LukeRedpath la tua soluzione con CI sembra abbastanza ideale ... conosci qualche buon articolo / blog con qualche tutorial su come configurarlo? Idealmente con Jenkins

— micromanc3r

fondamentalmente, i framework SONO librerie e forniscono un pratico meccanismo per lavorare con loro. Se guardi "dentro" un framework, è solo una directory che contiene una libreria statica e file di intestazione (in alcune strutture di cartelle con metadati).

Se si desidera creare il proprio framework, è necessario creare una "libreria statica" e comprimerla in un modo specifico. vedi questa domanda

In generale, i framwork su piattaforme vengono utilizzati per comportamenti riutilizzabili in cui si aggiunge il proprio codice "in un framework esistente". se si desidera avere alcune funzionalità specifiche, è possibile utilizzare una libreria (ad es. three20) e impacchettarla nell'app distribuibile

— Martin Ullrich
fonte

Si noti che non è necessario che un framework contenga una libreria statica. In effetti, su Mac OS X la maggior parte dei framework non contiene librerie statiche, ma contiene librerie dinamiche.

grazie è chiaro, ma come posso chiamare una classe in una libreria statica da un file .m? È sufficiente chiamare #import "MyClass.h", oltre ad aggiungere "binari di collegamento con le librerie"?

— Leonardo,

@Bavario hai ragione avrei dovuto scrivere solo "librerie" ^^; tuttavia, esiste quasi ogni framework senza librerie - nella maggior parte dei casi, si collega a un framework per la compilazione e la libreria è presente sul sistema di destinazione. questa è di nuovo questa cosa comportamento-funzionalità

— Martin Ullrich,

@Leonardo sì, in pratica è quello che devi fare. Assicurati solo che i file .h siano da qualche parte nel tuo percorso. Se hai il progetto XCode di libaray, puoi includere il progetto e il suo obiettivo come dipendenza in modo da ottenere più funzionalità di debug e i file .h sul tuo percorso

— Martin Ullrich

Sono confuso, ho pensato che la tua risposta fosse corretta, ma l'ho vista contrassegnata come "-1"?!?!?! In secondo luogo, la libreria fa parte di un'area di lavoro e correttamente collegata al progetto principale. Ma sto ancora ottenendo "classe non trovata" alla riga '#import "MyClass.h"' durante la creazione dell'applicazione. So che c'è un trucco per farlo funzionare.

— Leonardo