Ниже описаны основы использования OCUnit — фреймворка для создания юнит-тестов, интегрированного в Xcode. Чтобы наглядно попробовать описываемые вещи, код можно скачать сразу. Писал до эпохи Xcode 4, поэтому картинки немного устарели.

Я провел настоящее исследование ситуации с автоматизированным тестированием интерфейса мобильных приложений. Речь идет не о тестировании модулей, а именно о тестировании интерфейса финального приложения. И, да, прямо на телефоне!

Зачем это нужно? В первую очередь, для гарантированного улучшения качества вашего ПО и улучшении настроения тестировщиков.

В чем идея? Чаще всего тестирование мобильных приложений осуществляется людьми: тестировщик берет приложение, iPhone 3, iPhone 4, iPad, если ему не повезло, то еще берет пару андроидов и GalaxyTab, и тестирует ваше приложение, 80% тестирования составляют примерно такие сценарии:
— запустить приложение, убедиться, что оно не падает;
— перейти на вкладку места, убедиться, что все пункты на месте;
— зайти в один из пунктов, убедиться, что описание на месте;
…

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

В свое время в вебе на помощь пришел Selenium, который позволил через специальный плагин к браузеру записывать действия тестировщика (все помнят макросы в MS Word?) и затем проигрывать их автоматически с проверкой результата. Можно запускать тесты даже на разных браузерах! Мы использовали это решение в своей компании, и оно, действительно, работает. Усилия на разработку тестов окупились.

По сравнению с вебом мобильная разработка еще очень молодая область, и я не ожидал увидеть хороших решений для автоматизированного тестирования интерфейсов. Оказалось, что их более чем достаточно. Хочу рассказать вам о некоторых из них.

Зачем

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

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

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

Однажды мне надоело, что исправление багов занимает у меня больше времени, чем разработка приложения, и в поисках путей решения я пришел к TDD — Test-driven development (Разработка через тестирование).

В это статье рассказывается как делать первые шаги в XCode 4.5, используя unit test-ы, при разработки приложений под IOS.

Статья предназначена для новичков, в ней не содержится информации для зубров разработки.

На хабре в прошлом месяце была опубликована статья Конкурс ВК: Мессенджер для Android. Как это было!, в которой автор поделился своими мыслями о конкурсе и опубликовал список ресурсов и статей, которые помогли ему в создании приложения. Так как в последнее время я начал изучать разработку под iOS, то у меня скопилось некоторое количество ссылок, которые могут быть полезны для начинающих. Поэтому я последую его примеру и сделаю то же самое, только для своей платформы. Надеюсь, кому-нибудь они окажутся полезны и сэкономят немного времени.

Вступление

В недавно вышедшем iOS 5 появился удобный механизм разработки интерфейса программы — Storyboard. Этот механизм позволяет заметно уменьшить количество кода связанного с переходами между экранами, показами Popover'a и даже с настрокой ячеек в таблице.

Задача: По нажатию на кнопку показать следующий экран поместив его в текущий NavigationController.
Решение без Storyboard:

DDetailViewController* nextController = [DDetailViewController new];
[self.navigationController pushViewController:nextController animated:YES];
[nextController release];

Решение с использованием Storyboard:


Вот и все! Никакого кода!

Привет уважаемое хабрасообщество, этот пост служит продолжением еще недавно активно обсуждаемой темы о социальных иконках [1] [2]. Мысль, которая пришла ко мне в голову после прочтения этих статей, привела к появлению нового вектора развития этой темы. Кстати о векторе, например бывает так, что дизайн разрабатываемого сайта или приложения имеет свою специфику и интегрировать стандартные иконки социальных сервисов без адаптации не представляется возможным. В таком случае мы берем в руки гугл и принимаемся за поиск нужных логотипов, для того чтобы создать подходящий набор иконок. Ах да я немного отвлекся, продолжим о векторе, чтобы не проделывать такие скучные действия, я собрал воедино несколько популярных иконок в векторе и теперь каждый желающий может сэкономить немного времени воспользовавшись им.

Игровые приложения для детей и взрослых скучны без веселых букв и цифр.
Строгий iPhone кодекс не давал разработчику до версии iOS 3.2 стандартных способов использовать свои шрифты в приложениях.
Все спасались нарисованными в редакторе картинками цифр и букв или чужими библиотеками.



Как теперь обстоит дело с custom fonts для разработчиков iPhone поделок?
Осторожно! Под хабракатом 1 картинка, 1 анекдот сомнение и 2 фрагмента кода.

Перевод не претендует на 100%-ную точность, но я постарался максимально точно передать мысли и слог автора. Комментарии приветствуются.

