Лечу Crash'и NSLog'ами. Недорого. Многолетний опыт. 100% гарантия.

Примерно таким заголовком можно было бы описать то, что три с половиной месяца назад происходило у меня на одном из проектов. Вернее, это даже был не мой проект, но с проблемой crash'а пришлось разбираться именно мне.

Все началось с того, что на одном из относительно больших проектов начало стабильно вываливаться исключение при авторизации пользователя. «Ну и что тут такого? У всех бывает. Проверку на nil забыли поставить или где-то накосячили. „Тоже, мне, большое событие — crash на проекте“, — подумает большая часть программистов. В принципе — абсолютно согласен. Crash — не такое уж и редкое явление в программировании под iPhone, и с ним сталкиваешься по десять раз на день. Но этот был особенным. От него уже начало попахивать „магией“, когда мне сказали про его некоторые параметры и особенности:

• Воспроизводимость на симуляторе: 100%
• Воспроизводимость на устройстве: 0%
• Путь к крэшу (после локализации крэша): ~ 40 секунд
• Настройки оптимизации при компиляции (-O1,-O2...) не влияют на воспроизводимость
• XIB'ы в проекте не используются

Да выглядел он довольно безобидно:

// Code
UITextView * textView = [ [UITextView alloc] initWithFrame:CGRectMake(0, 150, _width, _height)];

// Exception
*** Terminating app due to uncaught exception 'CALayerInvalidGeometry', 
    reason: 'CALayer bounds contains NaN: [0 0; nan 200]'

»Ну тут же и ежу понятно, что width — после вычисления — NaN!", — подумал я. Бегло поглядев где и как вычисляется ширина вьюхи, и не найдя ничего особого опасного, я, для утверждения своей догадки, поставил перед созданием вьюхи NSLog. А вдобавок, и точку останова на строке с созданием элемента.

// Source:
NSLog(@"width = %f", _width);

//Output:
width = 200

«Гм», — подумал про себя я, и продолжил выполнение программы после точки останова. И крэша не произошло…

Когда человеку надоедает делать рутинную работу, у него возникает дикое желание от этой работы избавиться. Однако, в реальной жизни избавиться от нее не так просто, и ее все, же надо делать. В зависимости от вида работы и от ее количества, можно поступать по-разному. Можно продолжать выполнять уже заученные действия, можно уйти в себя и копить злость на всех и вся, на этот мир, на начальника, на PM'a, на <вписать свою причину> А можно попытаться эту рутину автоматизировать.

А пост будет о конкретной задаче, которую надо автоматизировать(Code Formatting) и о том, как все-таки расширить Xcode всякими полезными вкусностями для дальнейших автоматизаций. В прошлый раз это был Copy Paste Detector. А теперь пришло время Code-Formattera. Скажу сразу, что в здесь не поднимается вопрос, нужен ли автоматический Code-Formatter. Предполагается, что Вам он нужен. Если, все же не нужен — можно заглянуть под кат, чтобы вспомнить про возможность использовать внешние скрипты в Xcode.

Сегодня ночью, проводя очередной code-review в наших проектах, наткнулся на большой кусок проявления чистейшего, кристализованного копипаста. Он не очень пришелся мне по душе, и как-то сразу всплыл вопрос:" А много ли копипаста у нас в проектах"? Google is my friend, поэтому решение нашлось очень быстро у jkennedy1980, который использовал CPD (copy paste detector), который входит в PMD (Pretty Much Done || Project Mess Detector || Programming Mistake Detector || ... ). В общем случае, CPD умеет находить copy-paste сходу для ряда языков(cpp, cs, java, php, ruby, ecmascript) и относительно легко расширяется, но мне же был нужен Objective-C. Как раз такой вариант и был у jkennedy1980, который использовал CPD в автоматической сборке jenkins'ом. Это в общем случае очень хорошо для любого проекта на любом языке, когда jenkins внедрен в процесс разработки, все права выставлены, и все знают где, когда и что надо нажимать. В случае же, когда разработчики не знают про jenkins, либо знают, но он где-то там далеко, такой метод мягко говоря не подходит. Xcode для iPhone/iOS разработчиков, все же, как-то ближе, и хотя для него все еще нельзя написать плагин,

