Comments 17
MVPM – что? Это вы сами придумали?
Идея принадлежит Мартину Фаулеру, см. Presentation Model. MVPM — интерпретация этой идеи применительно к iOS SDK.
Мартин пишет,
Действительно выказываю почтение тем, кто докопался до насалфетных набросков Фаулера. Интересно, намного это полезней того же MVVM в разработке под iOS, например?
As such this material is very much in draft form and I won’t be doing any corrections or updates until I’m able to find time to work on it again.
Действительно выказываю почтение тем, кто докопался до насалфетных набросков Фаулера. Интересно, намного это полезней того же MVVM в разработке под iOS, например?
Учитывая то, что мне пока ни разу не довелось натыкаться на не то что одинаковые интерпретации MVVM в разных проектах, но даже и MVC — то вполне могут оказаться полезными знаниями (ну или на самом деле очередной интепретацией MVVM :-) ) )
Я бы не стал говорить, что MVPM может быть полезней MVVM.
Я бы сказал, что каждый из этих шаблонов может быть более уместен в тех или иных условиях.
Набор классов iOS SDK физически разделяет пользовательские истории на экраны, предоставляя логическую единицу в виде наследников UIViewController. Учитывая подобный подход, мы получаем возможность применения различных шаблонов (MVC, MVP, MVVM, MVPM) в рамках одного и того же приложения. Один экран = один шаблон в самом абсурдном случае.
Следует понимать, что, с одной стороны, программная логика в рамках экрана может потребовать разделения. Выделения сущностей, посвящённых той или иной ответственности.
С другой стороны, MVPM и MVVM (как и вообще любой шаблон проектирования) предполагают изначальный overhead по коду; MVPM и MVVM физически сложнее MVC и MVP.
Таким образом, там, где это действительно необходимо, может быть применен MVPM.
В большинстве случаев не стоит делать предварительной оптимизации, и городить сущности ради конвенции.
В качестве примера могу привести три граничных случая.
Первый: классический экран авторизации с логином и паролем.
Второй: экран с таблицей, выводящей набор модельных сущностей посредством типичных ячеек.
Третий: экран с таблицей, содержащей набор полей ввода, значения которых могут влиять друг на друга.
Внимание, викторина: какой из шаблонов где следует применять? (-:
Я бы сказал, что каждый из этих шаблонов может быть более уместен в тех или иных условиях.
Набор классов iOS SDK физически разделяет пользовательские истории на экраны, предоставляя логическую единицу в виде наследников UIViewController. Учитывая подобный подход, мы получаем возможность применения различных шаблонов (MVC, MVP, MVVM, MVPM) в рамках одного и того же приложения. Один экран = один шаблон в самом абсурдном случае.
Следует понимать, что, с одной стороны, программная логика в рамках экрана может потребовать разделения. Выделения сущностей, посвящённых той или иной ответственности.
С другой стороны, MVPM и MVVM (как и вообще любой шаблон проектирования) предполагают изначальный overhead по коду; MVPM и MVVM физически сложнее MVC и MVP.
Таким образом, там, где это действительно необходимо, может быть применен MVPM.
В большинстве случаев не стоит делать предварительной оптимизации, и городить сущности ради конвенции.
В качестве примера могу привести три граничных случая.
Первый: классический экран авторизации с логином и паролем.
Второй: экран с таблицей, выводящей набор модельных сущностей посредством типичных ячеек.
Третий: экран с таблицей, содержащей набор полей ввода, значения которых могут влиять друг на друга.
Внимание, викторина: какой из шаблонов где следует применять? (-:
Только для жителей и гостей столицы? Или возможно удаленное посещение?
К сожалению, удаленное посещение невозмжно. Стажировка очная в московском офисе Redmadrobot.
Прошу прощения за вопрос — что вы вкладываете в понятие «лучшие стажеры»? Это активные (интересующиеся) / отвечающие на семинарах / хорошо программирующие / хорошо сделавшие итоговое задание / коммуникабельные / красивые /…?
Интересны критерии оценки потенциальных кандидатов.
p.s. не подумайте что я тролль — к инициативе отношусь положительно.
Интересны критерии оценки потенциальных кандидатов.
p.s. не подумайте что я тролль — к инициативе отношусь положительно.
Есть набор формальных критериев (качество выполнения заданий, результаты проверок на лекциях и пр.) и неформальных (скорость роста, усердие и внимательность, формулировка и состав вопросов, коммуникация).
По итогам мы собираем все в одно место и принимаем решение по каждому кандидату. В общем, так же, как это бывает после собеседований, но более информированно.
По итогам мы собираем все в одно место и принимаем решение по каждому кандидату. В общем, так же, как это бывает после собеседований, но более информированно.
iOS9, Android 6 и другие знания, которые вам не скоро ещё пригодятся.
*это не в претензию, это сожаление о медленной скорости обновления устройств*
*это не в претензию, это сожаление о медленной скорости обновления устройств*
А что значит не скоро пригодятся? В Android 6 появилась новая модель управления разрешениями, которую стоит учитывать вот прямщас, потому что всё равно все придут к Android 6, пусть в течение 3 или 4 лет. Забить на краши новой версии или вообще выбросить из головы мысли о том, что приложение будет жить более года, как-то неверно.
Android 6 нужно изучать уже, несмотря на то что дашборд показывает долю в 0.5 процента.
Android 6 нужно изучать уже, несмотря на то что дашборд показывает долю в 0.5 процента.
Да понятно, что надо учитывать последние версии OS. В android они через время новые фичи хотя бы бекпортируют.
Вот с iOS — беда. Ну добавили они контрол. На старых осях его как не было, так и нет.
Вот с iOS — беда. Ну добавили они контрол. На старых осях его как не было, так и нет.
Боль ваша, конечно, понятна. Но не все новинки бесполезны: например, всякие фишки типа force touch и quick actions можно спокойно встраивать уже сейчас, новые фичи по безопасности придется учитывать всем (иначе iOS 9 просто заблокирует доступ к ресурсам), работать с iPad multitasking и iPad Pro приходится уже какое-то время. Самое большое разочарование, наверное, это UIStackView, но мы пользуемся ORStackView без особых проблем.
В общем, тут есть много того, о чем нужно поговорить.
В общем, тут есть много того, о чем нужно поговорить.
iOS 9 = 71% спустя ровно три месяца после выхода
developer.apple.com/support/app-store
Куда уж быстрее?
С андроид не так шустро, конечно, это да.
developer.apple.com/support/app-store
Куда уж быстрее?
С андроид не так шустро, конечно, это да.
Подскажите, в течение какого времени будет стажировка? Вы пишете что это зима. Т.е. полтора месяца? И еще: в вечернее время, это во сколько?
Sign up to leave a comment.
Зимняя стажировка для разработчиков в Redmadrobot