World of Tanks Assistant (WOT Assistant) и World of Warplanes Assitant (WOWP Assistant) — это приложения–компаньоны для игроков, которые позволяют следить за внутриигровой статистикой, сравнивать свои боевые показатели с друзьями, а также предоставляют оффлайн-доступ к справочной информации по технике.


WOWP Assistant появился относительно недавно (ноябрь 2013), а версия для World of Tanks была переписана почти с нуля в начале 2013, что по времени совпало с переходом на новый Wargaming Public API. 

Надеюсь, наиболее технически интересные моменты разработки iOS-библиотеки для взаимодействия Assistant’ов с API будут полезны для разработчиков и послужат источником вдохновения для участников конкурса Wargaming Developers Contest.

Зачем

1. Зачем подменять ответ сервера?
Я всегда был и буду сторонником подхода, когда каждый отвечает за свою доменную область. И скажем, если сервер с API сломался, то обнаружить это должны юнит-тесты бэк-енда, а не свалившиеся тесты моего iOS-приложения.

2. Зачем использовать блоки, почему не target-action, делегирование и так далее?
Это личное предпочтение каждого, почти во всех ситуациях разрабатываемые мной объекты будут иметь блоковые коллбэки а не вызывать методы делегата. Для меня это работает и особых проблем с этим подходом я не испытал. В конце концов, блоки — это стильно, модно, молодежно!

Зачастую возникают ситуации, когда функционал используемой IDE хочется расширить. Везет, если разработчику предоставлены средства и документация для того, чтобы это сделать. К сожалению, в случае c Xcode это не так. Документирование возможностей остановилось на версии Xcode 3.0, так что никто не гарантирует, что в следующей версии написанный вами плагин заработает.

Предисловие

Этот топик не ставит своей целью рассказать о code coverage, и о том, нужно это средство или нет. Также, не будет подниматься вопрос о целесообразности тестов в iOS проектах (положим, что они все-таки кому-то нужы, а значит есть).

Мотивация

Очень удобно, когда средства для профилирования/анализа встроены в IDE. История С code coverage в xCode не совсем безоблачная: во времена xCode 3.x и GCC все было просто и нужные ссылки и флаги компилятора гуглились на раз. C приходом xCode 4.1 все стало немного сложнее ввиду использования LLVM-GCC, приходилось идти на некоторые ухищрения (вплоть до сборки LLVM своими руками). А в 4.3 библиотеку libprofile_rt переместили в другую директорию, что тоже вызвало немало проблем.

Постановка задачи

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

Решение

Решение в лоб — использовать данные из коллбеков [CLLocationManagerInstance startUpdatingLocation] как в фоне, так и когда приложение активно. Первый и наиболее критичный недостаток данного решения — высокое энергопотребление (за несколько часов аккумулятор iPhone может полностью сесть). Второй — если приложение будет свернуто и 'убито', никаких апдейтов положения пользователя мы получить не сможем.

Как и многие разработчики, я не очень люблю писать много кода, особенно там, где это кажется не нужным — на ранних стадиях стараюсь придумать, как этот код оптимизировать и обобщить. Что касается непосредственно Core Data, мне всегда казалось, что все эти бесконечные фетчи и создания новых объектов можно упростить. Тогда я открыл для себя часто упоминаемый на хабре паттерн ActiveRecord и его очень хорошую (на мой взгляд) реализацию на Objective-C — MagicalRecord. Углубляться в описание не буду — все очень доступно описано на странице проекта.
Следующим шагом упрощения должен был быть маппинг данных, поступающих извне.