Длинные кейсы рулятся уже внутри, для этого в рутовом контроллере вместо непосредственно контроллеров логина/главного добавляют, например, UINavigationController, в который уже и «навигирует».
Координация в таких случаях осуществляется, например, при помощи координаторов. Никаких тысяч строк тут нет.
А вы уверены, что если приводишь примеры «сложной» разработки при помощи нативных средств, и при этом, чтобы показать, какая она сложная, используешь низкоуровневые библиотеки, которыми никто давно не пользуется, то тебя никто не раскусит? :)
Я не из мира Java, но любопытство есть. Так что у меня такой вопрос: в том же методе get используются this.level, this.current. Вопрос потоконебезопасности даже при чтении не смущает в данном случае? В моем мире задача читателей/писателей довольно актуальна, и не иметь возможности корректно читать из нескольких потоков кажется странным.
Всё, что нужно от мобильного ВК, находится на таб баре. Кнопкой More не пользуюсь почти. Был счастлив, когда, наконец, убрали бургер.
Быстрое переключение между текущими, как было сказано, модальными задачами (смотришь ленту, решил написать сообщение, затем надо вернуться) в одно движение, на мой взгляд, стало гораздо удобнее.
А самый большой профит в возможности сохранения текущего стека навигации в одной из вкладок. Вспомните, раньше: листаешь ленту, ткнул на пост, ткнул на паблик, там зашел еще куда-то. Что нужно, чтобы получить доступ к меню? Поправьте меня, если я ошибаюсь, но кажется, нужно было нажимать кнопку «назад», пока не попадешь на ленту.
Так что я полностью согласен с мыслью о том, что оставлять бургер стоило лишь ради привычки пользователей, но, как по мне, это было бы ошибкой.
1. Мы на «ты» не переходили, профессор.
2. lenght пишется length. А о безопасности расскажи кому-нибудь ещё. Получил nil, получил из него 0 и думай, почему у меня там обработка такая, будто объект есть, хотя его нет в природе.
3. По себе людей не судят. Раз ты считаешь, что такой код имеет место в проде, значит и сам так можешь написать. Я такой код сам не пишу и на код ревью не пропущу.
Если в распоряжении всего один урок, то как бы хорошо ты не объяснил процесс обдумывания решения, ученики забудут все со звонком, потому что это скучно. Да и не на один урок это. Мне вот алгоритмы (без привязки к программированию) преподавали всю начальную школу.
Автор поставил задачу показать аспект кодотворения, причем упор сделал на результат: мы написали эти, пока ещё не совсем понятные нам 15 строк кода, и теперь компьютер может загадывать числа и подсказывать нам.
10 класс – это конечно уже поздновато начинать с программированием, но, вспоминая себя где-нибудь в 6-7 классе, могу сказать, что меня это точно заинтересовало бы и вот тогда я бы уже хотел учиться.
Я тоже такой вопрос хотел задать, но затем пришло осознание, что ведь в данном случае прокси позволяет вызвать методы у тех, у кого они определены (с приоритетом, конечно же), и без него NewLogicController обязан определить ВСЕ методы делегата и пробросить их дальше, чтобы ничего не потерять. Прокси же автоматически вызовет методы, которых нет в NewLogicController, у старого вью контроллера.
Не то чтобы это было хорошо, все-таки, неявность очень сильно увеличивает время понимания кода, но зато показывает, как, действительно, красиво можно решать проблему.
В случае с методами вы знаете о типах данных, не нужно бояться, что если вдруг тип одного из передаваемых значений изменится, то вы получите краш или просто некорректный вывод на экране: лучше получить ошибки на этапе компиляции и поправить их в каждом месте, чем править их по мере «натыкания» на краш или, что еще сложнее заметить, на пустой лэйбл, заходя на один из экранов раз в месяц, поскольку его разработкой сейчас не занимаетесь.
Почему бы не создать класс или структуру вроде WeatherDescription, объявить в ней нужные вам поля и радоваться жизни. Добавить новое поле в класс, да без проблем, удалить какое-то поле и получить ошибки компиляции в нужных местах, да отлично.
А если наблюдатель, простите за тавтологию, наблюдает за значениями/объектами/событиями, не относящимися к одной группе, так вообще лучше объявить несколько методов в протоколе наблюдателя.
Удобно-то удобно, только вот в реалиях нынешней поддержки Swift пользоваться всем этим накладно.
Особенно в Xcode, где и время компиляции не растет при использовании кложуров, и подсветка синтаксиса с автокомплитом ломаются.
По книгам очень трудно что-то конкретное сказать.
По своему личному опыту считаю, что если считать что начинаешь программирование с нуля, то по сути цепочка сводится к:
— Начальные навыки (процедурное программирование, алгоритмы)
— Объектно-ориентированное программирование на каком-то языке, где относительно традиционная в современном понимании модель ООП (типа C++, C#)
— Изучение Objective-C. Желательно сразу пытаться что-то писать, то есть изучать в купе с Cocoa/Cocoa Touch, потому что теория программирования и ООП уже изучена. Причем книги чисто по языку здесь не столько архи-полезны и выступают, скорее, в роли справочного материала, но пролистать и ознакомиться с тем, какие возможности вообще есть, конечно, стоит. Очень много дают различные гайды от самих Apple (App Programming Guide, Core Data Programming Guide, etc.)
Изучение Swift, на мой взгляд, должно быть скорее факультативным, я лично изучил его до приемлемого уровня только попав в проект, но потратил на это неделю, дальше шло просто совершенствование.
А что-то вроде Objective-C Recipes — это по сути материал, который изучается уже по ходу разработки: касаешься какой-то темы в проекте и идешь искать это в книжках, интернете.
Можно. Но, хоть я и согласен с мыслью, что язык – это лишь инструмент, если есть желание стать хорошим iOS-разработчиком, Objective-C изучить нужно.
Полного перехода на Swift пока не предвидится со стороны разработчиков, со стороны Apple, наверняка, тоже. А чтобы понимать принципы работы с Cocoa/Cocoa Touch, знание того, как работает язык, просто необходимо.
Кроме того, хотя это может оказаться спорным моментом, в Objective-C намного лучше раскрываются низкоуровневые механизмы, такие как управление памятью, autoreleasepool и прочее.
Аплодирую стоя вашему терпению при общении с "разработчиком с десятилетним примерно стажем".
Спасибо
UINavigationController, в который уже и «навигирует».Координация в таких случаях осуществляется, например, при помощи координаторов. Никаких тысяч строк тут нет.
Я не из мира Java, но любопытство есть. Так что у меня такой вопрос: в том же методе get используются this.level, this.current. Вопрос потоконебезопасности даже при чтении не смущает в данном случае? В моем мире задача читателей/писателей довольно актуальна, и не иметь возможности корректно читать из нескольких потоков кажется странным.
Быстрое переключение между текущими, как было сказано, модальными задачами (смотришь ленту, решил написать сообщение, затем надо вернуться) в одно движение, на мой взгляд, стало гораздо удобнее.
А самый большой профит в возможности сохранения текущего стека навигации в одной из вкладок. Вспомните, раньше: листаешь ленту, ткнул на пост, ткнул на паблик, там зашел еще куда-то. Что нужно, чтобы получить доступ к меню? Поправьте меня, если я ошибаюсь, но кажется, нужно было нажимать кнопку «назад», пока не попадешь на ленту.
Так что я полностью согласен с мыслью о том, что оставлять бургер стоило лишь ради привычки пользователей, но, как по мне, это было бы ошибкой.
2.
lenghtпишется length. А о безопасности расскажи кому-нибудь ещё. Получил nil, получил из него 0 и думай, почему у меня там обработка такая, будто объект есть, хотя его нет в природе.3. По себе людей не судят. Раз ты считаешь, что такой код имеет место в проде, значит и сам так можешь написать. Я такой код сам не пишу и на код ревью не пропущу.
Удобно и безопасно, если вы не умеете с ними работать, это не значит, что они не нужны.
Вы так в production коде делаете? Удачи вам и хорошего настроения.
Автор поставил задачу показать аспект кодотворения, причем упор сделал на результат: мы написали эти, пока ещё не совсем понятные нам 15 строк кода, и теперь компьютер может загадывать числа и подсказывать нам.
10 класс – это конечно уже поздновато начинать с программированием, но, вспоминая себя где-нибудь в 6-7 классе, могу сказать, что меня это точно заинтересовало бы и вот тогда я бы уже хотел учиться.
Не то чтобы это было хорошо, все-таки, неявность очень сильно увеличивает время понимания кода, но зато показывает, как, действительно, красиво можно решать проблему.
В случае с методами вы знаете о типах данных, не нужно бояться, что если вдруг тип одного из передаваемых значений изменится, то вы получите краш или просто некорректный вывод на экране: лучше получить ошибки на этапе компиляции и поправить их в каждом месте, чем править их по мере «натыкания» на краш или, что еще сложнее заметить, на пустой лэйбл, заходя на один из экранов раз в месяц, поскольку его разработкой сейчас не занимаетесь.
Почему бы не создать класс или структуру вроде
WeatherDescription, объявить в ней нужные вам поля и радоваться жизни. Добавить новое поле в класс, да без проблем, удалить какое-то поле и получить ошибки компиляции в нужных местах, да отлично.А если наблюдатель, простите за тавтологию, наблюдает за значениями/объектами/событиями, не относящимися к одной группе, так вообще лучше объявить несколько методов в протоколе наблюдателя.
Особенно в Xcode, где и время компиляции не растет при использовании кложуров, и подсветка синтаксиса с автокомплитом ломаются.
Только чувствую, как сейчас понабегут с криками, что автор адепт секты.
Из данной статьи в очередной раз можно вынести, что не нужно читать подобные статьи на тему «оно плохое». Если интересно, разберись и для себя реши.
По своему личному опыту считаю, что если считать что начинаешь программирование с нуля, то по сути цепочка сводится к:
— Начальные навыки (процедурное программирование, алгоритмы)
— Объектно-ориентированное программирование на каком-то языке, где относительно традиционная в современном понимании модель ООП (типа C++, C#)
— Изучение Objective-C. Желательно сразу пытаться что-то писать, то есть изучать в купе с Cocoa/Cocoa Touch, потому что теория программирования и ООП уже изучена. Причем книги чисто по языку здесь не столько архи-полезны и выступают, скорее, в роли справочного материала, но пролистать и ознакомиться с тем, какие возможности вообще есть, конечно, стоит. Очень много дают различные гайды от самих Apple (App Programming Guide, Core Data Programming Guide, etc.)
Изучение Swift, на мой взгляд, должно быть скорее факультативным, я лично изучил его до приемлемого уровня только попав в проект, но потратил на это неделю, дальше шло просто совершенствование.
А что-то вроде Objective-C Recipes — это по сути материал, который изучается уже по ходу разработки: касаешься какой-то темы в проекте и идешь искать это в книжках, интернете.
Полного перехода на Swift пока не предвидится со стороны разработчиков, со стороны Apple, наверняка, тоже. А чтобы понимать принципы работы с Cocoa/Cocoa Touch, знание того, как работает язык, просто необходимо.
Кроме того, хотя это может оказаться спорным моментом, в Objective-C намного лучше раскрываются низкоуровневые механизмы, такие как управление памятью, autoreleasepool и прочее.