Как называется встроенный в ios sdk фреймворк для хранения данных persistence

Обновлено: 30.06.2024

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

Вступление

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

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

Файловая система и песочница приложений

Безопасность на платформе iOS была одним из главных приоритетов Apple с тех пор, как iPhone был представлен в 2007 году. В отличие от приложений OS X, приложение iOS находится в изолированной программной среде. Песочница приложения не только ссылается на каталог песочницы приложения в файловой системе. Он также включает в себя контролируемый и ограниченный доступ к пользовательским данным, хранящимся на устройстве, системным службам и оборудованию.

С появлением Mac App Store Apple начала применять изолированную программную среду приложений в OS X. Хотя ограничения, накладываемые на приложения OS X, не такие строгие, как ограничения, накладываемые на приложения iOS, основная концепция аналогична. Хотя есть и отличия. Например, в изолированной программной среде приложения для iOS содержится пакет приложений, чего нельзя сказать о приложениях OS X. Причины этих различий в основном исторические.

Песочница и каталоги

Операционная система устанавливает каждое приложение iOS в каталог песочницы, который содержит каталог пакета приложений и три дополнительных каталога, Documents , Library и tmp . Доступ к каталогу песочницы приложения, часто называемому его домашним каталогом, можно получить, вызвав простую функцию Foundation, NSHomeDirectory() .

Вы можете попробовать это сами. Создайте новый проект Xcode на основе шаблона приложения Single View и назовите его « Постоянство данных».

Откройте AppDelegate.swift и добавьте приведенный выше фрагмент кода в application(_:didFinishLaunchingWithOptions:) . Если вы запустите приложение в симуляторе, вывод в консоли должен выглядеть примерно так:

/Users/Bart/Library/Developer/CoreSimulator/Devices/14F00EFB-2EAB-438C-B401-7FEFDA1D94AB/data/Containers/Data/Application/81B23594-3BA2-4AF9-B91A-F74A53FD6945

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

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

Мы вызываем NSSearchPathForDirectoriesInDomains() , которая определена в платформе Foundation. В качестве первого аргумента мы передаем DocumentDirectory типа NSSearchPathDirectory чтобы указать, что нас интересует только каталог документов приложения. Второй и третий аргументы имеют меньшее значение для нашего обсуждения. Функция возвращает массив типа [String] , содержащий один результат, путь к каталогу документов приложения.

Почему песочница?

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

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

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

Что идет куда?

Несмотря на то, что вы можете делать практически все, что захотите, в песочнице своего приложения, Apple предоставила несколько рекомендаций относительно того, что и где хранить. Об этих рекомендациях важно знать по нескольким причинам. Когда резервное копирование устройства iOS выполняется на ваш компьютер или в iCloud, не все файлы в песочнице включаются в резервную копию.

Например, каталог tmp следует использовать только для временного хранения файлов. Операционная система может свободно очищать этот каталог в любое время, например, когда на устройстве недостаточно места на диске. Каталог tmp не включен в резервные копии.

Каталог Documents предназначен для пользовательских данных, а каталог Library — для данных приложения, которые не привязаны строго к пользователю. Каталог Caches в каталоге Library — это еще один каталог, для которого нет резервных копий.

Также имейте в виду, что ваше приложение не должно изменять содержимое каталога комплекта приложений. Каталог комплекта приложений подписывается при установке приложения. Изменяя содержимое каталога комплекта приложений любым способом, вышеупомянутая подпись изменяется, что означает, что операционная система не позволяет приложению снова запускаться. Это еще одна мера безопасности, введенная Apple для защиты клиентов.

Параметры сохранения данных

Существует несколько стратегий хранения данных приложения на диске. В этой статье мы кратко рассмотрим четыре распространенных подхода на iOS:

система по умолчанию
списки свойств
SQLite
Основные данные

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

Пользователь по умолчанию

Система по умолчанию — это то, что iOS унаследовала от OS X. Несмотря на то, что она была создана и предназначена для хранения пользовательских настроек, ее можно использовать для хранения любого типа данных, если это тип списка свойств, NSString , NSNumber , NSDate , NSArray , NSDictionary и NSData или любой из их изменяемых вариантов.

А как насчет типов данных Swift? К счастью, Свифт достаточно умен. Он может хранить строки и числа, конвертируя их в NSString и NSNumber . То же самое относится к массивам и словарям Swift.

Система по умолчанию — это не что иное, как набор списков свойств, по одному списку свойств на приложение. Список свойств хранится в папке « Предпочтения » в папке « Библиотека » приложения, что указывает на назначение и функцию списка свойств.

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

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

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

Приступаем

Что такое Core Data?

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

