Вообще, насколько я знаю, у них используются сторонние проприетарные библиотеки с закрытым кодом, которые они не могут выложить, а так же из-за этого они не могут выложить х64 версию. Хотя она собирается из этих же исходников с подключением библиотек, взятых из релизной версии.
Возможно им требуется время на приведение проекта в состояние, в котором публикация кода не нарушит лицензий. Но для таких случаев можно и скрипт написать, тем более, если код они уже многократно обновляли.
Я не сильно удивлён результатами :)
К сожалению, у этик редисок в репозитории лежит старая версия, отстающая от актуальной. У них «нет времени», чтобы обновить её, по их же словам.
Прочитал код как [[NSString alloc] initWithString@«hello world»];
Ну а дальше я предполагал, что ARC оперирует областями видимости. Как только объект выходит из области видимости — у него вызывается release.
В non-arc объект уничтожается незамедлительно после того, как referenceCount становится равным нулю. То есть, если бы вместо autorelease вызывался бы release — autorelease pool бы не использовался и утечки бы не было бы.
Ну, тут вопрос в том, как именно ARC расставит вызовы. Если бы он релизил объекты при присваивании (как это делалось в setter'ах в non-arc) — то утечки памяти всё равно не было бы.
Да, пожалуй, потом я тоже подумал о том, что здесь могут возникнуть проблемы c работой ARC из-за того, что поток никогда не будет освобождён. Точного механизма его работы я не знаю, только общие принципы.
Но расход памяти здесь — далеко не самая главная проблема :)
У меня складывается такое впечатление, что смысле не в правильном ответе на эти вопросы, а в том, КАК человек на них ответит.
Например, в фирме, где я сейчас работаю, в тестовые задания ошибки вставляют специально.
Проблема в VIPER, которую я вижу (ну или в том понимании Вайпера, которое у меня есть — я могу ошибаться), это то, что у него нет сущности, способной делать выбор, какой экран показать дальше в случае сложного и нелинейного workflow.
По идее, это должен быть wireframe, но он не должен обращаться к данным.
Ближайший объект, который может сделать этот выбор — это Presenter, но конкретный Презентер работает с конкретным подмножеством данных, и для этого выбора ему нужно запросить дополнительные данные. К тому же выбор переходов перестаёт быть очевидным из-за того, что ответственность размазывается по множеству классов.
Можно попробовать, как мне тут подсказывают, ввести дополнительный презентер в цепочку вызовов, но это ЕЩЁ больше бойлерплейта.
В общем, удовлетворительного решения этой проблемы я пока не вижу.
В данном случае я имел ввиду редактор XAML в Visual Studio: помимо функционала визуального редактора он так же умеет делать автозавершение и автоматическую генерацию методов. В основном это вызвано тем, что концепция MVVM для WPF родная.
Кажется, вы меня неправильно поняли. Я имею к этому проекту отношение только как пользователь. Ну и я имел ввиду в рамках обычного цикла статей, таких, как эта.
В любом случае, спасибо за ответ. А вот вашим, хм, клиентом, я смогу стать когда вы научите PVS-Studio в Objective-C/Swift :)
Давно не следил за вашими постами, потому есть вопрос:
Могу ли я бесплатно проверить коммерческий проект с открытым кодом? Если да, то как мне это сделать? А можете ли это сделать вы и написать статью? :)
Проблема в том, что вы замучаетесь писать биндинги и конвертеры вручную, если у вас нет достаточно мощного инструмента.
С другой стороны — вопрос быстродействия. Первый кандидат на роль биндингов — KVO, но чаще всего — это плохая идея с точки зрения быстродействия. Значит нам нужны свои собственные dependency property. А ещё нужна реализация двухсторонних биндингов для пользовательского ввода.
В другой стороны, можно (и нужно) просто скинуть всю визуальную логику в потомок от UIView и сделать его вьюхой контроллера, оставив в UIViewController только делегаты и обновление данных.
В общем, я не уверен, что оно того стоит. Как баловство в каком-то своём проекте — почему бы и нет? А вот для чего-то серьёзного — я бы не стал использовать этот подход напрямую.
Имхо, главная проблема MVVM — без хорошего редактора он ничего не стоит. Так что я не уверен, что попытки использовать этот паттерн в Obj-C/Swift принесут ожидаемый результат.
Возможно им требуется время на приведение проекта в состояние, в котором публикация кода не нарушит лицензий. Но для таких случаев можно и скрипт написать, тем более, если код они уже многократно обновляли.
К сожалению, у этик редисок в репозитории лежит старая версия, отстающая от актуальной. У них «нет времени», чтобы обновить её, по их же словам.
Ну а дальше я предполагал, что ARC оперирует областями видимости. Как только объект выходит из области видимости — у него вызывается release.
Вот так:
NSString *str;
while (YES) {
[string release];
str = [[NSString alloc] initWithFormat:@«hello world»];
}
Кстати, надо бы проверить, как ARC поведёт себя в случае с [[NSObject alloc] init]. К сожалению, сейчас нет Мака под рукой.
Но расход памяти здесь — далеко не самая главная проблема :)
Например, в фирме, где я сейчас работаю, в тестовые задания ошибки вставляют специально.
Здесь используется arc?
Если да, то утечки памяти здесь нет.
В общем часть вопросов выглядят так, как будто они пришли из времён iPhone OS 3.0
По идее, это должен быть wireframe, но он не должен обращаться к данным.
Ближайший объект, который может сделать этот выбор — это Presenter, но конкретный Презентер работает с конкретным подмножеством данных, и для этого выбора ему нужно запросить дополнительные данные. К тому же выбор переходов перестаёт быть очевидным из-за того, что ответственность размазывается по множеству классов.
Можно попробовать, как мне тут подсказывают, ввести дополнительный презентер в цепочку вызовов, но это ЕЩЁ больше бойлерплейта.
В общем, удовлетворительного решения этой проблемы я пока не вижу.
В любом случае, спасибо за ответ. А вот вашим, хм, клиентом, я смогу стать когда вы научите PVS-Studio в Objective-C/Swift :)
Могу ли я бесплатно проверить коммерческий проект с открытым кодом? Если да, то как мне это сделать? А можете ли это сделать вы и написать статью? :)
С другой стороны — вопрос быстродействия. Первый кандидат на роль биндингов — KVO, но чаще всего — это плохая идея с точки зрения быстродействия. Значит нам нужны свои собственные dependency property. А ещё нужна реализация двухсторонних биндингов для пользовательского ввода.
В другой стороны, можно (и нужно) просто скинуть всю визуальную логику в потомок от UIView и сделать его вьюхой контроллера, оставив в UIViewController только делегаты и обновление данных.
В общем, я не уверен, что оно того стоит. Как баловство в каком-то своём проекте — почему бы и нет? А вот для чего-то серьёзного — я бы не стал использовать этот подход напрямую.