Включете библиотеки в проект за библиотека на iOS

Пиша библиотека за iOS, която зависи от някои други библиотеки с отворен код. Очевидно не е възможно да има два класа с едно и също име, така че е възможно библиотеката да се компилира и проект, който потенциално би могъл да я използва, също да се компилира, но те не работят добре заедно (на фазата на свързване).

Библиотеката е насочена към голяма аудитория, така че не мога да правя предположения дали тези разработчици ще импортират едни и същи библиотеки или не, или може да използват различна, несъвместима версия на същите библиотеки.

Разгледах наоколо, но не можах да намеря ясно решение на проблема си (може би няма). Засега се сещам за тези варианти:

  • Информирайте потребителите, че X библиотеките вече са включени в проекта, така че те не ги включват също. Това означава, че те не могат да използват различна версия на X библиотеки.
  • Като усъвършенствана версия на първия, използвайте CocoaPods, така че зависимостите да се разрешават автоматично. Все още има недостатъка, че две версии на библиотеката не могат да съществуват едновременно.
  • Импортиране и преименуване на всички класове, от които зависи библиотеката ми, като им поставя префикс, така че имената да не са в конфликт с оригиналните. Това е досадна работа, но по-важното е, че има недостатъка, че няма да мога да изтегля/бутам код от/към оригиналната библиотека, тъй като кодът ще се промени твърде много. Все още ми се струва най-добрият вариант от гледна точка на потребителя.

Сещате ли се за по-добра идея? Аз съм доста нов в библиотечните проекти, така че може би има нещо очевидно, което пропускам.

Все още не сме решили дали да разпространяваме в двоичен или изходен код. Ако има причина да избера едно или друго бих искал да чуя и вашето мнение.


xcode ios cocoapods
person gimix    schedule 24.01.2013    source източник
comment
мислите ли да разпространявате сорс или двоичен файл?   -  person hooleyhoop    schedule 25.01.2013
comment
Добавих това към описанието, благодаря hooleyhoop   -  person gimix    schedule 25.01.2013

Отговори (2)


arrow_upward
0
arrow_downward

Когато се сблъсках с този проблем, избрах третата ви опция и префиксирах зависимите класове в моята библиотека. Причината, поради която бихте могли да обмислите да направите това, вместо да разчитате на потребителя да импортира останалите, би била, че можете да гарантирате съвместимост и не е нужно да се притеснявате за версиите на кого разчитате.

person rooster117    schedule 24.01.2013
comment
В крайна сметка направих това, благодаря ви. Все още се чудя дали има по-добър вариант, но изглежда, че няма. - person gimix; 25.11.2017

arrow_upward
0
arrow_downward

Първа точка -

Информирайте потребителите, че X библиотеките вече са включени в проекта, така че те не ги включват също

така че имате статична библиотека Foolib.a, тя има зависимост от трета страна Barlib.a, за да може Foolib да изгражда, HEADER_SEARCH_PATHS на Foolib трябва да бъде настроен на пътя на Публичните заглавки на Barlib. Няма повече.

Ако разпространявате изходния си код, можете да използвате CocoaPods (това е добър начин) или можете да добавите хранилището на Barlib като git подмодул (или каквото и да е по ваш избор на VCS) на вашето хранилище и да кодирате твърдо HEADER_SEARCH_PATHS към него път или можете да изискате вашият потребител да грабне своя собствена Barlib и ръчно да редактира HEADER_SEARCH_PATHS до правилния път (ако отидете на маршрута на CocoaPods или подмодула, потребителят може лесно да направи и това, така че има повече опции).

Нищо от Barlib не е „във“ вашия проект.

От друга страна, ако разпространявате двоичен файл, за да може вашият потребител да се свърже с приложението си, трябва да посочите в инструкциите си, че Foolib изисква Barlib да бъде свързан с приложението. Инструкции за това как да се сдобия с Barlib биха били добри.

Нищо от Barlib не е „във“ вашия проект или компилирано във вашата библиотека.

Втора точка -

използвайте CocoaPods, така че зависимостите да се разрешават автоматично. Все още има недостатъка, че две версии на библиотеката не могат да съществуват едновременно

Две версии на една и съща библиотека в едно приложение са невъзможни, но ситуацията, при която крайният потребител вече изисква Barlib 3.0, иска да използва вашия Foolib, но Foolib изисква Barlib 4.0, не е необходимо да възникне - зависи от вас разработчика . Можете да бъдете щедри и да поддържате множество версии на Barlib (т.е. всичко, от което Foolib се нуждае, за да работи, е Barlib1.0, Barlib2.0, Barlib3.0 ИЛИ Barlib4.0, свързан в приложението - подобно на писането на приложение, което поддържа iOS5 и iOS6) или можете да бъдете самоуверени и да изисквате конкретна версия и ако потребителят вече изисква различна версия на Barlib, голям късмет, той ще трябва да промени кода си, ако иска да използва вашата библиотека.

Трета точка -

Импортирайте и преименувайте всички класове, от които зависи моята библиотека, поставяйки им префикс, така че имената да не са в конфликт с оригиналното

Това е твърде ужасно, за да го обмисля в момента. съжалявам

Нищо от Barlib никога не е „във“ вашия проект или компилирано във вашата библиотека. Вие не разпространявате каквото и да е копие на Barlib - нито свързано във вашия двоичен файл, нито като изходен код.

person hooleyhoop    schedule 24.01.2013