Apple предоставляет гибкий фрэймворк для работы с хранимыми на устройстве данными — Core Data. Конечно же Core Data не панацея и есть другие варианты хранения данных, которые могут лучше подойти при решении определенных задач, но уж очень хорошо и красиво Core Data вписывается в Cocoa Touch. Большинство деталей по работе с хранилищем данных Core Data скрывает, позволяя вам сконцентрироваться на том, что действительно делает ваше приложение веселым, уникальным и удобным в использовании.

Не смотря на то, что Core Data может хранить данные в реляционной базе данных вроде SQLite, Core Data не является СУБД. По-правде Core Data в качестве хранилища может вообще не использовать реляционные базы данных. Core Data не является чем-то вроде Hibernate, хотя и предоставляет некоторые возможности ORM. Core Data скорее является оболочкой/фрэймворком для работы с данными, которая позволяет работать с сущностями и их связями (отношениями к другим объектами), атрибутами, в том виде, который напоминает работы с объектным графом в обычном объектно-ориентированном программировании.

Знаете ли Вы?

Core Data был внедрён лишь начиная с Mac OS X 10.4 Tiger и iPhone SDK 3.0

История хранения данных в iOS

Как за выпущенные Pixar мультфильмы мы должны благодарить компанию NeXT, так и за Core Data мы должны сказать ей спасибо. Core Data родилась и эволюционировала из технологии, называемой Enterprise Objects Framework (EOF).
Дебют фрэймворка приходится на 2005 год с запуском Mac OS X 10.4 (Tiger), а вот в IPhone появляется лишь начиная с версии 3.0.
До того, как Core Data пришла на IPhone, разработчикам приходилось не сладко и для хранения данных могли быть использованы следующие варианты:
1) Списки свойств, которые содержали пары ключ-значение из различных типов данных.
2) Сериализация данных и хранение их в файлах (использовался протокол NSCoding)
3) Реляционная база данных SQLite
4) Хранение данных в облаке

Эти методы всё еще продолжают использоваться, хотя и ни один метод из четырёх не сравнится по удобству с использованием Core Data. Несмотря на рождение таких фрэймворком, как FMDatabase и ActiveRecord, для решения проблемы с хранением данных до появления Core Data, разработчики с удовольствием переключились на Core Data после его появления.
Хотя повторюсь, что Core Data не является лекарством от всех болезней, иногда вы конечно будете обращаться к решениям с использованием, например, списка свойств, но чаще всего вы будете сталкиваться с необходимостью и желанием использовать в своих приложениях именно Core Data, как инструмент, который наилучшим образом позволяет решить вашу проблему.
Чем чаще и чем больше вы будете программировать и использовать Core Data, тем чаще у вас будет возникать не вопрос «Стоит ли мне использовать Core Data?», а «Есть ли причина не использовать Core Data?».

Создание простого приложения с Core Data

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

Понимание основных компонентов Core Data

Перед тем, как погрузиться в код и разбор тестового приложения, необходимо иметь представление о компонентах Core Data. На рисунке ниже продемонстрированы основные элементы, которые мы будем использовать в тестовом приложении.

Как пользователь Core Data вы никогда не должны работать напрямую с хранилищем данных. Абстрагируйтесь от хранилища, от типа хранилища, думайте только о данных! Особенностью такого подхода является возможность безболезненно сменить тип хранилища (был XML файл, а стал SQLite) не меняя большое кол-ва написанного вами кода.
Объекты, которые находятся под управлением фрэймворка (Core Data) должны наследовать методы/свойства класса NSManagedObject.
Так же, как и людям, объектам нужна среда в которой они могут существовать, такая среда есть и, называется она managed object context (среда управляемых объектов) или просто context. Среда, в которой находится объект, следит не только за тем, в каком состоянии находится объект с которым вы работаете, но и за состояниями связанных объектов (объектов, которые зависимы от данного и от которых зависим он сам).
Экземпляр класса NSManagedObjectContext предоставляет ту самую среду для объектов, объект данного типа должен быть доступен в вашем приложении всегда. Обычно экземпляр класса NSManagedObjectContext является свойством делегата вашего приложения. Без среды, без экземпляра класса NSManagedObjectContext вам просто не удастся работать с Core Data.

Создание нового проекта

Запустим XCode и создадим новый проект из шаблона Master-Detail Application:

Заполним поля следующим образом:

И после завершения создания увидим примерно такую картину:

Запускаем наш проект

Перед тем как начать разбираться, что находится под капотом данного приложения, давайте запустим и разберемся, что вообще делает приложение.
Жмём на кнопку «Run» и перед нами появится вот такое:

Нажмем несколько раз на кнопку с "+" и в списке появится несколько записей со временем.

Теперь завершим (остановим) работу приложения и, если приложение не использовало бы Core Data для хранения данных, то при очередном запуске мы увидели бы пустой список снова, однако после перезапуска мы видим всё ту же картину:

Разбираем составляющие приложения

