А куда более низкоуровневей? бэкинг-стор у CALAyer — это ни что иное как память видеокарты, ты веделяешь себе кусок и все операции происходят не в CPU, а в GPU с помощью конвеера.
Другой вопрос, что тут для эффектов испольузется блжндинг двух буферов, и для этого нужно иметь доступ к обоим бУферам. Поэтому мне кажется проблема состоит в том, что:
— с соображений безопасности
— не унифицировали API, поэтому не могут еще гарантировать обратой совместимости
— вообще решили, что не нужно это разработчикам.
CAFilter нельзя использовать, картинку из UIView получить — тривиальная задача, она всегда доступная через бэкинг стор у Layer этого вью.
Они не такие и медленные, долго создается контекст, если держать один контекст во время операции динамического размытия, то всё будет ок.
А почему-бы не использовать для этого CIFilter (CIGaussianBlur), он немного медленнее, но зато встроенный родной и стандартный.
А вот кстати хорошая статья на сравнение разных подходов.
А тут наглядная демонстрация встроенных фильтров.
да — это недостатки ручного управления пакетами. Найти исходники можно по названию классов. Не автоматизировано, но всё-же.
Если наколбашего в стороннем коде и это сделано правильно и с пользой — то нужно заливать в «общаг». Если разработчик этого не сделал — это плохо. Если решение специфичное только для этой задачи, то в Objective-C есть много способов сделать это без вмешательства в сторонний код (категории, наследование например).
В общем любой метод правильный, если использован правильно. И об этом нужно рассказывать новичкам.
Так как я в год разных приложений делаю с десяток, и практически у всех у них поддержка очень вялая (пара правок в месяц в самом лучшем случае или вообще ничего), то самый лучший подход — это ручное управление.
А то, что вы делаете — это особо не отличается от ручного подхода. Cocoapods вы используете только для ускорения процесса загрузки компонент, насколько я понял. В процессе разрабтки вы же не обновляете пакеты?
При обновлении нужно иметь хорошее покрытие тестами, чтоб быть увереным, что ничего не поломалось. Ведь сторонние пакеты практически не гарантируют обратную совместимость.
И обновлять пакеты имеет смысл, когда работа над проектом ведется очень долго: одна команда — один продукт. И обновление пакетов в этом случае должа быть целая отдельная итерация разработки со всеми циклами тестирования.
А у ручного подхода есть еще достоинства — есть возможность три раза подумать, а действительно ли этот компонент тут нужен?
Я нигде не говорил, что cocoapods — это плохо. Я просто хотел сказать, что нужно кроме достоинств говорить и о недостатках, особенно начинающим разработчикам. Так как они очень доверчиво относятся к тому, что им говорят учителя/наставники. Так проще не утонуть в куче новых знаний. И таким образом рождаются стереотипы.
«не стал бы настоятельно рекомендовать» — это не тоже самое, что «настоятельно бы не рекомендовал».
Тут в советах его настоятельно рекомендуют, вот я бы не стал этого делать :-) Так, что я не категоричен, я не очень ясно выразился.
cocoapods я бы не стал настоятельно рекомендовать, особенно начинающим разработчикам.
В таком пакетном подходе есть достаточно весомые недостатки:
— зависимость от сервера
— зависимость от репозитория, на который указывает пакет.
Например был у вас проект, вы его сделали и он себе работает. Вы его положили к себе в репозиторий и занялись другими проектами. Но через год вышел iOS7 и нужно что-то поменять в проекте. Вы спокойно выгружаете свой проект и бац: нужной версии нет в репозитории, владелец переехал со своими исходниками с гитхаба на битбукет, но в cocoapods этого не поменяли. Или вообще удалил свои исходники.
Ну и перестал работать cocoapods вдруг (есть такая вероятность, всё не вечно) и все ваши проекты стали сиротами. И ищи по интернету все зависимости по всем проектам. И хорошо, если найдется.
Не раскрыто, почему это удобней, чем реализовать например у синглота метод sharedInstance, где с помощью dispatch_once будет по требованию создаваться один экземпляр. А для тестов(если для тестов нужна другая инициализация) либо сделать sharedInstanceTest, либо закрыть инициализацю с помощью директив препроцессора и котролировать это конфигурациями сборки (хотя не очень элегантный вариант).
В общем не очень убедительно.
Я иногда вижу ваши статьи, но не очень старательно за ними слежу, поэтому может вы уже писали об этом. Но интересно, вы сам PVS-Studio анализировали? Есть ошибки?
По опыту использования Air2012, использовал для разработки.
Так вот 4Гб вообще за глаза хватает. По крайней мере до этого была прошка 15 с 8 гигами и ощущения такие-же.
Я не знаю за счет чего, то-ли умных мезанизм подкачки на SSD, то-ли еще чего.
Щас ретина 16 Гб, но думаю это лишнее. 8 Гигов за глаза практически любому пользователю.
По английски курс выглядит более лояльно:
«Программирование под Андроид для занятых разработчиков», а не для лентяев :-) А так вообще наличие таких курсов всегда полезно и нужно.
это почему?
Google Chrome на iOS использует Blink, Opera старая на iOS использовала Presto, я (и уверен, что не только я) в нескольких проектах использовать Gecko, HTMLayout и свой собственный HTML Layout движок.
Почему не про iOS, где написано, что нельзя использовать свой HTML Layout Engine
Другой вопрос, что тут для эффектов испольузется блжндинг двух буферов, и для этого нужно иметь доступ к обоим бУферам. Поэтому мне кажется проблема состоит в том, что:
— с соображений безопасности
— не унифицировали API, поэтому не могут еще гарантировать обратой совместимости
— вообще решили, что не нужно это разработчикам.
Или всё вместе.
Они не такие и медленные, долго создается контекст, если держать один контекст во время операции динамического размытия, то всё будет ок.
А вот кстати хорошая статья на сравнение разных подходов.
А тут наглядная демонстрация встроенных фильтров.
Если наколбашего в стороннем коде и это сделано правильно и с пользой — то нужно заливать в «общаг». Если разработчик этого не сделал — это плохо. Если решение специфичное только для этой задачи, то в Objective-C есть много способов сделать это без вмешательства в сторонний код (категории, наследование например).
В общем любой метод правильный, если использован правильно. И об этом нужно рассказывать новичкам.
А то, что вы делаете — это особо не отличается от ручного подхода. Cocoapods вы используете только для ускорения процесса загрузки компонент, насколько я понял. В процессе разрабтки вы же не обновляете пакеты?
При обновлении нужно иметь хорошее покрытие тестами, чтоб быть увереным, что ничего не поломалось. Ведь сторонние пакеты практически не гарантируют обратную совместимость.
И обновлять пакеты имеет смысл, когда работа над проектом ведется очень долго: одна команда — один продукт. И обновление пакетов в этом случае должа быть целая отдельная итерация разработки со всеми циклами тестирования.
А у ручного подхода есть еще достоинства — есть возможность три раза подумать, а действительно ли этот компонент тут нужен?
Я нигде не говорил, что cocoapods — это плохо. Я просто хотел сказать, что нужно кроме достоинств говорить и о недостатках, особенно начинающим разработчикам. Так как они очень доверчиво относятся к тому, что им говорят учителя/наставники. Так проще не утонуть в куче новых знаний. И таким образом рождаются стереотипы.
Тут в советах его настоятельно рекомендуют, вот я бы не стал этого делать :-) Так, что я не категоричен, я не очень ясно выразился.
В таком пакетном подходе есть достаточно весомые недостатки:
— зависимость от сервера
— зависимость от репозитория, на который указывает пакет.
Например был у вас проект, вы его сделали и он себе работает. Вы его положили к себе в репозиторий и занялись другими проектами. Но через год вышел iOS7 и нужно что-то поменять в проекте. Вы спокойно выгружаете свой проект и бац: нужной версии нет в репозитории, владелец переехал со своими исходниками с гитхаба на битбукет, но в cocoapods этого не поменяли. Или вообще удалил свои исходники.
Ну и перестал работать cocoapods вдруг (есть такая вероятность, всё не вечно) и все ваши проекты стали сиротами. И ищи по интернету все зависимости по всем проектам. И хорошо, если найдется.
Извините, что сделать?
Не раскрыто, почему это удобней, чем реализовать например у синглота метод sharedInstance, где с помощью dispatch_once будет по требованию создаваться один экземпляр. А для тестов(если для тестов нужна другая инициализация) либо сделать sharedInstanceTest, либо закрыть инициализацю с помощью директив препроцессора и котролировать это конфигурациями сборки (хотя не очень элегантный вариант).
В общем не очень убедительно.
Так вот 4Гб вообще за глаза хватает. По крайней мере до этого была прошка 15 с 8 гигами и ощущения такие-же.
Я не знаю за счет чего, то-ли умных мезанизм подкачки на SSD, то-ли еще чего.
Щас ретина 16 Гб, но думаю это лишнее. 8 Гигов за глаза практически любому пользователю.
«Программирование под Андроид для занятых разработчиков», а не для лентяев :-) А так вообще наличие таких курсов всегда полезно и нужно.
Google Chrome на iOS использует Blink, Opera старая на iOS использовала Presto, я (и уверен, что не только я) в нескольких проектах использовать Gecko, HTMLayout и свой собственный HTML Layout движок.
Почему не про iOS, где написано, что нельзя использовать свой HTML Layout Engine