Те, кому по причине необходимости пришлось столкнуться с Three20, в процессе разработки iOS приложений, знают, что данная библиотека более-менее решать некоторый круг задач, связанный с быстрым прототипированием, использованием глобальной навигации, MVC подходом для разработки приложений.

Основным минусом библиотеки является то, что в ней отсутствует нормальная документация, а та, что есть недостаточна для нормального понимания того, что происходит внутри этой библиотеки.

Это не единственный минус библиотеки, и в интернете можно найти много обсуждений относительно за и против Three20.

Необходимо сказать, что главный разработчик остановил разработку над Three20, и решил создать новую библиотеку Nimbus, основной идеей которой будет простота и высокая документированность:
«Nimbus is an iOS framework whose feature set grows only as fast as its documentation.»

Тем не менее, проект существует и по сей день, и некоторые части этого проекта заслуживают внимания, и достаточны интересны с точки зрения проектирования.

В данном посте будут подробно рассмотрены вопросы, связанные с работой TTModel.

Для тех, кто не собирается использовать Three20 у себя в проектах, будет полезно подсмотреть на одну из возможных, заслуживающий внимания, реализаций модели в шаблоне MVC.

Всех, кому еще интересно, прошу

Большинство прикладных приложения под iOS таким или иным образом используют UIViewController'ы. Там где UIKit фрэймворк — там и UIViewController'ы. Их много, они повсюду, они сидят в засадах и выглядывают из-за каждого угла. Поэтому, любой программист под iOS — будь он зеленым новичком, едва ступившим на тропу программирования, либо матерым профессионалом своего дела, должны знать о UIViewController'aх все.

Причиной написания данной поста является то, что, как оказалось, можно преспокойно программировать под iOS полгода, и не знать полностью о жизненном цикле UIViewcontroller'ов. И на небольших проектах это даже получается. Однако, когда приходится иметь дело с серьезным, достаточно большим проектом, то появляются определенные проблемы с нехваткой памяти, «неправильной» и «непонятной» работой контроллеров, пропажей данных, и еще со многими типичными проблемами, о которых будет написано ниже.

Так вот. В данном посте, я еще раз расскажу о жизненном цикле UIViewController'ов, расскажу о том, что и где стоит делать, и в каком случае. Пост ориентирован на разработчиков разных уровней, так что кто-то узнает для себя что-то новое, а кто-то найдет повод отпинать моменты, на которые стоит обратить внимание Junior'ов в команде.

Всех заинтересовавшихся, прошу

Вот и закончились очередные 72 часа, в течение которых порядка 300 команд пытались решить задание в рамках ежегодного соревнования от ICFP.

Предварительные результаты (замороженные за 12 часов до окончания), можно посмотреть на сайте организатора, там же можно прочитать и задание этого года.

Итак, список русскоязычных отчетов, найденных на просторах интернета:

При разработке под iOS время от времени у заказчиков, да и у некоторых программистов возникает закономерный вопрос: «А можно ли каким-нибудь образом при старте приложения подменять картинку?».

Немного порыскав по интернету, и покопавшись в документации, то напрашивается ответ, что сделать это невозможно по следующим причинам:

• Файл, который показывается при запуске приложения лежит внутри папки приложения, и, ак следовательно переписать его не является возможным
• По аналогичной причине нельзя изменить файл Info.plist, в котором сохраняется относительный путь к файлу стартовым изображением

Однако, все же, это возможно сделать стандартными способами, без всякого рода Jailbreak'а. Впрочем, как и у каждого решения есть свои плюсы, минусы и особенности.