Структура приложения относительно проста. В наличие имеется модель данных, которая описывает сущность хранимую в базе данных (хранилище); контроллер, который облегчает взаимодействия между экраном (таблицей) и хранилищем данных; делегат приложения, который помогает инициализировать и запустить приложение.
На изображении представленном ниже показаны классы используемые в приложении и как они соотносятся друг с другом:

Обратите внимание на то, что класс MasterViewController содержит свойство, которое ссылается на экземпляр класса NSManagedObjectContext для взаимодействия с Core Data. Пройдясь по коду можно увидеть, что MasterViewController получает managed object context из свойства делегата приложения.

BasicApplication.xcdatamodel представляет собой директорию в файловой системе, которая содержит информацию о структуре модели данных. Модель данных является основой каждого приложения использующего Core Data.
Модель данных данного приложения описывает лишь одну сущность — Event. Сущность Event содержит лишь одно свойство (поле, атрибут) — timeStamp типа Date.

Сущность Event типа NSManagedObject, который считается основным для всех сущностей находящимся под управлением Core Data. Во второй главе мы рассмотрим тип NSManagedObject более подробно.

Извлечение/выборка данных

Следующим классом, который нас интересует, является MasterViewController. В его заголовочном файле описаны два свойства на которые мы обратим внимание:

NSFetchedResultsController представляет собой контроллер, предоставляемый фрэймворком Core Data для управления запросами к хранилищу.
NSManagedObjectContext является известной нам уже средой существования объектов типа NSManagedObject.

Реализация класса MasterViewController, которую можно найти в файле MasterViewController.m, показывает, каким образом можно взаимодействовать с Core Data для получения и хранения данных. В реализации класса MasterVIewController имеется явный геттер fetchedResultsController, который производит предварительную настройку запроса на выборку данных из хранилища.

Первым шагом к осуществлению запроса на выборку данных является создание запроса:

Результаты запроса могут быть отсортированы при помощи NSSortDescriptor. NSSortDescriptor определяет поле для сортировки и тип сортировки (по возрастанию или убыванию).
В нашем примере сортируем по убыванию времена создания записей:

После того, как запрос определен, мы можем приступить к созданию NSFetchedResultsController.
Используя в качестве делегата NSFetchedResultsController MasterVIewController мы можем следить за состоянием данных хранилища (удаление, добавление, перемещение и тд) и безболезненно интегрировать данное решение с UITableView. Мы можем конечно же получить те же результаты вызывая метод executeFetchRequest в managed object context, но в таком случае мы не получим и не сможем воспользоваться всеми преимуществами NSFetchedResultsController.
Создание и настройка переменной экземпляра класса NSFetchedResultsController:

Вы наверно заметили, что используемый ранее метод initWithFetchRequest имеет параметр cacheName. При передаче в качестве аргумента nil Вы исключаете возможность кэширования результата запроса, но при указании наименования кэша, вы позволяете Core Data проверить наличие такого же ранее осуществленного запроса и вернуть результат из кэша. В противном случае, если запроса с таким именем кэша нет, то будет осуществлен запрос к хранилищу и возвращены необходимые данные, которые будет закэшированы впоследствии.

В завершение нам осталось только выполнить запрос для получения данных:

Ниже вы можете ознакомиться с полным геттером fetchedResultsController:

NSFetchedResultsController представляет собой нечто вроде коллекции объектов типа NSManagedObject, для этого у него даже имеется свойства fetchedObjects типа NSArray для получения доступа к результатам запроса.
Класс MasterVIewController, который так же расширяет возможности UITableViewController, демонстрирует нам насколько удобно использовать NSFetchedResultsController для управления содержимым таблиц.

Вставка нового объекта

Быстро окинув взглядом метод insertNewObject: станет понятно, каким образом создаются и добавляются новые события в хранилище. NSManagedObject определяются описанием сущности из модели данных и могут существовать только в определенном контексте (среде). Первым шагом для создания нового объекта является получение контекста в котором этот объект будет создан:

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

Полный метод добавления нового объекта представлен ниже:

Инициализация контекста (среды)

Очевидно, что всё, что мы раньше делали не может быть достигнуто без создания объекта контекста, без той самой среды в которой существует и живет объект. Как раз за создание этой самой среды отвечает делегат приложения. Три свойства, которые должны быть обязательно в любом приложении использующем Core Data:

Обратите внимание на то, что все три свойства readonly, делается это для того, чтобы извне их нельзя было установить. Изучая BasicApplicationAppDelegate.m видно, что все три свойства имеют явные геттеры.

Managed Object Model:

После чего создается хранилище поддерживающее созданные модели данных. В нашем случае, собственно, как и в большинстве других с использованием Core Data, хранилище данных основывается на SQLite.

Создаём контекст (среду):

Контекст используется во всём приложении в качестве интерфейса для взаимодействия с Core Data и постоянным хранилищем.
Последовательность инициализации Core Data:

