В общем, не знаю, насколько это правильно/не правильно, постить и шарить такие знания ;) Но, во-первых, я считаю, что Apple такое не пропустит (это раз). А во-вторых, эту информацию можно спокойно найти на просторах интеренета… Главное, ее скомбинировать. Результат объединения знаний, найденных здесь и здесь, вы можете прочитать в статье.
Используйте на свой страх и риск. Для меня это работало и решило мою задачу. Я не несу ответсвенность за то, как ВЫ это будете использовать ;)
Понадобится на самом деле совсем немного. Для начала находим и добавляем из библиотек CoreTelephony.framework. Так как header’ы для него отсуствуют (все-таки Private API), нам понадобится файл хедера, который мы заберем у ericdasan. Все ненужные методы и структуры нам можно спокойно удалять. Нас интересует только вот этот метод :
- (BOOL)sendSMSWithText:(id)fp8 serviceCenter:(id)fp12 toAddress:(id)fp16;
Дальше – все просто:
#import "CTMessageCenter.h"
....
// SENDS SMS Without user prompt!!!
// ServiceCenter - nil - по идее использует SMS-сервисцентр по умолчанию
// Формат я не копал - потому что для меня задача решена ;) Но, скорее всего
// здесь просто номер сервисного центра SMS
[[CTMessageCenter sharedMessageCenter] sendSMSWithText:@"Cool!"
serviceCenter:nil
toAddress:@"+38091ХХХХХХХ"];
Исходный код прилагается
Разобравшись в основных понятиях Core Data, можно начинать им пользоваться. Для простоты и удобства, здесь и далее, будет предполагаться, что NSPersistenceStoreCoordinator, NSManagedObjectContext, NSManagedObjectModel уже созданы, и к ним есть доступ. Модель, которая будет использоваться в примерах, выглядит следующим образом:
Типы данных свойств объектов особого значения для примеров не имеют. Модель взята из “детского набора инженера-генетика”, который позволяет в домашних условиях выращивать животных нечто, с одним телом, одной головой, некоторым количеством рук и ног. Каждая часть тела имеет определенные свойства.
Начать стоит, как обычно, с заполнения БД. Необходимо напомнить, что Core Data – это не БД. Просто мы испольуем ее возможность сохранения данных из Core Data в БД. Статья полностью »
Объект – CoreData.
Задача – изучение параметров и возможностей.
Результат – получение общих понятий о возможностях и возможных применениях.
Итак. CoreData – что за зверь такой? Как говорит нам документация, это очень хороший и пушистый зверь, который всего лишь является надстройкой над конкретным хранилищем данных. а именно – над данными, которые хранятся в бинарном виде(CoreData-формат), XML, SQLite базе.
Что же все-таки позволяет сделать CoreData? Операции со сложными графами объектов, с множественными связями, валидацией, с возможностью осуществлять undo/redo операции на и… сохранять эти графы в некотором хранилище данных. Что получает от этого программист? Возможность не опускаться до уровня отщепенцев базы данных, не рассматривать проблему сериализации/десериализации, работая на уровне объектов.
Необходимо заметить, что CoreData справляется с этими задачами очень шустро, и не идет ни в какое сравнение по скорости и количеству кода с другими реализациями ORM под iPhone (будь то самописный ORM на основе SQLite, либо надстрока FMDB, либо SQLite Persistence Objects).
Кроме всего прочего, в SDK 3.0 появились специальные вспомогательные классы, позволяющие быстро интегрировать ввод/вывод данных, сохраненных с помощью CoreData. Так, при помощи NSFetchedResultsController можно без особых проблем использовать UITableView для отображения нескольких ТЫСЯЧ объектов. Статья полностью »
Интересно? Читаем дальше …
Сегодня столкнулись с такой проблемой как Error launching remote program: security policy error. Приложение удачно ставилось на iPhone/iPod, при запуске выдавалась ошибка прото ,что время действия Provisioning Profile’а истекло. Генерирование нового Provisioning profile’a и заливка его в XCode и, собственно на iPhone, ни к чему не привела – сообщение продолжало вылазить, и работа остановилась до нахождения лучших решений. Удаление всех профилей, кроме нового на iPhone’е тоже ничего не дало.
Немного помучавшись. и в результате нашли проблему.
Зайдя в Organizer в ХСode, можно увидеть примерно следующее:
То есть всего один из установленных профилей просрочен. Удаление просроченного профиля из Organizer’a решает данную проблему.
З.Ы. На скриншоте показаны только не просроченные профили, однако он дает понимание того, как бы выглядел список профилей, если бы хотя бы один из них был просрочен ;)
З.Ы.Ы. На самом деле причин и решений у этой (Error launching remote program: security policy error) проблемы может быть несколько. Однако, в нашем случае это всего лишь просроченный provisioning profile.
Если возникла необходимость “дать попробовать” ваше приложение заказчику/тестеру/друзьям и т.п. на этапе разработки, когда еще ничего не готово, и скачивать его из Apple Store нет возможности, и XCode у этих людей не установлен… То вы обречены Есть возможность распространения приложения через iTunes (.IPA файл). Среди большого количества людей таким образом распространить приложение не удастся (ограничение Apple на количество UUID(100 в год), привязанных к Developer-аккаунту), но для тестирования сойдет.
Для этого понадобится
- UUID телефон(ов) пользователя(ей), на которые необходимо установить приложение
- Provisioning profile, который включает эти UUID’ы
- XСode
Появилось немного свободного времени, и, наконец-то до меня добралась книга с названием iPhone Human Interface Guidelines.
Как известно, Apple довольно часто имеет склонность к отказам принятия приложений в AppStore. Мотивации бывают разные – дублирование функционала (Apple не любит программы, которые дублируют функционал программ, установленных по умолчанию), “запрещенный содержимое”, не соответсвие iPhone Human Interface Guidelines, сокращенно HIG. О последнем и пойдет речь. Чтобы уменьшить количество отказов от Apple (хотя бы в пределах нашей компании), я буду отмечать особенности из HIG, которые посчитаю “не вполне очевидными”, но на которых Apple заостряет внимание. То есть, в конце концов пост должен превратиться в краткую выдержку из HIG. Он будет дополняться по мере чтения книги, и по мере осознания дзен Apple. Все, кому лень читать книгу из 300 с лишним страниц – можете отслеживать прогресс ;) Статья полностью »
Но, как бы там ни было, прийдется начинать с вещей более-менее очевидных, но о которых все же, иногда забывают. Иногда я буду отмечать вещи, требующие особого внимания и не совсем очевидные.
Когда возникает необходимость создать в модели отношение «один ко многим» (такое, как показано на рисунке),

