2015-11-17 13 views
9

Ho questo codice base che è Objective C e Swift mix. Alcuni luoghi Swift utilizza l'obiettivo e viceversa. Ho bisogno di creare un framework ora basato su questo codebase ma non voglio includere tutti i file ogg oggettivi nell'intestazione del mio ombrello. Ecco il mio problema:Intestazione ombrello pubblica e privata nell'obiettivo C

All'interno del mio framework devo ancora essere in grado di usare swift da objc e viceversa; ma non voglio esporre tutti quei file objc che vengono utilizzati internamente da classi veloci. L'intestazione del bridging non è consentita nei framework, quindi tutte le intestazioni necessarie per il rapido bisogno di andare nell'intestazione dell'ombrello.

Mi chiedo se sia possibile avere tutte le intestazioni objc necessarie per il codice swift interno in un file che sarebbe la mia private header di ombrello e tutti i file che ho bisogno di esporre andrebbero nell'intestazione dell'ombrello pubblico.

Qualche suggerimento?

+0

Ciao, @ puru020, hai trovato una soluzione per questo? Ho esattamente lo stesso problema e non riesco a trovare come risolverlo. Grazie. – Daniel

+0

Non ho. Non sembra esserci una soluzione. Quello che abbiamo deciso è di mantenere 2 sezioni nell'intestazione dell'ombrello per i file .h pubblici e privati. Una volta creato il framework, eseguiamo uno script che va ed elimina la sezione privata dell'intestazione dell'ombrello. – puru020

+0

Ieri ho cercato ore per trovare soluzioni a questo problema. Il problema principale è la restrizione di non essere in grado di utilizzare un'intestazione di bridging nei framework. Per il caso "private objc-header in Swift", mi sono imbattuto nella definizione di un modulo privato, una funzione CLANG. Sfortunatamente, questo sembra essere lì per esporre intestazioni private ad altri framework, piuttosto che usare intestazioni private di objc in Swift. Anche se credo che ci sia una ragione per i problemi, in quanto l'interoperabilità sembra essere importante per Apple. Gradirei una risposta chiarificatrice. –

risposta

0

Sto usando con successo moduli esplicitamente dichiarati come una soluzione di questo problema per il caso Objective-C -> Swift. Non ho separato la dichiarazione del modulo in una mappa di modulo privata separata ma ho dichiarato sia il modulo framework che un modulo esplicito all'interno della stessa modulemap a causa della preoccupazione sollevata in uno dei commenti alla domanda (non ero sicuro se o come è possibile utilizzare l'intestazione generata dalla mappa del modulo privato all'interno dello stesso framework).

Ecco un estratto del modulemap ho definito per il mio MPFoundation.framework, che include un modulo esplicito MPManuscriptCompiler_Protected che importa l'intestazione "MPManuscriptCompiler+Protected.h" che non è incluso nell'intestazione ombrello per il quadro:

framework module MPFoundation { 
    umbrella header "MPFoundation.h" 

    export * 
    module * { export * } 

    explicit module MPManuscriptCompiler_Protected { 
     header "MPManuscriptCompiler+Protected.h" 
     export * 
    } 
} 

ho quindi utilizzare questo modulo esplicita MPManuscriptCompiler_Protected nel mio sottoclasse Swift che è presente nello stesso quadro in questo modo:

import MPFoundation.MPManuscriptCompiler_Protected 

La mia soluzione è in realtà tecnicamente solo una soluzione: per farlo funzionare, "MPManuscriptCompiler+Protected.h" può essere contrassegnato come intestazione privata o di progetto nel framework, quindi non sarà visibile nell'intestazione dell'ombrello e non sarà disponibile per le importazioni basate sull'intestazione con il suo nome file. Quindi, questo funziona senza dover includere questa intestazione nell'intestazione dell'ombrello.

Tuttavia, il modulo creato in questo modo è esposto pubblicamente nel framework e disponibile per gli occhi che non dovrebbero vederlo. Non ho indagato ulteriormente perché in pratica questo risolve il problema abbastanza bene (sono ancora per colpire i problemi in cui avrei per caso importato quell'intestazione protetta dove non doveva essere importata).

+0

Questo impedisce al client del tuo framework di importare le tue classi private come nel modo in cui hai fatto? Questo è ciò che ha funzionato per me: https://github.com/danieleggert/mixed-swift-objc-framework – puru020

+0

Sort of: l'header stesso può effettivamente essere impostato come privato anziché pubblico (questo contraddice la mia risposta sopra - lo adatterà) ... quindi per le importazioni basate sull'intestazione non è disponibile. Tuttavia, come modulo è disponibile in questo modulo per i client esterni, che è stato accettabile per me poiché non ho avuto a che fare con una cartella separata e una mappa dei moduli separata e le chiavi di configurazione di build aggiuntive. La tua soluzione sembra però più corretta. – mz2

Problemi correlati