Механизм запускается при вызове метода application:didFinishLaunchingWithOptions:

Вызывая геттер свойства managedObjectContext делегата приложения на выполнение запускается цепочка действий:
— (NSManagedObjectContext *)managedObjectContext вызывает
— (NSPersistentStoreCoordinator *)persistentStoreCoordinator, который в свою очередь производит вызов
— (NSManagedObjectModel *)managedObjectModel.
Таким образом вызов геттер-метода managedObjectContext инициализирует весь стэк объектов Core Data и приводит Core Data в готовность.

Добавление Core Data в уже существующий проект

Добавление фрэймворка Core Data
Создание модели данных
Инициализация контекста (среды)

Добавление фрэймворка Core Data

UIKit
Foundation
Core Graphics

Где производится добавление новых фрэймворков:

Выбираем фрэймворк для подключения:

Создание модели данных

Ни одно приложение Core Data не может считаться завершенным без модели данных. Модель данных описывает все сущности, которые будут находиться в ведении Core Data.
Для создания новой модели данных: File -> New -> New File

Назовем нашу модель MyModel.xcdatamodeld:

После создания модели перед вами откроется окно редактирования (создания) сущностей.

Создать новую сущность можно кликнув на кнопку "+" в левой нижней части XCode, а добавить новый атрибут сущности можно нажав на кнопку "+" уже в разделе «Attributes» и затем выбрать его тип.

Инициализация контекста (среды)

Последний шаг состоит в инициализации контекста, хранилища и объектной модели. Чаще всего вы можете воспользоваться кодом, который автоматически генерируется XCode в «пустых» проектах использующих Core Data.

DemoAppAppDelegate.h

Переключимся в *.m файл DemoAppAppDelegate и напишем следующие строки:

Далее следует код, который производит инициализацию модели данных, хранилища и контекста.

Методы, которые ранее мы еще нигде не реализовывали:

Теперь, когда мы подключили Core Data, наше приложение может использовать его для хранения данных.
Давайте реализуем простой пример, который бы позволил нам убедиться в том, что всё работает так, как надо и данные действительно сохраняются.
В тестовом примере мы будем определять кол-во раз, которое было запущено наше приложение.
Внесём маленькие изменения в метод application:didFinishLaunchingWithOptions: делегата приложения в виде получения кол-ва раз, которое приложения запускалось ранее и добавление нового события запуска.

Код для получения предыдущих запусков приложения:

После чего мы можем пройтись по всему массиву следующим образом:

Добавим новую запись и сохраним:

После первого запуска приложение выведет в консоль следующую строку:

После второго запуска:

Полный метод выглядит следующим образом:

В завершение

Хранение данных необходимо при разработке iOS. Обработка данных - основная технология в разработке iOS. Соответствующее постоянное хранение данных может реализовать автономную функцию приложения и улучшить взаимодействие с пользователем. Так называемое сохранение данных заключается в сохранении данных на жестком диске, чтобы к ранее сохраненным данным можно было получить доступ после перезапуска приложения или телефона. В разработке для iOS существует множество решений для сохранения состояния. Далее я резюмирую следующие 5 решений для сохранения состояния:
1, plist (список атрибутов)
2, предпочтение (настройка предпочтения)
3. NSKeyedArchiver (архив)
4、SQList 3 （FMDB）
Поскольку параметр предпочтения сохраняет все данные в файле plist, названном по имени пакета приложения в каталоге предпочтений, параметр предпочтения и список атрибутов вводятся вместе.

Механизм песочницы

Приложения iOS могут только читать файлы в файловой системе, созданной для программы, и не могут получить доступ к другим местам. Эта область называется песочницей, поэтому здесь должны храниться все файлы, не относящиеся к кодам, например изображения, значки Звуки, списки атрибутов, текстовые файлы и т. Д.
1. Структура каталогов

2. Анализ структуры каталогов

Пакет приложения: содержит все файлы ресурсов и исполняемые файлы

Документы: сохраните данные, которые необходимо сохранить при запуске приложения, а iTunes создаст резервную копию этого каталога при синхронизации устройства.

Библиотека / кеши: iTunes не будет синхронизировать эту папку, которая подходит для хранения неважных данных большого размера, для которых не требуется резервное копирование.

Библиотека / Настройки: iTunes синхронизирует содержимое этой папки при синхронизации приложения и обычно сохраняет информацию о настройках приложения.
tmp: iTunes не будет синхронизировать эту папку, система может удалить файлы в этом каталоге, когда приложение не запущено, поэтому этот каталог подходит для сохранения некоторых временных файлов в приложении и удаления их, когда они используются

1. Список атрибутов (plist)

