Лучший способ импортировать пачку или «систему» ​​новых классов?

Question

Вот расширенный вопрос для продвинутых разработчиков.

Итак, я написал большую "подсистему".По сути, это UIViewController, называемый CleverViewController, который является UIViewController.

В настоящее время существует большое количество вспомогательных классов (около десяти), которые выполняют тяжелую работу: выполняют математические функции, обработку изображений, чисто логические функции, создаютизображения или что у вас с тысячами строк кода.

(Чтобы сделать это, я просто запустил новый проект / приложение XCode "Scratchpad", который мало чем загружает и запускает CleverViewController. Так что в настоящее время он работаеткак приложение, которое запускает CleverViewController. Десять или около того классов, которые я упоминаю, являются частью «подсистемы», просто находятся там в этом проекте / приложении.)

Итак, теперь мы будем использовать CleverViewController, новую технологиюв общем, в разных приложениях.(Или, возможно, друзья захотят использовать его и т. Д.)

Какой лучший способ «сделать» это?Я все испортил, и действительно это должен быть ОДИН (довольно большой) класс, а не дюжина классов?(Я мог бы понять это тогда, поскольку я просто добавил бы этот новый (большой) класс, где это необходимо, как добавление любого другого класса.)

Должен ли я создать «каркас», подобный каркасам Apple?(Если так, то, что, черт возьми, они, как вы это делаете и т. Д.?!?)

На самом деле, вам просто нужно неуклюже включить все дюжины классов, и это всев сгруппированной подпапке).

А как насчет всех заголовков и так далее?(В настоящее время у меня просто дюжина включений в pch-файле проекта блокнота.)

Разве не должно быть легко "поддерживать" эту "подсистему" отдельно и т. Д.?

Боюсь, я ничего не знаю об этом: если ответ очевиден, ударь меня по голове и дай мне знать.

Спасибо за любую информацию по этому вопросу!

Мэтью, если вы видите это ... Я ищу вашу ссылку на Framework, я ее не видел.

Answer 1

в идеале вы должны создать динамическую библиотеку (которую фреймворк будет квалифицировать как).

, но Apple решила запретить это в iOS, поэтому лучший способ - использовать статическую библиотеку. затем вы создаете xcodeproj с этой библиотекой и распространяете его своим друзьям вместе с исходным кодом, чтобы они могли помочь в разработке;)

со статической библиотекой каждый исполняемый файл будет затем копировать код (путем статической ссылки) в свое приложение. в osx распространение классов objc - это кошмар (из-за плоского пространства имен при загрузке классов - вы получаете коллизии классов во время выполнения).

все, что клиент должен сделать, чтобы использовать эту библиотеку, это добавить xcodeproj библиотеки в свое приложение, настроить его как зависимость сборки, а затем связать. это довольно легко, если у вас есть навык.

если возможно, лучше написать их на c или c ++, потому что символы и зависимости objc не могут быть удалены из конечного исполняемого файла - если они используют только один класс в библиотеке, им все равно придется отправлять все классы.

удачи

EDIT

1) Что такое статическая | динамическая библиотека?

чтобы быть очень кратким в моем описании сложной темы: они многоразовые двоичные файлы. То, как они используются, связаны, объединены, загружены, зависит от типа изображения. По сути, вы создаете общую библиотеку, компилируя коллекцию исходных файлов, которая создает библиотеку. Затем вы просто связываете свое приложение с библиотекой. Это удобство в разработке программного обеспечения. Если вы не связали свое приложение с Foundation.framework, вам понадобится источник для NSString, чтобы использовать этот класс. Таким образом, это значительно упрощает разработку программного обеспечения, позволяя организовывать, разделять и повторно использовать программы. Это также полезно, потому что ваше приложение может быть улучшено, когда (например) Apple обновляет ОС (в свою очередь, обновляет фреймворки). Эти обновления изменяют выполнение вашей программы - как правило, в лучшую сторону, поскольку исправлены ошибки и сделаны улучшения производительности.

Для более подробной информации:

http://en.wikipedia.org/wiki/Static_library

http://en.wikipedia.org/wiki/Shared_library

2) Вы говорите "... создать xcodeproj с этой библиотекой ..." .. как мне создать "библиотеку"?

хорошо, процесс аналогичен для iOS, но вот как это сделать на OS X (я использую Xcode 3.2.x здесь):

