С листинга 19-7, где валидатор решили сделать IBOutlet'ом, ждал момента, когда будем прицеплять. В итоге все ограничилось «так можно — читай там». Я правильно понимаю, что мы просто берем Object в IB, указываем там класс и цепляем?
Второй вопрос по самой связке. Зачем они завязывают выбор стратегии(выбор логики) на IB, который нужен для построения UI и связи его элементов с кодом? Стратегии можно раздать во viewDidLoad основного контроллера.
И еще не понял в чем проблема кидать исключения при вызове абстрактного метода. Этот метод никогда не будет вызываться ни в каких циклах, причем тут производительность? Не рекомендуется? Надо использовать NSError, ок, и выставили его в nil. Как тогда сообщить разрабу, что код не дописан и мы дергаем абстрактные методы? Почему бы не кидать исключения за такое?
Это все вопрос философии. Сами фреймвоки на Android подталкивают разработчика к работе через исключения.
На тему того, что не надо ловить исключения — можно поспорить. Не до конца понятно, что мешает отправить себе стек и сообщение о критической ситуации не роняя приложение. И действительно ли так много ситуаций, когда нельзя позволить продолжить пользоваться приложением?
Есть что добавить. Не скажу за всю мелкую моторику, но писать ручкой после окончания университета стал намного хуже, похожая история у многих друзей/знакомых.
Отлично! Отдельное спасибо за моменты с памятью.
Возник вопрос: Почему прикрутив модификатор __block мы рвем retain cycle? Думал, что данный идентификатор используется для того, чтобы получить возможность изменять внешний для блока объект.
Apple борется за батарейку пользователя. Так гарантируется, что никто не сможет написать сервис, который будет крутиться в бэкграунде и каждые 5 минут перекачивать например весь контент в приложении.
Техническая конференция по мобильной разработке — это хорошо, но темы достаточно специфические. Если вкркатце описать: безопасность мобильных приложений, кроссплатформа, Tizen, Kotlin. Не хочу разводить холивары на тему долей рынка, перспективности и прочего, просто хочется более канонической мобильной разработки. Что-то в духе Apple Tech Talks по двум основным платформам. Ну и даешь в Москве конечно же! :)
Каталоги, как оказалось, популярны в Германии, почему бы просто не дать людям то, что им надо? Ясно, что вы не являетесь целевой аудиторией. Ну а так вы ведь разработчик, должны понимать, что интересность проекта связана с конечным контентом достаточно косвено. Инкапсуляция ведь, на написанное можно было бы натянуть научные журналы, комиксы или смешные картинки. Наверняка большинство разрабов и близко к проспектам не подходит, не разрабы ведь сайты заполняют.
Стало любопытно, поставил себе Яндекс.Shell. Когда пользовался последний раз, он страшно лагал, сейчас все работает бодренько.
Сразу пара вопросов к знатокам/ребятам из Яндекса: Как получилось, что среди приложений есть яндексовский телефон и местами вылезает яндексовская клавиатура, хотя я их не ставил? На андроиде ведь ничего нельзя поставить без рута и без запроса к пользователю. Ланчер делает вид, что у него есть эти приложения, а на деле он просто открывает собственные активити?
Так или иначе, большую часть функционала из ролика удалось повторить просто при помощи ланчера.
С одной стороны понятно, что прошивка нужна, чтобы пользователь получил все «из коробки». Но с другой стороны простой домохозяйке ничего не останется, кроме как пользоваться Стором и недоумевать, почему у ее подружки на самсунге больше приложений, хотя и там и там андроид.
Тем более, прошивку сложнее поддерживать для всех смартфонов, и, скорее всего, она будет пилиться только для телефонов «партнеров».
Почему бы не предложить то же самое покомпонентно? Уверен, что желающих попробовать ланчер, звонилку, контакты, клавиатуру и пр. от Яндекса найдется намного больше, чем тех, кто захочет перепрошивать телефон. Нужен простой путь как «туда», так и «обратно», в случае чего.
Второй вопрос по самой связке. Зачем они завязывают выбор стратегии(выбор логики) на IB, который нужен для построения UI и связи его элементов с кодом? Стратегии можно раздать во viewDidLoad основного контроллера.
И еще не понял в чем проблема кидать исключения при вызове абстрактного метода. Этот метод никогда не будет вызываться ни в каких циклах, причем тут производительность? Не рекомендуется? Надо использовать NSError, ок, и выставили его в nil. Как тогда сообщить разрабу, что код не дописан и мы дергаем абстрактные методы? Почему бы не кидать исключения за такое?
На тему того, что не надо ловить исключения — можно поспорить. Не до конца понятно, что мешает отправить себе стек и сообщение о критической ситуации не роняя приложение. И действительно ли так много ситуаций, когда нельзя позволить продолжить пользоваться приложением?
Возник вопрос: Почему прикрутив модификатор __block мы рвем retain cycle? Думал, что данный идентификатор используется для того, чтобы получить возможность изменять внешний для блока объект.
Сразу пара вопросов к знатокам/ребятам из Яндекса: Как получилось, что среди приложений есть яндексовский телефон и местами вылезает яндексовская клавиатура, хотя я их не ставил? На андроиде ведь ничего нельзя поставить без рута и без запроса к пользователю. Ланчер делает вид, что у него есть эти приложения, а на деле он просто открывает собственные активити?
Так или иначе, большую часть функционала из ролика удалось повторить просто при помощи ланчера.
Тем более, прошивку сложнее поддерживать для всех смартфонов, и, скорее всего, она будет пилиться только для телефонов «партнеров».
Почему бы не предложить то же самое покомпонентно? Уверен, что желающих попробовать ланчер, звонилку, контакты, клавиатуру и пр. от Яндекса найдется намного больше, чем тех, кто захочет перепрошивать телефон. Нужен простой путь как «туда», так и «обратно», в случае чего.