iOS предоставляет файл в формате plist (список атрибутов) для хранения облегченных данных.Список атрибутов представляет собой файл формата XML с расширением plist. Если объект имеет тип NSString, NSDictionary, NSArray, NSData, NSNumber и т. Д., Вы можете использовать метод writeToFile: atomically: для прямой записи объекта в файл списка атрибутов. Данные, сохраненные в этом формате, можно напрямую прочитать с помощью NSDictionary и NSArray. Файл plist принадлежит методу Write в разработке для iOS и может отображаться в виде списка свойств или в формате xml. Это очень удобно для управления данными. Необходимо освоить обработку данных с помощью файлов plist.

Записать данные в файл plist

Создать файл

Записать файл

Прочитать файл

Файлы Plist в каталоге файлов (включая info.plist)

2. Настройки (NSUserDefault)

3. Архив

Архивирование - это очень часто используемый метод хранения файлов. Можно заархивировать почти любой тип объекта (фактически, форма файлового хранилища). В отличие от списка атрибутов, это также легкое решение для сохранения данных. Архив зашифрован, и данные преобразуются в двоичные данные после обработки архива, поэтому безопасность намного выше, чем у списка атрибутов. Мы можем записывать сложные объекты в файлы, и независимо от того, сколько объектов добавлено, способ записи объектов на диск остается неизменным.

Используйте archiveRootObject для простого архивирования

Архивировать несколько объектов
Архив: запись данных

Разархивировать: получить данные из пути для создания экземпляра NSKeyedUnarchiver и использовать encodeObject: forKey: для получения объекта в файле.

Архивировать пользовательские объекты
// Создаем модель

SQList 3 （FMDB）

Важные классы фреймворка в фреймворке FMDB

FMDatabase
Объект FMDatabase представляет одну базу данных SQLite, используемую для выполнения операторов SQL.
FMResultSet
Набор результатов после выполнения запроса с использованием FMDatabase
FMDatabaseQueue
используется для выполнения нескольких запросов или обновлений в нескольких потоках, это потокобезопасно.

Использование базы данных

Интеллектуальная рекомендация

Michael.W Поговорите о Hyperledger Fabric. Проблема 20 - Подробная индивидуальная сортировка узла с пятью порядками с исходным кодом для чтения.

Michael.W Поговорите о Hyperledger Fabric. Проблема 20 - Подробная индивидуальная сортировка узла с пятью порядками с исходным кодом чтения Fabric Файл исходного кода одиночного режима находится в ord.

Мяу Пасс Матрица SDUT

Мяу Пасс Матрица SDUT Time Limit: 1000 ms Memory Limit: 65536 KiB Submit Statistic Problem Description Лянцзян получил матрицу, но эта матрица была особенно уродливой, и Лянцзян испытал отвращение. Чт.

Гессенская легкая двоичная структура удаленного вызова

Hessian - это легкая двоичная структура удаленного вызова, официальный адрес документа, в основном он включает протокол удаленного вызова Hessian, протокол сериализации Hessian, прокси-сервер клиента .

TCP Pasket и распаковка и Нетти Solutions

Основные введение TCP является ориентированным на соединение, обеспечивая высокую надежность услуг. На обоих концах (клиенты и терминалы сервера) должны иметь один или более гнезда, так что передающий.

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

Автор: Пратик Джианчандани (Prateek Gianchandani)

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

Кроме того, мы будем запускать приложения в IOS-симуляторе, используя Xcode и, следовательно, весь анализ будет происходить на компьютере, а не на самом устройстве. Все это будет делаться лишь с той целью, чтобы продемонстрировать, что вы можете использовать методы, описанные в предыдущих статьях, и над приложением, запущенным через Xcode. При желании, вы можете запустить приложение на устройстве, используя способ, описанный в седьмой статье из этой серии.

NSUserDefaults

Один из наиболее распространенных способов сохранения пользовательских настроек и свойств приложения – использование NSUserDefaults. Информация, хранимая в NSUserDefaults, сохраняется даже после закрытия и повторного запуска приложения. К примеру, в NSUserDefaults может храниться статус пользователя в системе, и при повторном открытии приложения в зависимости от этого статуса, пользователю будет показываться соответствующая информация и внешний вид интерфейса. Некоторые приложения используют NSUserDefaults для хранения конфиденциальной информации (например, пользовательский токен доступа), которая при повторном запуске приложения используется для повторной аутентификации в системе.

Загрузите и запустите тестовое приложение. Появится окно (см. рисунок ниже). Введите любую информацию в текстовом поле, которое относится к NSUserDefaults и нажмите на кнопку с надписью Save in NSUserDefaults, после чего информация сохранится в NSUserDefaults.

Рисунок 1: Окно, появляющееся после запуска тестового приложения

