Objective C *

Хабралюди, добрый день!
Сегодня хочу начать написание ряда лекций с практическими заданиями по книги Михаеля Привата и Роберта Варнера «Pro Core Data for iOS», которую можете купить по этой ссылке. Каждая глава будет содержать теоретическую и практическую часть.



Содержание:

• Глава №1. Приступаем (Практическая часть)
• Глава №2. Усваиваем Core Data
• Глава №3. Хранение данных: SQLite и другие варианты
• Глава №4. Создание модели данных
• Глава №5. Работаем с объектами данных
• Глава №6. Обработка результатирующих множеств
• Глава №7. Настройка производительности и используемой памяти
• Глава №8. Управление версиями и миграции
• Глава №9. Управление таблицами с использованием NSFetchedResultsController
• Глава №10. Использование Core Data в продвинутых приложениях

Apportable SDK — это продукт, который позволяет без изменений скомпилировать игру (или приложение), разработанное на Objective-C/Cocoa Touch для iOS под Android. Это полный toolchain (компилятор, дебаггер, линковщик — все-все-все), работающие Foundation, CoreFoundation, UIKit, множество других фреймворков из состава iOS, перенесенные на Android (даже такая «мелочь» как GameKit и StoreKit, с бэкендами для GooglePlus и Amazon GameCircle/Appstore).

Цель Apportable — дать iOS разработчику перенести свое приложение на Android за час, без изменения кода, и поддерживать после этого одну кодовую базу. Как портировать простую игрушку на cocos2d — под катом

Поясню для начинающих, что при разработке под iOS для установки на девайс большую часть времени вы собираете приложение в development режиме, т.е. только для себя.
Но в какой-то момент требуется начинать выдавать заказчику результат работы на «посмотреть».
Для этого используется особый вид сборки AdHoc Distribution. Нужно сходить к Apple'у и создать distribution provisioning profile. После чего собирать приложение, подписывая его этим профилем. В профиле прописываются все идентификаторы девайсов, на которые планируется это приложение устанавливать на этом этапе. В итоге при билде под AdHoc, XСode создает файл с расширением .ipa, который уже можно установить на все, прописанные в профиле, девайсы. Например через iTunes.

Возникает вопрос как лучше всего передать вашему клиенту получившуюся сборку. Да, можно просто отправить файл по почте например, или выложить на файлообменник и пусть бедняга сам устанавливает его через iTunes на свой девайс. Но если вы цените время своего клиента или вам лень объяснять ему как это сделать, ну или вы просто милый и приятный человек, то вам стоит задуматься, а нет ли другого, более удобного способа.

Об одном из таких способов, с автоматизацией выдачи из Xcode читаем под катом!

Друзья.
Сегодня речь пойдёт о создании красивых бэкграундов в iOs приложениях с точки зрения программиста, расчёте их разрешений, специфики разных Apple устройств и обходе подводных камней. Многое из этого для большинства iOs разработчиков покажется очевидным, но я буду рад, если для некоторых это станет инструкцией при непосредственной работе.

Итак, мы должны ответить на следующие вопросы:

1. Какие разрешения выбирать для картинок.
2. Как именовать картинки.
3. Как это использовать.

Недавно появилась задача — встроить в приложение динамический поиск информации, то есть выдача должна генерироваться параллельно вводу пользователем символов. Вся информация хранится в SQLite базе данных. Все бы ничего, но в каждом слове выдачи искомые символы должны подсвечиваться.
Было принято волевое решение не использовать внешние библиотеки, а попробовать обойтись своими силами.

Добрый вечер!

Всё началось с того, что необходим был более или менее удобный инструмент для работы с API социальной сети ВКонтакте под iOS. Однако Google меня достаточно быстро расстроил результатами поиска:

• StonewHawk — GitHub
• maiorov/VKAPI — GitHub
• AndrewShmig/Vkontakte-iOS-SDK (да-да, с первой версией было не всё так хорошо, как могло показаться с первого взгляда)

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

Под катом я расскажу, как работает обновленная версия ВКонтакте iOS SDK v2, с чего всё начиналось и к чему в итоге пришли.

Магические константы в коде — зло. Строковые константы в коде — еще большее зло.
И вроде бы от них никуда не денешься, они повсюду:

1) При загрузке объектов из xib-ов:

MyView* view = [[[NSBundle mainBundle] loadNibNamed:@"MyView" owner:self options:nil] lastObject];

MyViewController* controller = [MyViewController initWithNibName:@"MyViewController" bundle:nil];

2) При работе с CoreData:

NSFetchRequest *request = [[NSFetchRequest alloc] init];
[request setEntity:[NSEntityDescription entityForName:@"MyCoreDataClass" inManagedObjectContext:moc]];
[request setSortDescriptors:@[ [[NSSortDescriptor alloc] initWithKey:@"someProperty" ascending:NO] ]];