• выберите пункт меню Файл> Новый проект
• в шаблоне выбора проекта выберите «Framework & Library»
• для каркаса выберите «Какао Каркас». обратите внимание, что фреймворку вообще не нужно использовать Какао, это может быть чистый C или C ++ - это всего лишь шаблон, и вы можете изменять настройки шаблона после сохранения вашего проекта.
• для статической библиотеки выберите «BSD C Library», затем «static» из всплывающего меню ниже
• для динамической библиотеки, выберите «BSD C Library», затем «dynamic» из всплывающего меню ниже

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

3) Когда вы говорите, что «распространение уроков - это кошмар», вы имеете в виду, например, если бы я буквально дал вам два текстовых файла "Soften.m" и "Soften.h" ..?

Что я имел в виду в этом случае: распространение разделяемых библиотек, имеющих классы или категории objc, является кошмаром - в некоторых контекстах. Проблема в том, что символы objc (любой определенный метод или класс objc) могут конфликтовать во время загрузки. Например, 2 отдельных класса из 2 отдельных общих библиотек будут конфликтовать при загрузке библиотек в программу.

Это не проблема со статическими библиотеками - потому что компоновщик будет прерван. Но это проблема динамической загрузки, потому что, скажем, у вас есть класс с именем QTCaptureConnection, и ваше приложение не ссылается на QTKit.framework (который также определяет этот класс objc). Если плагин вашего приложения или какая-либо библиотека, загруженная в исполняемый файл, ссылается на QTKit, то у вас возникнет конфликт загрузки objc.

Это означает, что будет загружен только один класс, и при сообщении будет возвращен один класс [[QTCaptureConnection alloc] init] - одна из двух зависимостей не будет возвращена ожидаемому классу.Это означает, что каждое имя класса и метод каждого двоичного образа, загруженного в исполняемый файл, должны быть уникальными.В большинстве случаев это вне вашего контроля.Наиболее очевидный случай - разработка плагинов.Если вы разрабатываете плагины, это также означает, что вы должны переименовывать каждый класс, повторно используемый каждым плагином, который вы распространяете, или распространять разделяемую библиотеку для разделяемых классов - что во многих случаях не вариант.

4) «... добавить xcodeproj библиотеки в их приложение» - как вы в буквальном смысле этого делаете?

вы перетаскиваете xcodeproj из Finder в открытый проект в Xcode, как вы это делаете сфайл заголовка (но вы не копируете файл или не добавляете его к цели).Затем Xcode обновляет ссылки, добавляет символы проекта (например, имена классов, функции), и вы сможете настроить цели проекта, которые вы перетаскивали, как зависимости, и сможете ссылаться на библиотеки проекта.

5) C / ++ понятен, но здесь неосуществим (я не думаю)

Это зависит от того, что делает библиотека.В конечном счете, нет функции c ++ или objc, которую нельзя аппроксимировать, используя только C.Оооо ... вы часто можете реализовать то, что вам нужно, используя C или C ++.Проблема выходит из-под контроля, потому что приложение может хотеть небольшую функцию из нескольких разных библиотек, в то время как каждая библиотека может иметь несколько МБ.так что все эти библиотеки могут добавить (в качестве примера) 20 МБ к конечному приложению.Если символы могут быть удалены, то клиент (используя библиотеку) будет платить только за то, что он / она назвал (в двоичном размере).Таким образом, 19 МБ неиспользуемого материала можно удалить из конечного приложения (и избежать множества других проблем).

6, что, черт возьми, являются «рамочными» вещами Apple (UIKit,CoreGraphics и т. Д.) - как это здесь уместится?

Одно из самых больших ограничений типичных разделяемых библиотек состоит в том, что они будут включать только одно двоичное изображение (только соответствующий код).Итак, люди придумали множество способов объединить другие вещи, которые они хотели / должны были распространить в двоичный файл, которые были зависимостями библиотеки.примеры включают графику / изображения или текстовые файлы.

фреймворки хороши тем, что они функционируют как динамические библиотеки, но они также являются структурами каталогов.используя каркас, вы можете просто скопировать изображение, pdf, nib-файл и т. д., которые используются библиотекой.

если вы используете статическую библиотеку, клиенту (повторному использованию библиотеки) придется вручнуюдобавьте каждый ресурс в фазу сборки файлов копирования своего приложения, убедитесь, что они существуют, и синхронизируйте их по мере того, как приложение и библиотеки становятся более зрелыми.с каркасом, многие из этих зависимостей удаляются.Взгляните на весь материал в /System/Library/Frameworks/AppKit.framework/ - он включает в себя двоичный файл (включая реализацию тонны классов objc), тонну локализованных изображений, nib-файлов, локализованных строковых файлов, заголовкафайлы и другие важные данные.