Многие не понимают того, что информация, хранимая в NSUserDefaults, не шифруется и может быть легко получена из пакета приложения (application bundle), поскольку хранится в plist-файле с именем bundle Id конкретного приложения. Для начала нам необходимо найти пакет для нашего приложения. Поскольку мы запускаем приложение на компьютере, то все приложения можно найти в папке /Users/$username/Library/Application Support/iPhone Simulator/$ios version of simulator/Applications/. В моем случае это папка Users/prateekgianchandani/Library/Application Support/iPhone Simulator/6.1/Applications.

Внутри этой папки находится пакет приложений, которые мы запускаем через Xcode для конкретной версии IOS. Мы можем найти наше приложение по дате последнего изменения.

Рисунок 2: Перечень приложений

Заходим внутрь нашего приложения. Все содержимое NSUserDefaults хранится внутри plist-файла с именем Library -> Preferences -> $AppBundleId.plist, как показано на рисунке ниже.

Рисунок 3: Plist-файл, где хранится информация из NSUserDefaults

Открыв вышеуказанный plist-файл, вы легко можете увидеть его содержимое.

Рисунок 4: Содержимое plist-файла

Некоторые plist-файлы могут быть бинарными и их не так просто прочесть. Вы можете либо сконвертировать их в xml при помощи утилиты plutil, либо открыть этот бинарный файл на устройстве при помощи iExplorer.

Еще один распространенный способ хранения информации – plist-файлы. К подобному способу следует прибегать лишь тогда, когда хранимая информация не представляет особой ценности, поскольку сами файлы не шифруются, и информацию из них можно легко извлечь даже на неджейлбрейковом устройстве. Были найдены уязвимости, которые свидетельствовали о том, что крупные компании использовали plist-файлы для хранения конфиденциальных данных (токены доступа, имена пользователей и пароли). В тестовом приложении введите информацию в соответствующих текстовых полях и нажмите на кнопку с надписью Save in plist file.

Рисунок 5: Сохранение информации в plist-файле

Ниже показан код, позволяющий сохранять информацию в plist-файле:

Из кода, показанного выше, видно, что всегда можно задать свой собственный путь для хранения plist-файла. Теперь мы можем поискать все plist-файлы внутри пакета приложения (в нашем случае, будем искать файл с именем userinfo.plist).

Рисунок 6: Местонахождение plist-файла

Заглянув внутрь найденного файла, мы видим введенную ранее комбинацию имени пользователя и пароля.

Рисунок 7: Содержимое plist-файла

Файлы CoreData и Sqlite

Поскольку для хранения информации CoreData использует Sqlite, мы будем рассматривать только CoreData. Ниже приводится выдержка из документации Apple относительно CoreData:

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

Отслеживание изменений и поддержка отмены изменений. У Core Data есть встроенные возможности для отмены и восстановления изменений во время редактирования текста.
Поддержка взаимосвязей. Core Data управляет распространением изменений, включая поддержку корректности взаимосвязей среди объектов.
Отложенное выполнение. Core Data может уменьшить издержки памяти вашего приложения путем отложенной загрузки объектов. Также присутствует поддержка частично материализованных функций (partially materialized futures) и копирования при записи совместно используемых данных.
Автоматическая проверка значений свойств. Управляемые объекты Core Data расширяют стандартные методы валидации данных типа «ключ-значение», которые поддерживают целостность этих данных.
Перенос схемы. Изменить схему приложения может быть не так просто, как с точки зрения усилий, затрачиваемых разработчиками, так и использования ресурсов во время выполнения приложения. Утилиты Core Data, предназначенные для переноса схем, упрощают задачу копирования при изменении схемы и в некоторых случаях позволяют выполнять сверхэффективный перенос схемы по месту.
Дополнительная интеграция с уровнем контроллера приложения для поддержки синхронизации с пользовательским интерфейсом. При работе с iOS у Core Data есть объект NSFetchedResultsController. При работе в OS X Core Data интегрирован с Cocoa Bindings.
Полная и автоматическая поддержка для доступа и отслеживания изменений данных, хранящихся по принципу «ключ-значение». В дополнении к синтезу методов доступа и отслеживания изменений данных, в Core Data присутствует соответствующий набор средств для взаимосвязей типа «один-ко-многим» или «много-ко-многим».
Группировка, фильтрация и организация данных в памяти или в пользовательском интерфейсе.
Автоматическая поддержка для объектов, хранящихся во внешних репозиториях.
Продвинутая компиляция запросов. Вместо написания SQL-кода, вы можете создавать сложные запросы путем связывания объекта NSPredicate с запросом на извлечение данных. В NSPredicate есть поддержка базовых функций, связанных подзапросов и других продвинутых возможностей языка SQL. Также в Core Data есть поддержка корректного Unicode, регионального поиска, сортировки и регулярных выражений.
Политики объединения. В Core Data есть встроенные средства отслеживания версий и оптимистичной блокировки для поддержки автоматического разрешения конфликтов при многократной записи.