3) Если вы используете KVO, то строки появляются и тут:

[self addObserver:someObservedObject 
       forKeyPath:@"someProperty"
          options:(NSKeyValueObservingOptionNew |  NSKeyValueObservingOptionOld) 
          context:nil];

4) Ну и KVC:

NSInteger maxValue = [[arrayOfMyClassObjects valueForKeyPath:@"@max.someProperty"] intValue];

5) Но даже если CoreData вы предпочитаете работу с SQLite напраямую, xib-ами вы брезгуете, то вот такой код вам должен быть знаком:

[self.tableView dequeueReusableCellWithIdentifier:@"MyTableViewCell"];

6) Ну и когда Apple представила миру Storyboard — это было замечательно, если-бы не одно но:

[self performSegueWithIdentifier:@"MySegue" sender:nil]

-(void)prepareForSegue:(UIStoryboardSegue *)segue sender:( id )sender {
   if ( [segue.identifier isEqual:@"MySegue"] );
}

Вы видите проблему? Она состоит в том, что компилятор никак не проверяет содержимое строк, поскольку не знает (да и не может в принципе знать), что в них содержится. И если вы опечатаетесь или измените значение соответствующих полей в xcdatamodel / xib / storyboard / переименуете property, то ошибка вылезет не на стадии компиляции, а в рантайме, и отловить и исправить ее будет дольше и дороже.
Так что-же можно сделать?

Добрый вечер!

Всё началось с того, что необходим был более или менее удобный инструмент для работы с API социальной сети ВКонтакте под iOS. Однако Google меня достаточно быстро расстроил результатами поиска:

• StonewHawk — GitHub
• maiorov/VKAPI — GitHub

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

Под катом я расскажу, как работает новая версия ВКонтакте iOS SDK, с чего всё начиналось и к чему в итоге пришли.

Здравствуйте, дорогие читатели Хабра!

Уже довольно давно работаю фрилансером и иногда беру пару-тройку простеньких проектов за $100-200 для разгрузки мозга. В этот раз клиент попросил использовать внешние кнопки регулировки громкости в iPhone. Проблема состояла в том, что встроенного API для внешних кнопок в iOS не существует: до недавних пор использование хардверных элементов устройства, отличное от системного поведения, было запрещено. Поэтому различные приложения типа «Camera+» и «Camera Pro» никак не могли донести подобный функционал до пользователя. Однако, по счастливой случайности, в iOS 5 разработчики Apple сами начали использовать подобный подход к интерфейсу: сделать фотографию в системном приложении камеры теперь можно, нажав на клавишу увеличения громкости.

Как реализовать подобное поведение внешних клавиш в своем приложении, смотрите под катом. Исходники прилагаются в конце статьи.

Или сказ о том, как разработка JSON валидатора превратилась в очередной JSON binding

Пока нормальные разработчики пишут приложения я изобретаю велосипеды.

Наверное многие разработчики сталкивались с ситуацией, когда мобильное приложение разрабатывается параллельно с бэкэндом. При этом частенько структуры данных, приходящие в ответ на запрос с сервера, могут меняться. Например, на стороне бэкэнда решат поменять именование одного из ключиков JSON-а, забыв предупредить о этом мобильную команду. Я уже не говорю про ситуации, когда CamelCase нотацию «внезапно» решили поменять на underscore или наоборот. Вы можете сказать, что налицо плохая организация процесса и недостаток общения команд, и будете абсолютно правы. Но когда приложение на смартфоне заказчика перестает работать на демо все взгляды устремляются на мобильщиков.

Всем привет,

Прошло совсем не много времени, с тех пор как я начал изучать Objective-C, но я начал работать над серьезным приложением. И передо мной стали различные задачи(проблемы), как реализовать то или это. Хочу поделится с вами одним из решений, одной из своих задач.

Итак начнем-с. Передо мной стала задача написать приложение биллинга для одного израильского мобильного оператора, в котором можно проверить состояние счета и выполнять некоторые настройки для своих мобильных линий.




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

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

NSURLCache — это комплексное решение для кеширования сетевых запросов в оперативной памяти или на диске. В соответствии с документацией Apple, любой запрос с использованием NSURLConnection будет «пропущен» через NSURLCache.

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

В данном посте я хочу обратиться к теме, о которой многие начинающие iPhone-разработчики часто имеют смутное представление: Objective-C Runtime. Многие знают, что он существует, но каковы его возможности и как его использовать на практике?
Попробуем разобраться в базовых функциях этой библиотеки. Материал основан на лекциях, которые мы в Coalla используем для обучения сотрудников.

