В реализации PROPERTY_IMP придётся на макросах приводить propertyName к setPropertyName, что не очень приятно. Зато в вашем решении проще поддержать скалярные типы.
А зачем макрос PROPERTY_DEF? Разве в нём не будет @property (attributes) type name?
Вы предлагаете написать #define generate_accessor(property_name) ... и добавлять его для каждого поля?
Решение рабочее, но:
нужно будет проделать чуть больше действий для добавления нового поля
подсветка синтаксиса при составлении и редактировании макросов осутствует
Оверхедом при использовании рантайма можно пренебречь, так как resolveMethodFor:selector: вызывается только при первом обращении к полю. Ошибки в именах методов в решении с рантаймом не возникают так как селектор передаётся в аргументе.
Если есть желание выйти в магазин приложений одним из первых, для разработки можно пользоваться симулятором. Подправить шероховатости после получения устройства будет быстрее, чем писать проект с нуля.
> Я не понял почему в DVURLAsset в init не сохраняется схема внутри, а просто затирается.
В конструктор AVURLAsset передаётся изменённая схема для того, чтобы ассет вызывал методы делегата, а не загружал данные своими силами. Оригинальная схема передаётся в DVAssetLoaderDelegate строкой ниже, там и используется.
> Мне не совсем понятно где кеширование происходит?
У DVURLAsset есть делегат. В него приходят данные, которые можно сохранить самостоятельно.
> Зачем у делегата делегат?
Когда ассет не может загрузить данные самостоятельно, он просит это сделать делегата. Как только он (делегат) закончил загрузку, он оповещает об этом свой делегат. Получается делегат делегата :)
Пожалуй, переименую его в observer.
You should not use +[NSURLProtocol registerClass:], as that
method will register your class with the default session rather
than with an instance of NSURLSession.
Я не думаю, что AVPlayer грузит данные через [NSURLSession defaultSession]. А в этом случае запросы в протокол приходить не будут, пока его не добавили в protocolClasses у сессии.
В реализации
PROPERTY_IMPпридётся на макросах приводитьpropertyNameкsetPropertyName, что не очень приятно. Зато в вашем решении проще поддержать скалярные типы.А зачем макрос
PROPERTY_DEF? Разве в нём не будет@property (attributes) type name?Вы предлагаете написать
#define generate_accessor(property_name) ...и добавлять его для каждого поля?Решение рабочее, но:
Оверхедом при использовании рантайма можно пренебречь, так как
resolveMethodFor:selector:вызывается только при первом обращении к полю. Ошибки в именах методов в решении с рантаймом не возникают так как селектор передаётся в аргументе.components.scheme = [DVAssetLoaderDelegate scheme];
if (self = [super initWithURL:[components URL] options:options]) {
DVAssetLoaderDelegate *resourceLoaderDelegate = [[DVAssetLoaderDelegate alloc] initWithURL:URL];
В нижней строке используется оригинальный URL, а не модифицированный.
> Сохранить да, но переиспользовать?
В следующий раз можно создавать AVURLAsset из локального URL.
В конструктор AVURLAsset передаётся изменённая схема для того, чтобы ассет вызывал методы делегата, а не загружал данные своими силами. Оригинальная схема передаётся в DVAssetLoaderDelegate строкой ниже, там и используется.
> Мне не совсем понятно где кеширование происходит?
У DVURLAsset есть делегат. В него приходят данные, которые можно сохранить самостоятельно.
> Зачем у делегата делегат?
Когда ассет не может загрузить данные самостоятельно, он просит это сделать делегата. Как только он (делегат) закончил загрузку, он оповещает об этом свой делегат. Получается делегат делегата :)
Пожалуй, переименую его в observer.
В хедере NSURLSession: