Инструмент Automation (автоматическое тестирование iOS-приложений) - некоторые способы обойти траблы

Инструмент Automation позволяет автоматически тестировать iOS приложения, используя для написания тестовых скриптов JavaScript.

Вероятно, в Apple решили, что заботиться об удобстве работы программистов не настолько остро актуально в отличие от заботы о массовом пользователе... В общем Automation имеет ряд неприятных багов.

1 баг:
Кнопка нажимается с точки зрения Automation, но вы своими глазами видите на экране, что ничего не произошло. В таком случае я выхожу из положения так: я вставляю в скрипте цикл (обычно хватает 2-3 итераций), с помощью которого выясняю встроенными в Automation JavaScript-функциями произошло ли то, что должно произойти после нажатия (например, появилось ли окно, что можно проверить через myView.isVisible() && myView.isValid() условие)

2 баг:
Кнопка, контрол или что-нибудь ещё вообще никак не реагирует на нажатие, если это нажатие является первым нажатием по только что открытому окну. Спасает меня вот что: я с помощью скрипта "провожу пальцем" по тому месту (обычно это середина верхнего бара), где можно водить и это ни к чему не приведёт. После этого окно "оживает" и дальше уже можно нажимать на кнопку.

Продаю недорого 64-разрядный Хакинтош с установленной Mountain Lion

Продаю недорого 64-разрядный Хакинтош с установленной Mountain Lion (устанавливал хакинтошник-профи), я использовал его для iOS-разработки. Подробнее на http://do.ngs.ru/1101351267

Как прицеплять в Xcode-проект статические либы отдельно для Debug и Release

Это касается только Xcode 4 и более поздних версий:

ПЕРВЫЙ ТРУДОЁМКИЙ СПОСОБ: прицепить либы к дереву проекта намертво (вероятно можно и мышкой добавить нужные либы из Finder-папки перетаскивая их прямо в дерево проекта), но я делал это выходя в свойства проекта, потом переключался на вкладку Target, выбирал там Build Phases -> Link Binary With Libraries.

Этот первый способ плох тем, что Xcode порой глючит, и не в состоянии отличить дебаг-либу от релизной и может прицеплять дебаг-либу при релизной сборке приложения. Поэтому мне пришлось написать shell-скрипты, которые прятали в Temp-папки те либы, которые мне мешали и shell-скрипты для возвращения этих либ на прежние места. То есть перед Release-сборкой приложения все дебаг-либы можно аккуратно убрать одним запуском скрипта - при этом эти либы окрасятся в тревожный красный цвет в дереве проекта, но пусть это вас не пугает - приложение будет исправно собираться с оставшимися релизными либами.

НОВЫЙ ХОРОШИЙ СПОСОБ (пока плохо мной оттестирован): не добавлять либы первым способом в дерево проекта. Добавьте пути к нужным либам (включая имена файлов этих собранных либ) в настройках проекта и настройках таргета  -> Build Settings -> Linking -> Other Linker Flags (в подраздел Debug добавьте пути к дебаг-либам, в подраздел Release - к релиз-либам). Кроме того, вы можете в Debug/Release подразделы добавить вложенные подразделы для разных таргетов (для симуляторов и девайсов) - для этого найдите + кнопку справа внизу "Add Build Settings", нажмите на неё и выберите "Add Conditional Settings" (укажите пути для симуляторных и девайсовских дебаг/релиз либ).

Ссылки и статьи для iOS-программистов

Моя страница в Evernote, куда я сохраняю различные ссылки и фрагменты статей, интересующие меня как iOS-разработчика

Как отключать все вызовы NSLog для release-сборки

Опыт показывает, что перед release-сборкой очередной версии (для отправки в AppStore) комментировать десятки или даже сотни отладочных выводов в консоль слишком утомительно, да и не всегда полезно (некоторые выводы в консоль могут ещё пригодиться). Добавьте удобную макрофункцию где-нибудь в общий заголовок проекта (который включаете почти везде, например пусть это будет AppMacros.h).

#ifdef DEBUG
#define DLog(f, ...) NSLog(f, ## __VA_ARGS__)
#else
#define DLog(f, ...)
#endif

Теперь с помощью Find and Replace замените все NSLog на DLog. Если в некоторых исходниках вылезут ошибки компиляции, то добавьте в эти исходники #include "AppMacros.h"

О важности IBOutlet прикрепления объектов к объекту-хозяину

Очень важно, если вы решили часть рутинных операций возложить на такой удобный инструмент как Interface Builder не забывать об одном правиле. Каждый объект, который создаётся не динамически в коде (например smthObject = [[SmthClass alloc] initWith... ]), а создан с помощью Interface Builder, каждый такой объект должен иметь своего хозяина (разве что главный делегат приложения гарантированно работает по умолчанию).

То есть любой ваш объект (созданный с помощью Interface Builder) должен принадлежать кому-нибудь как IBOutlet-переменная. Я убеждался в этом уже много раз на практике. Иначе происходят падения программы при попытке заставить этот объект что-либо сделать, из-за того, что у этого объекта (если он не принадлежит никому как IBOutlet-переменная) например вызывается метод, а объект вроде не существует (раз ни к кому не принадлежит). Может быть гуру-программисты дадут более точное объяснение этому явлению...

О важности округления размеров GUI-контролов

Вчера мучался в догадках, почему под одной и той же ячейкой в UITableView (одна ячейка в одной группе, стиль выбран UITableViewStyleGrouped) появлялась одна и та же горизонтальная полосочка. Баг был явно привязан именно к этой ячейке.

Оказалось, что я задавал высоту ячейки не как целое или округлённое до целого число (то есть возвращал из метода heightForRowAtIndexPath значение с заметной на экране дробной частью).