В этом небольшом 15-минутном видео Юра Digal Буянов (ведущий iOS-разработчик e-Legion) расскажет о тонкостях работы с блоками в Objective-C.



Мы решили сделать целый ряд коротких видео о разработке (не только мобильной), дизайне и маркетинге. Чтобы не пропустить выход новых материалов, вы можете подписаться на Хабра-блог или на youtube-канал.

Принимаются советы, рекомендации, а также заявки на интересующие темы, которые можно раскрыть в следующих видео.

Мы рады сообщить, что сегодня официально стал доступен AppCode 2.0. В этот релиз мы добавили поддержку популярного фреймворка для тестирования Kiwi. В новый AppCode интегрированы два внешних браузера документации Dash и Ingredients.

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

Привет Хабр!

Предыстория

Давно заметил, что на хабре нет ни одной статьи о такой замечательной библиотеке как RestKit, написанной на Objective-C и предоставляющая прекрасные возможности для работы с RESTful-сервисами. Поэтому и пришла идея опубликовать краткое описание некоторых возможностей библиотеки, тем более что уже вышла совершенно новая её версия использующая за основу AFNetworking библиотеку для работы с HTTP. В статье описывается одна из важнейших для меня функциональностей — маппинг объектов.

По специфике работы мне приходится вести несколько (5-10) проектов одновременно, и часто возвращается к кодированию проекта после значительной паузы, месяц и более. Такая особенность требует организации кода, которая позволит очень быстро вспомнить архитектуру проекта.

Так же для экономии времени и ресурсов я использую общие классы для MacOS и iOS версий моего приложения.
Для тех, кому интересны особенности моего опыта — прошу под кат.

Даная статья является продолжением «Переопределение реализации метода. Вдохновленный Java'ой». В предыдущей заметке было предложено слишком уж кривое решение, оставлять в таком виде не хотелось и было принято волевое решение довести свое начинание до логического завершения и сделать все «как надо». Хотя вопрос нужности такого функционала в Objective-C до сих пор открыт.


Итак, продолжаем быть похожими на Java

Продолжение можно почитать тут habrahabr.ru/post/170265

Вступление

Изучая основы разработки под Android мне пришлось познакомится с таким замечательным языком, как Java. Читая очередной раздел гугловского GetStarted я наткнулся на такую конструкцию:

Button.OnClickListener mTakePicSOnClickListener = 
		new Button.OnClickListener() {
		@Override
		public void onClick(View v) {
			
		}
	};

Объявление представителя OnClickListener и переопределения у него метода onClick (поправьте меня Java программисты). Хм, подумал я, а круто бы эту фичу поиметь в Objective-C, а именно возможность переопределять реализацию метода у объекта(конкретного объекта, а не реализацию метода для всех объектов класса) да еще и через блоки в runtime (!) и забыл о этом всем… пока не оказался в полупустом автобусе в дождливую погоду. Времени было много и я решил поразмыслить над тем, что же тут можно сделать.
Зачем это нужно было? Изначально хотелось уметь делать так:

tableView1.delegate = [[NSObject new] override:@selector(tableView:didDeselectRowAtIndexPath:) imp:^void(NSIndexPath* ip){
       NSLog(@"selected row %i", ip.row);
}]
tableView2.delegate = [[NSObject new] override:@selector(tableView:didDeselectRowAtIndexPath:) imp:^void(NSIndexPath* ip){
       NSLog(@"selected row %i", ip.row);
}]

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

Тем самым местом я чувствовал, что это вполне реализуемо благодаря богатому внутреннему миру Objective-C Runtime.
И да, то самое место меня не подвело.

Многие, вероятно, знают, что при работе с событиями изменения свойств с помощью key-value observing существует очень удобный механизм, предотвращающий появление в приложении «метрвых» объектов, которые представляют собой получателей вызовов. В действительности, первый же мертвый объект «валит» приложение, при поступлении ему события — это закономерно, так как объект уже не существует и никаких методов вызвать у него уже не получится.

Поиск таких объектов мог быть затруднен, если бы не замечательная в отладке вещь под названием NSKVODeallocateBreak, которая позволяет прервать выполнение приложения в момент, когда уничтожается объект, подписанный на события, чтобы отследить время его жизни и убрать проблему.

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

Данная статья рассчитана на разработчиков, имеющих опыт работы с платформой и знающих, каким образом определяется жизненный цикл объекта. Если у вас есть определенные пробелы в этой области (а я неоднократно встречал даже опытных разработчиков, которые не знают, каким образом работает счетчик ссылок и не представляющих, во что разворачивается @synthesize), то вы можете прочитать мою старую статью, посвященную исследованию данного вопроса. Остальных прошу к столу.