то может показаться, что обратные отношения ставить незачем, как и при отношениях «один к одному» . И действительно, ваше приложение запустится и не будет падать из-за этого, хотя компилятор и выдаст вам Warning’и. Но не все так просто… Статья полностью »
Просто обязан написать об этом:)
Сегодня выплыла проблема случайных крешей приложения, примерно следующего плана
EXC_BAD_ACCESS
objc_msgSend + 24
-[UIWebView webView:resource:didFinishLoadingFromDataSource:] + 80
-[UIWebViewWebViewDelegate webView:resource:didFinishLoadingFromDataSource:] + 36
Проверка на двойное и преждевременное освобождение объектов ничего не дала. То есть с памятью проблем небыло. Проблема была в чем-то другом. Судя по call-Tree, было сделано предположение, что UIWebView, вызывает метод делегата, который уже был удален из памяти. По сути, такого произойти не могло, так как обычно такими делегатами являются UIViewController’ы, которые в методе dealloc вызывают [webView release].
Но! Как оказалось, этого совсем недостаточно. Итак – решение проблемы. В методе dealloc, либо в любом месте, где вы прекращаете использовать объект, у которого вы прописаны делегатом, делайте следующее [webView setDelegate:nil]. В таком случае, даже если объект будет слать какие-то сообщения делегату, то приложение не будет вылетать с ошибкой.
Вывод:Как уже было сказано выше – всегда “обNULLяйте” делегата объекта. Ну, и пример кода соотвественно.
// ViewItemController.h
@interface ViewItemController : UIViewController < UIWebViewDelegate> {
UIWebView *webView;
}
@property(nonatomic, retain) IBOutlet UIVebView * webView;
@end
// ViewItemController.m
-(void)viewDidLoad {
[[self webView] setDelegate:self]
}
//
// На самом деле вполне "понятно", что после [webView release],
// совсем не факт, что webView уничтожится, ведь retainCount
// может быть все еще больше 0. Но для понимания этого
// нужно задуматься, а на это время не всегда хватает ;)
-(void) dealloc {
[webView setDelegate:nil];
[webview release];
[super dealloc];
}
Иногда бывает необходимо узнавать о том, когда клавиатура собирается появиться или спрятаться (например, когда текстовые поля находятся в таблице и приходится уменьшать высоту таблицы так, чтобы она вся была над клавиатурой). Для этого есть 4 типа уведомлений с такими именами:
- UIKeyboardWillShowNotification – клавиатура должна появится,
- UIKeyboardDidShowNotification – клавиатура появилась,
- UIKeyboardWillHideNotification – клавиатура должна спрятаться,
- UIKeyboardDidHideNotification – клавиатура наконец спряталась.
Так вот…
Статья полностью »
Многие, наверное, уже пробовали работать с CoreData и хотя бы краем уха слышали/краем глаза видели что-то о поддержке undo/redo для контекста объектов. Дело в том, что существуют механизмы, позволяющие при изменении объектов, унаследованных от NSManagedObject и находящихся в контексте NSManagedObjectContex, производить перемещение по т.н. контекстному графу при помощи методов undo и redo. Вершины этого графа создаются путем вызова у контекста метода processPendingChanges, после чего последующие изменения объектов в контексте можно откатить до их состояния на момент создания вершины методом undo. Также можно перемещаться между созданными вершинами, вызывая методы undo (к предыдущей вершине) или redo (к следующей вершине). За обработку и управление изменениями отвечает undoManager – объект класса NSUndoManager, который есть у объекта- контекста. Сдесь небольшое уточнение – есть, если только вы программируете под Mac OS. В iPhone SDK undoManager не инициализируется при инициализации контекста!
[context undoManager] == nil;// == YES !!!!!!!!















