Xcode *

Предисловие

Недавно Apple представила общественности достаточно важное изменение в разработке iOS приложений, анонсировав новый язык программирования Swift. Я принял решение: изучая этот язык пошагово, я буду в своих статьях рассказывать обо всём, что мне удалось найти. Это лишь первый пост из многих на эту тему, но я надеюсь, что вы решите изучать язык вместе со мной!

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

Итак, я собираюсь начать с довольно простого приложения. Также я буду объяснять, как работает код. Готовы? Поехали…

Возьмём за основу статью Знакомьтесь, Swift!, где показано как сделать простое приложение на Swift, и добавим туда такие известные и полезные штуки как pull to refresh и infinite scrolling используя встроенные возможности языка. Чтобы было еще интереснее, добавим немного асинхронности, иначе приложение будет каждый раз замирать на время обновления.

Меня зовут Митя Куркин, я руковожу разработкой iOS мессенджеров Mail.Ru Group. Сегодня я расскажу о нашем опыте ускорения приложений на iOS. Высокая скорость работы очень важна для 99% приложений. Особенно это актуально на мобильных платформах, где вычислительные мощности и, соответственно, заряд аккумулятора весьма ограничены. Поэтому каждый уважающий себя разработчик стремится оптимизировать работу своего приложения с целью устранения различных задержек, из которых складывается общее время реакции.

Компания «Deque Systems» представила бета-версию WorldSpace Xcode Plugin, который интегрируется в Xcode и автоматически анализирует исходный код проекта на предмет правильного указания всех атрибутов доступности. Плагин также предоставляет контекстную справку по методам решения тех или иных проблем accessibility в iOS. Кроме того, он может быть встроен в Continuous Integration.

С помощью этого инструмента можно легко включить поддержку VoiceOver в процесс разработки на постоянной основе, так как он позволяет нажатием пары кнопок отловить базовые проблемы невизуальной доступности интерфейса. Плагин использует растущий набор правил, основанных на базе критериев стандарта WCAG 2.0.

Статья является своеобразным продолжением статьи «Знакомьтесь, Swift!» за авторством Helecta, а также вольным переводом статьи Developing iOS Apps Using Swift Tutorial Part 2.



Итак, в первой статье мы написали простое Single View приложение, включающее таблицу с несколькими ячейками.
На этот раз мы немного углубимся и сделаем несколько более амбициозных вещей. Мы будем обращаться к API поиска iTunes, парсить ответ, полученный в JSON и отображать результаты в Table View.
На первый взгляд может показаться, что все это довольно сложно и предстоит много работы, но на самом деле это не так. Все описанное выше является достаточно простым функционалом для iOS приложений и каждый уважающий себя iOS разработчик должен это уметь.

Зачесались у меня тут руки узнать, что это за зверь такой Swift и с чем его собственно едят. Как и ожидалось проблем и подводных камней пока оказалось много, ну либо я совсем не умею этот Swift готовить. Самая большая проблема ожидала меня при попытке подружить этот самый Swift с CoreData — штука принципиально отказывалась работать. Обильное гугление не приводило к хоть каким-либо хорошим результатам — информация была либо крайне обрывочной, либо попахивала костылями. Посему в первый вечер терзаний я капитулировал и решил использовать самое тупое решение в работе с CoreData по-старинке — хранить весь код в старом добром Objective-C и уже к нему обращаться из Swift (например в интерфейсах). Однако, перфекционизм в душе не давал покоя и требовалось реализовать чистое одноязычное решение, что я собственно и смог сделать, хотя признаться и не без костылей тоже. Кому интересен процесс прошу под кат. Также попутно предлагаю собирать баги и не самые на мой взгляд удобные вещи, которые пришли вместе с новым языком. Возможно, что-то я сделал криво — буду благодарен комментариям и поправкам, а также обсуждению лучших практик.

2 июня на конференции WWDC 2014 Apple представила новый объектно-ориентированный язык программирования — Swift. Я думаю, многие уже успели посмотреть, что из себя представляет этот язык (Swift — нововведения), поэтому я не буду останавливаться на нововведениях. Я предлагаю создать простенький проект на языке Swift, чтобы понять на деле основные отличия от привычного Obj-C.

Мне было интересно попробовать написать приложение для iOS, чисто в познавательных целях, но 99USD платить Apple за «любознательность» не очень то и хотелось. Не отчаивайтесь, для таких как мы есть способы и запустить приложение и отладить его на целевом устройстве.

Я хотел научиться работать с oracle из xcode, так как не обнаружил готового фреймворка от apple для работы с базой данных oracle напрямую.
Для начала, я попробовал создать тестовый проект и подключить к нему instantclient от oracle. Также я использовал тестовый пример от Oracle ( cdemo81.c ), включил его код в проект на xcode и протестировал работу. Да, все работает, хотя пришлось немножко побить в шаманский бубен от google. Тем не менее, использовать напрямую oci библиотеку тяжело, так как нужно реализовать интерфейс, а это похоже на изобретение велосипеда.
Тогда я решил попробовать использовать кросс-платформенную библиотеку ocilib ( http://orclib.sourceforge.net )
Далее в тексте пошаговая инструкция о том, как сделать тестовый проект на cocoa и использовать эту библиотеку. Цель тестового проекта — подключив библиотеку получить данные с сервера oracle.

Данный туториал описывает создание плагина для Clang и покрывает следующие шаги:

• настройка окружения
• создание базового плагина
• создание Xcode-проекта для разработки плагина
• генерирование предупреждений
• генерирование ошибок
• интеграция плагина в Xcode
• интерактивные подсказки по устранению предупреждений и ошибок

TL;DR

Готовый плагин можно найти здесь

Основную идею данной заметки в принципе можно уместить в одном предложении: «раз уж вы пишете тесты, то неплохо было бы прогонять их на всех возможных конфигурациях, а не на одной единственной». Но поскольку формат однострочных статей на хабре не принят, а информация усваивается пропорционально логарифму количества слов в объяснении, то раскрою мысль подробнее.

Quick Help научился брать документацию из комментариев: