dipendenze di movimentazione per progetto iOS quadro

Question

Ho creato progetto iOS quadro con questo metodo: https://github.com/jverkoey/iOS-Framework

Opere abbastanza pulito, ma io sono un po 'confuso su come includere le biblioteche/quadri che sono necessari per il mio quadro di lavorare e, in particolare, come farlo in modo che nel caso un'app client di terze parti che utilizza il mio framework possa includere anche queste librerie senza conflitti.

Diciamo che il mio codice quadro ha bisogno di queste due cose:

• FacebookSDK.framework
• libFlurry.a

Il primo è un quadro di iOS. Quando lo aggiungo alla fase "Link Binary With Libraries" nel mio Framework e provo a compilare il progetto client che usa il mio framework il linker si lamenta dei simboli mancanti - Devo aggiungere FacebookSDK al progetto client che è fantastico: non c'è possibilità di conflitti se le app client vogliono usare Facebook.

Tuttavia, quando faccio lo stesso con la libreria statica Flurry, ricevo errori di simboli duplicati durante la compilazione del progetto client. Il che mi confonde un po ', perché FacebookSDK.framework non è solo una libreria statica pacchettizzata?

ukaszs-iMac:FacebookSDK.framework lukasz$ file Versions/A/FacebookSDK 
Versions/A/FacebookSDK: Mach-O universal binary with 3 architectures 
Versions/A/FacebookSDK (for architecture i386): current ar archive random library 
Versions/A/FacebookSDK (for architecture armv7): current ar archive random library 
Versions/A/FacebookSDK (for architecture cputype (12) cpusubtype (11)): current ar archive random library 

Quindi le mie domande sono:

1. perché una libreria incorporata nel quadro (come Facebook) non è legata al mio quadro del prodotto del progetto, mentre biblioteca incluso come .a file è?
2. come includere un file .a nel mio framework in modo che non generi errori di simboli duplicati quando l'app client che utilizza il framework richiede anche questa particolare libreria statica?

Answer 1

Per il caso d'uso che si sta descrivendo, è necessario collegarsi a queste librerie esterne dall'applicazione, NON dal proprio framework. Può essere uno o l'altro, ma non può essere entrambi.

Se si decide che queste dipendenze appartengono alla responsabilità dell'applicazione, le si rimuoverà da "Collega binari con librerie" e qualsiasi altra configurazione di collegamento esplicita e si dovrà semplicemente proiettare il progetto quadro con il percorso di questi framework e librerie quindi può trovare i simboli (ma non il collegamento con essi) al momento della compilazione (cioè il percorso delle librerie deve essere incluso LIBRARY_SEARCH_PATHS).

Answer 2

Non collegare nulla durante la creazione del framework, ma creare un binario *.a con gli oggetti del framework.

Inoltre, non è necessario includere codice da altre librerie nel framework poiché le applicazioni client potrebbero aggiungere direttamente le stesse librerie o richiedere versioni diverse di esse, creando così conflitti.

Ovviamente è possibile fare riferimento ai file di intestazione *.h da altre librerie nel framework per compilare gli oggetti.

Come risultato, i passaggi di installazione per il framework devono dettagliare altri framework/librerie necessari, le relative versioni supportate, come aggiungere file di risorse (se presenti), ecc. Solo alcuni dei molti motivi per cui è possibile prendere in considerazione Creare invece un CocoaPods 'podspec.

Answer 3

1. Utilizzare cocoapods, è facile (http://cocoapods.org/)

2. I suoi sviluppatori di applicazioni dovranno includere il podfile e scaricare le dipendenze.

3. Durante lo sviluppo dell'SDK utilizzare un'applicazione di applicazione/demo di riferimento sopra SDK per simulare questo.

Answer 4

Utilizzare il responsabile delle dipendenze di CocoaPods. Ecco una buona guida,

7 miniute video tutorial

Answer 5

Si dovrebbe usare CocoaPods. La tua dipendenza da Facebook può essere fatta collegando il CocoaPod.

Se si desidera includere quella versione specifica di Facebook nel pod, è possibile inserirla nel repository e utilizzare la proprietà vendored_frameworks per fare riferimento ad essa.

Analogamente, se si desidera distribuire libFlurry.a, è possibile farlo utilizzando s.vendored_libraries.

Per le librerie di sistema, non è necessario venderle, ad es. libZ.a.

Si consiglia vivamente di creare il proprio CocoaPod utilizzando pod lib create YourPodName. Hanno recentemente cambiato il meccanismo per come funziona ed è davvero bello.

È possibile creare un progetto di esempio che mostra come utilizzare il codice nel contesto di un'app.

Quindi una delle altre cose belle che ho appena imparato, qualcuno può fare pod try YourPodName e automaticamente scaricherà, integrerà ed eseguirà il progetto Xcode.

CocoaPods vale la pena.

Answer 6

Principalmente se si installano framework di terze parti che è possibile installare con cocoapods (che è davvero bello, lo farei sicuramente) o che offrono di scaricare il framework e includerlo nel progetto. Se si decide di scaricare la libreria e includerla, normalmente nella guida "Guida introduttiva" è disponibile un elenco di framework.

Mezzi: offri loro l'installazione usando cocoapods e per scaricare la tua libreria ma non includono altro, dai loro un elenco di cosa hanno bisogno.

Answer 7

Sto costruendo il mio progetto quadro usando CocoaPods. Il framework utilizza alcune terze librerie di CocoaPods. Podfile specifica di installare la dipendenza sulla destinazione del framework. Quando costruisco il framework, include tutte le librerie nel binario.

Se aggiungo use_frameworks! in Podfile, quando il framework è costruito, non includerà le librerie di terze parti.