То есть, по сути, CoreData можно использовать для создания модели, управления взаимосвязью между различными типами объектов, локального сохранения данных и получения данных из локального кэша при помощи запросов в тот момент, когда это необходимо. В этой статье мы будем экспериментировать с тестовым приложением. После запуска на экране появится простейшая RSS-лента.

Рисунок 8: Тестовое приложение с простейшей RSS-лентой

Это приложение использует Core Data для сохранения информации. Важно отметить, что фреймворк Core Data использует Sql-запросы для хранения данных и, следовательно, вся информация хранится в файлах с расширением .db. Теперь посмотрим, где хранится эта информация. Внутри пакета приложения вы можете увидеть файл с именем MyCoreData.sqlite.

Рисунок 9: Содержимое пакета приложения

Сейчас мы будем анализировать файл MyCoreData.sqlite при помощи утилиты sqlite3. В моем случае этот файл находится в папке

Рисунок 10: Начинаем анализировать файл MyCoreData.sqlite

Как видно из рисунка выше, внутри файла присутствует таблица ZSTORIES. В Core Data в начало имени каждой таблицы подставляется Z, то есть на самом деле имя таблицы - STORIES, и мы можем это легко увидеть из исходных файлов проекта.

Рисунок 11: Параметры таблицы STORIES

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

Рисунок 12: Содержимое таблицы STORIES

Как видно из рисунка выше по умолчанию все хранимые данные незашифрованные и могут быть легко получены. Следовательно, использовать CoreData для хранения конфиденциальной информации нецелесообразно. Существуют библиотеки, выступающие в роли обертки для CoreData, которые сохраняют данные в зашифрованном виде. Существуют и другие решения, позволяющие сохранять информацию в зашифрованном виде без использования CoreData. Например, Salesforce Mobile SDK использует функцию SmartStore, которая может хранить зашифрованные данные на устройстве в специальных таблицах (или Soups).

Некоторые разработчики избегают сохранять данные в Keychain из-за сложностей реализации этого механизма. Однако, хранение информации в Keychain, вероятно, является самым безопасным способом хранения на неджейлбрейковом устройстве. На джейлбрейковом устройстве ничто не находится в безопасности (более подробно об этом рассказывается в двенадцатой статье этой серии). В этой статье демонстрируется, насколько просто сохранять данные в Keychain при помощи простейших классов-оберток. По сути, код для сохранения информации в Keychain при помощи этого класса очень похож на код для сохранения данных в NSUserDefaults. Ниже показан код, который сохраняет строку в Keychain. Обратите внимание, что синтаксис очень схож с кодом для сохранения в NSUserDefaults.

[plain]
PDKeychainBindings *bindings = [PDKeychainBindings sharedKeychainBindings];
[bindings setObject:@"XYZ" forKey:@"authToken"];
[/plain]

Далее показан небольшой участок кода, про помощи которого можно получать информацию из Keychain.

[plain]
PDKeychainBindings *bindings = [PDKeychainBindings sharedKeychainBindings];
NSLog(@"Auth token is %@",[bindings objectForKey:@"authToken"]]);
[/plain]

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

Как уже говорилось ранее, ничто не защищено на джейлбрековом устройстве. Злоумышленник может доставать информацию из plist-файлов, выгружать все хранилище Keychain, изменять реализацию методов (об этом рассказывалось в восьмой статье этой серии) и вообще делать все, что заблагорассудится. Однако разработчик приложения при помощи некоторых трюков может усложнить жизнь скрипт кидди (или тем, кто только начинает свой путь на этом поприще). Разработчик может шифровать файлы во время их сохранения на устройстве (более подробно об этом читайте в этой статье). Или вы можете затруднить получение злоумышленником корректной информации. Например, рассмотрим пример сохранения в Keychain аутентификационного токена для конкретного пользователя. Неопытный злоумышленник лишь попытается использовать этот токен, выгруженный из Keychain, для подделки пользовательской сессии. Мы же перед сохранением токена можем обработать его каким-нибудь алгоритмом (например, самое простое, что можно сделать, - перемешать символы задом наперед), и злоумышленник не будет знать, что нужно сделать для того, чтобы получить рабочий токен. Само собой, злоумышленник может провести более тщательное исследование приложение и выявить этот трюк, однако в некоторых случаях это может помочь. Еще один простейший трюк: перед сохранением строки добавлять к ней константу.

В 2019 году появилось множество приложений для iOS, которые однозначно стоит добавить на главный экран вашего устройства. Например, Mobike для бесстанционного проката велосипедов, Blinkist для чтения или прослушивания краткого пересказа и Oh She Glows для поиска популярных вегетарианских рецептов.

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

