statici (iPhone) biblioteche, la distribuzione, e le dipendenze

Question

(presumibilmente alla seguente domanda non è iPhone specifico, a parte il fatto che probabilmente useremmo un quadro o una libreria dinamica in altro modo.)

Sto costruendo un iPhone proprietaria SDK per un client, da integrare con il loro back-end web. Dato che non vogliamo distribuire il codice sorgente ai clienti, dobbiamo distribuire l'SDK come libreria statica. Funziona tutto bene e ho verificato che posso collegare nuove app per iPhone alla libreria e installarle sul dispositivo.

La mia preoccupazione riguarda le librerie di terze parti da cui dipende il nostro SDK. Ad esempio, attualmente stiamo usando HTTPRiot e Three20 (le librerie esatte possono cambiare, ma non è questo il punto). Sono preoccupato che questo possa causare conflitti se i clienti utilizzano anche una di queste librerie (e forse anche versioni diverse) nella loro app.

Quali sono le migliori pratiche intorno a questo? Esiste un modo per escludere i simboli delle librerie dipendenti dalla nostra libreria statica (nel qual caso i clienti dovrebbero collegarsi manualmente sia al nostro SDK che a HTTPRiot e Three20)? O c'è qualche altro meccanismo stabilito?

Sto cercando di trovare un equilibrio tra facilità d'uso e flessibilità/compatibilità. Idealmente, i clienti dovrebbero solo abbandonare il nostro SDK nel loro progetto e apportare un numero minimo di modifiche alle impostazioni di costruzione, ma se rende le cose più robuste, potrebbe avere più senso che i clienti si colleghino su più librerie individualmente. O suppongo che potremmo distribuire più versioni dell'SDK, con e senza dipendenze di terze parti, per coprire entrambi i casi.

spero che le mie domande hanno senso ... provenienti principalmente da un Ruby e Java fondo, non ho avuto a che fare con le librerie compilate (in senso tradizionale) per un lungo periodo ...;)

Answer 1

Se fossi in me specificherò esattamente quali versioni di quelle librerie di terze parti interagiscono con la mia libreria. Quindi testerei contro di loro, li documenterei e probabilmente li consegnerò con quelle particolari versioni incluse nel rilascio.

Due cose di cui mi preoccuperei:
-Io vorrei essere sicuro che "funzioni" solo quando i miei clienti lo installano.
- Non vorrei garantire il supporto per versioni future arbitrarie di quelle librerie di terze parti.

Va bene includere un processo per il cliente per passare a versioni più recenti, ma se qualcosa non funziona, mi aspetto che il cliente paghi per tale sviluppo un miglioramento, piuttosto che un bug gratuito correzione (a meno che non lo includa nella licenza originale/accordo di supporto).

A quel punto diventa un problema assicurarsi che le specifiche versioni delle librerie di terze parti possano funzionare felicemente insieme a qualsiasi altra cosa il cliente abbia bisogno (nel tuo caso un back-end web). Nella mia esperienza, di solito è una funzione della biblioteca, ad es. alcuni non sono progettati in modo che più versioni possano essere affiancate.