Начиная с Интернет Эксплорера 4 в 1998-ом, а затем с марта 2008-ого и до марта 2010-ого, один за другим, вся «большая пятерка» десктопных браузеров — Сафари, Файрфокс, Опера и Хром — выкатили сравнительно похожие реализации правила @font-face для привязки шрифтов. Вместе с тем, неотъемлимая часть веб-издательского паззла, часть, которой не хватает с начала Веба, встала на место и теперь настоящая, веб-ориентированая типографика начинает принимать форму.

Для начала, обзор последних событий:

1. 18-ого марта 2010 года была учреждена группа Web Fonts Working Group в W3C. Её первая задача была утвердить спецификацию WOFF как стандарт доставки sfnt (OTF и TTF) шрифтов в веб в «сжатом» виде.
2. Была представлена отрисовка шрифтов в IE9 с помощью Windows’s DirectWrite в IE9 Platform Preview.
3. Появились первые инструменты для подготовки веб шрифтов, такие как Font Squirrel’s @Font-Face Generator и EOTFAST.
4. Пошла новая волна «шрифтохранилищ» в виде Typekit, Typotheque и бесплатного, опенсорсного Kernest.
5. Появились первые “трастовые/кредитные” лицензии на веб-шрифты от дизайнеров коммерческих шрифтов.
6. CSS3 Fonts Module включил в себя некоторые продвинутые свойства OpenType.
7. Adobe Flash, когда-то надежная, кросс-платформенная среда замены текста (sIFR), сейчас выглядит абсолютно убогой.
8. Google запустил бесплатный сервис шрифтов с растущей библиотекой. Все шрифты в библиотеке доступны и для частного хранения/использования.

Теперь пройдемся по пунктам…

Предисловие

Приветствую вас хабролюди. Недавно сбылась мечта всей моей жизни и я купил себе Mac (13’ unibody). Поздний 2008, но для нашей деревни сойдет. С тех пор начал потихоньку вникать в разработку приложений для iOS (в частностни для iPhone).

Теперь ближе к делу. Я для начала решил написать простенькое приложение позволяющее создавать и просматривать заметки. Вот как оно выглядело в итоге:

Этот пост адресован в первую очередь начинающим (и не очень) разработчикам на iOS.
Часто в приложениях требуется разместить карту с метками на какие-то места. Стандартными средствами можно изменить картинку метки, во всплывающем окошке при щелчке на метку можно изменить заголовок, подзаголовок, картинку, а также добавлять справа кнопку или еще что-то.
При этом, все эти элементы могут быть только стандартного размера и будут выглядеть примерно так, как на картинке справа.

Но что, если требуется создать нестандартное всплывающее окошко, в которое можно будет разместить все, что угодно, (ну почти, все, что угодно) как на картинке слева?

Какое-то время назад я решил перепрофилироваться на разработчика под iOS, и решил систематизировать материал. Так сказать, составить свой roadmap. Получился некий обзор, которым я хотел бы поделиться с вами.
Данный обзор не претендует на полноту, непогрешимость и истину в последней инстанции.

Итак, вы приобрёли iPhone или iPad. Чудесные устройства, не правда ли? Какое-то время спустя пришла мысль “а не создать ли мне под него программу, которая завоюет мир?”. Я расскажу вам, с чего начать.

В этой небольшой статье расскажу про изменения во фреймворке UIKit, которые мне показались важными и полезными. Сразу оговорюсь — еще не имел возможности опробовать описываемые нововведения, так что статья в основном теоретическая.

NSAttributedString и UIKit

Для начала — то, что лично я ожидал еще в iOS 5 — поддержка NSAttributedString в текстовых компонентах — UILabel, UITextView, UITextField, а так же поддержка отрисовки строк с атрибутами и различные вспомогательные методы для этого. Конечно, весь этот функционал был доступен и раньше, используя Core Text, но работать с API стиля Core Foundation все же сложнее, так что можно смело ожидать улучшения поддержки форматирования текста (Rich Text) во многих сторонних приложениях. В качестве примера можно посмотреть стандартное приложение Mail.

Auto Layout в iOS

Очень важное нововведение — в iOS 6 появится Auto Layout от MacOS Lion. Теперь задавать положение компонентов интерфейса относительно друг друга станет проще. В кратце, Auto Layout позволяет задать набор ограничений (constraints), связывающих компоненты, например позволяет задавать границы размеров, зависимости между компонентами. Надеюсь это позволит облегчить создание интерфейса для нескольких языков (сейчас иногда приходится создавать отдельный nib/storyboard), включая арабские с написанием справа налево, а также упростит настройку интерфейса в зависимости от ориентации устройства. На данный момент документации для iOS по Auto Layout еще нет, нам предлагают документацию от MacOS.

В этой статье я рассмотрю метод создания блоков с одноцветным полупрозрачным фоном.
Например, таких:


Сразу оговорюсь, что я не буду использовать opacity и абсолютное позиционирование, чтобы разместить контент поверх полупрозрачного блока.