Достижение великолепного пользовательского опыта зависит от многих факторов. Прежде всего, вам необходимо отказаться от такого понятия как “финальный продукт”. Команды разработчиков самых коммерчески успешных приложений постоянно наблюдают, тестируют и доводят до ума каждую мелкую деталь. Вы спросите: “Как мне это сделать?”. Частично ответ на данный вопрос зависит от вашего руководства и нацеленности команды на результат, но по большей части от тех инструментов, которые вы используете в работе. В нашем случае — это iOS SDK (комплект средств разработки для iOS).

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

Ключевые особенности:

Обширная сеть с более чем миллионом пользователей.
Опрос пользователей.
Наличие видео отзывов и их автоматическое транскрибирование.

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

Ключевые особенности:

Appsee — это высококачественная аналитическая платформа, созданная для анализа поведения пользователей в приложениях. Appsee включает в себя видеозаписи сессий и тепловую карту кликов, а также интегрирует их в другие встроенные инструменты для аналитики: воронку конверсии, когортный анализ, карту поведения и даже в видеозаписи с ошибками, которые позволяют командам разработчиков воспроизводить последовательности, приведшие к неисправности. Также Appsee включает сторонние интеграции с известными платформами, такими как AppsFlyer, Crashlytics, Optimizely, Salesforce, Slack и другими. Для интеграции Appsee SDK в ваше приложение потребуется всего одна строка кода.

Ключевые особенности:

Видеозапись сессий.
Тепловая карта кликов.
Пользовательские сценарии и карта пути пользователя.

Instabug — еще один SDK со множеством функций, включающий в себя инструмент для составления отчетов об ошибках для пользователей и для отправления вам необходимой информации о трассировке стека без навигационной цепочки. Также у вас есть возможность увидеть, как работает текущая версия по сравнению с предыдущими, и ознакомиться с видеозаписями сессий ваших пользователей. Instabug можно интегрировать с вашим workflow, чтобы отправлять предупреждения всей вашей команде через Slack и JIRA.

Ключевые особенности:

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

Optimizely — это платформа для экспериментов, предлагающая решения для веб-страниц и мобильных приложений. Инструмент позволяет плавно экспериментировать в режиме реального времени с любой частью вашего приложения или веб-страницы. Это позволяет выяснить при каких условиях растёт доход, увеличиваются регистрации и загрузки. И вам не нужно ждать отзыва в App Store, чтобы узнать, что конкретно необходимо изменить. Optimizely дает возможность настроить таргетинг, время и распределение аудитории при проведении тестирования.

Ключевые особенности:

Мгновенное и поэтапное развертывание
Визуальный редактор
Распределение аудитории и расширенный таргетинг

ForeSee предлагает набор многоканальных инструментов для формирования “клиентского опыта”, включая self-service инструмент обратной связи с пользователями. С помощью ForeSee Feedback, вы можете стимулировать пользователей заполнять простые опросы и сообщать о проблемах до того, как те превратятся в снежный ком. Кроме того, у вас есть возможность быстро задеплоить окно с рейтингом для ценных пользователей. Также ForeSee позволяет воспроизвести пользовательскую сессию, обеспечивая целостное представление о UX во время работы вашего приложения.

Ключевые особенности:

Простой self-service деплой.
Возможность для пользователей поставить оценку и оставить отзыв.
Воспроизведение пользовательских сессий.

С помощью всего нескольких строк кода Stripe iOS SDK позволяет безопасно получить информацию о кредитной карте, не собирая PCI данные и используя автоматизированную систему идентификации мошенничества, основанную на машинном обучении. Stripe позволяет пользователям настраивать пользовательский интерфейс с помощью предварительно созданных и проверенных временем UI компонентов на сайтах и в мобильных приложениях. Удобный пользовательский интерфейс и настраиваемые параметры/виды оплаты в совокупности создают самый удобный и надежный процесс оплаты для ваших клиентов.

Ключевые особенности:

Встроенная проверка.
Настраиваемый набор UI компонентов.
Предотвращение мошенничества на основе машинного обучения.

Mapbox — это платформа, предназначенная для создания и публикации своих собственных карт. Этот iOS SDK помогает создавать приложения, использующие данные о локации для управления какими-либо функциями, в нескольких категориях, включая транспорт, путешествия, навигацию и даже AR. Конечно, разработчики могут использовать и заранее разработанные карты. Платформа использует сеть из более чем 400 миллионов пользователей.

Ключевые особенности:

Настройка цвета дорог, линий границ, географических названий и т.д.
Поддержка оффлайн карт.
Навигация.

“Лучшие” iOS SDK инструменты — это те, которые позволяют вам воплощать свежие идеи в жизнь, уверенно работать с данными и быстро их оптимизировать. Этот список поможет лучше ориентироваться в потребностях ваших пользователей, что, в конечном итоге, позволит повысить время удержания клиентов и поможет улучшить с ними деловые отношения.

Читайте также: