Да, пожалуй, потом я тоже подумал о том, что здесь могут возникнуть проблемы 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 принесут ожидаемый результат.
Пардон. Я успел сообщение поправить, пока вы коммент писали. Перечитал задачу внимательнее.
Вообще, похоже, ключевое слово «заполнить». Это не «подставить».
Если уж «заполнять», то 6 + 11 + 13
Их тут нет:
Если вы в качестве десятичного знака запятую, то разделителями чисел выступает точка с запятой (";"). («по-русски»)
Если вы хотите использовать запятую в качестве разделителя, то вы допжны использовать точку как десятичный разделитель («по-английски»). Ну или поставить пробелы как положенно в типографике, в конце концов («по-человечески»).
Тут нет никаких дополнительных условий, в таких ситуациях подразумивается «дефолтное» поведение. Я конечно могу начать считать в 11-тиричной системе или сказать, что здесь 11 = def(10), но это бред.
Вот именно в таком виде задача не имеет решения, т.к. чтобы записать это в системе исчисления с другим основанием нужно поместить 2 числа в квадрат.
Но расход памяти здесь — далеко не самая главная проблема :)
Например, в фирме, где я сейчас работаю, в тестовые задания ошибки вставляют специально.
Здесь используется arc?
Если да, то утечки памяти здесь нет.
В общем часть вопросов выглядят так, как будто они пришли из времён iPhone OS 3.0
По идее, это должен быть wireframe, но он не должен обращаться к данным.
Ближайший объект, который может сделать этот выбор — это Presenter, но конкретный Презентер работает с конкретным подмножеством данных, и для этого выбора ему нужно запросить дополнительные данные. К тому же выбор переходов перестаёт быть очевидным из-за того, что ответственность размазывается по множеству классов.
Можно попробовать, как мне тут подсказывают, ввести дополнительный презентер в цепочку вызовов, но это ЕЩЁ больше бойлерплейта.
В общем, удовлетворительного решения этой проблемы я пока не вижу.
В любом случае, спасибо за ответ. А вот вашим, хм, клиентом, я смогу стать когда вы научите PVS-Studio в Objective-C/Swift :)
Могу ли я бесплатно проверить коммерческий проект с открытым кодом? Если да, то как мне это сделать? А можете ли это сделать вы и написать статью? :)
С другой стороны — вопрос быстродействия. Первый кандидат на роль биндингов — KVO, но чаще всего — это плохая идея с точки зрения быстродействия. Значит нам нужны свои собственные dependency property. А ещё нужна реализация двухсторонних биндингов для пользовательского ввода.
В другой стороны, можно (и нужно) просто скинуть всю визуальную логику в потомок от UIView и сделать его вьюхой контроллера, оставив в UIViewController только делегаты и обновление данных.
В общем, я не уверен, что оно того стоит. Как баловство в каком-то своём проекте — почему бы и нет? А вот для чего-то серьёзного — я бы не стал использовать этот подход напрямую.
Вообще, похоже, ключевое слово «заполнить». Это не «подставить».
Если уж «заполнять», то 6 + 11 + 13
Кстати, я тут подумал: некоторые кодеры пишут код вот точно так же, как эта задача составлена.
Это тоже является решением задачи.
Если вы в качестве десятичного знака запятую, то разделителями чисел выступает точка с запятой (";"). («по-русски»)
Если вы хотите использовать запятую в качестве разделителя, то вы допжны использовать точку как десятичный разделитель («по-английски»). Ну или поставить пробелы как положенно в типографике, в конце концов («по-человечески»).
Так что условие таки некорректно.
Вот именно в таком виде задача не имеет решения, т.к. чтобы записать это в системе исчисления с другим основанием нужно поместить 2 числа в квадрат.