estáticos (iPhone) Las bibliotecas, distribución y dependencias

Question

(presumiblemente la siguiente pregunta no es iPhone específica, aparte del hecho de que probablemente usaríamos un marco o una biblioteca dinámica de lo contrario.)

Estoy construyendo un iPhone patentada SDK para un cliente, para integrarlo con su back-end web. Como no queremos distribuir el código fuente a los clientes, debemos distribuir el SDK como una biblioteca estática. Todo esto funciona bien, y he verificado que puedo vincular nuevas aplicaciones de iPhone a la biblioteca e instalarlas en el dispositivo.

Mi preocupación se centra en las bibliotecas de terceros de las que depende nuestro SDK. Por ejemplo, actualmente estamos usando HTTPRiot y Three20 (las bibliotecas exactas pueden cambiar, pero ese no es el punto). Me preocupa que esto pueda generar conflictos si los clientes también usan cualquiera de estas bibliotecas (y tal vez incluso versiones diferentes) en su aplicación.

¿Cuáles son las mejores prácticas al respecto? ¿Hay alguna manera de excluir los símbolos de las bibliotecas dependientes de nuestra propia biblioteca estática (en cuyo caso los clientes tendrían que vincular manualmente tanto a nuestro SDK como a HTTPRiot y Three20)? ¿O hay algún otro mecanismo establecido?

Estoy tratando de encontrar un equilibrio entre la facilidad de uso y la flexibilidad/compatibilidad. Lo ideal es que los clientes solo tengan que colocar nuestro propio SDK en su proyecto y realizar un número mínimo de cambios en la configuración de compilación, pero si lo hace más robusto, podría tener más sentido hacer que los clientes se vinculen a múltiples bibliotecas individualmente. O supongo que podríamos distribuir varias versiones del SDK, con y sin dependencias de terceros, para cubrir ambos casos.

espero que mis preguntas tienen sentido ... principalmente procedentes de un fondo de Ruby y Java, no he tenido que hacer frente a las bibliotecas compiladas (en el sentido tradicional) durante mucho tiempo ...;)

Answer 1

Si fuera yo, debería especificar exactamente qué versiones de esas bibliotecas de terceros mi biblioteca interactúa. Luego probaría en contra de ellos, los documentaría y probablemente entregaría con esas versiones particulares incluidas en el lanzamiento.

Dos cosas de las que me preocuparía:
-Me gustaría asegurarme de que "solo funciona" cuando mis clientes lo instalan.
-No me gustaría garantizar el soporte para futuras versiones arbitrarias de esas bibliotecas de terceros.

Está bien incluir un proceso para que el cliente se mueva a versiones más nuevas, pero si algo no funciona, esperaría que el cliente pague por ese trabajo de desarrollo como una mejora, en lugar de ser un error gratuito corregir (a menos que incluya eso en el acuerdo original de licencia/soporte).

En ese momento, se convierte en una cuestión de garantizar que sus versiones específicas de las bibliotecas de terceros puedan funcionar felizmente junto a cualquier otra cosa que el cliente necesite (en su caso, un back-end web). En mi experiencia, eso generalmente es una función de la biblioteca, p. algunos no están diseñados, por lo que pueden ejecutarse varias versiones una al lado de la otra.