Защита данных Используя дисковое шифрование

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

Защита данных доступна на большинстве устройств на iOS и подвергается следующим требованиям:

• Файловая система на устройстве пользователя должна поддерживать защиту данных. Большинство устройств поддерживает это поведение.

• У пользователя должен быть активный набор блокировки кода доступа для устройства.

Для защиты файла Вы добавляете атрибут к файлу, указывающему желаемый уровень защиты. Добавьте этот атрибут с помощью любого NSData класс или NSFileManager класс. При записи новых файлов можно использовать writeToFile:options:error: метод NSData с надлежащей защитой оценивают как одна из опций записи. Для существующих файлов можно использовать setAttributes:ofItemAtPath:error: метод NSFileManager установить или изменить значение NSFileProtectionKey. При использовании этих методов укажите один из следующих уровней защиты для файла:

• Когда устройство заблокировано, никакая защита — файл шифруется, но не защищен кодом доступа и доступен. Укажите NSDataWritingFileProtectionNone опция (NSData) или NSFileProtectionNone атрибут (NSFileManager).

• В то время как устройство заблокировано, завершенный — файл шифруется и недоступен. Укажите NSDataWritingFileProtectionComplete опция (NSData) или NSFileProtectionComplete атрибут (NSFileManager).

• Завершенный, если уже не открываются — файл шифруется. В то время как устройство заблокировано, закрытый файл недоступен. После того, как пользователь разблокировал устройство, Ваше приложение может открыть файл и использовать его. Если пользователь блокирует устройство, в то время как файл открыт, тем не менее, Ваше приложение может продолжать получать доступ к нему. Укажите NSDataWritingFileProtectionCompleteUnlessOpen опция (NSData) или NSFileProtectionCompleteUnlessOpen атрибут (NSFileManager).

• Завершенный до первого входа в систему — файл шифруется и недоступен, пока устройство не загрузилось, и пользователь разблокировал его один раз. Укажите NSDataWritingFileProtectionCompleteUntilFirstUserAuthentication опция (NSData) или NSFileProtectionCompleteUntilFirstUserAuthentication атрибут (NSFileManager).

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

• Делегат приложения может реализовать applicationProtectedDataWillBecomeUnavailable: и applicationProtectedDataDidBecomeAvailable: методы.

• Любой объект может зарегистрироваться для UIApplicationProtectedDataWillBecomeUnavailable и UIApplicationProtectedDataDidBecomeAvailable уведомления.

• Любой объект может проверить значение protectedDataAvailable свойство совместно используемого UIApplication объект определить, в настоящее время доступны ли файлы.

Для новых файлов рекомендуется включить защиту данных прежде, чем записать любые данные им. Если Вы используете writeToFile:options:error: метод для записи содержания NSData возразите против диска, это происходит автоматически. Для существующих файлов, добавляя защиту данных заменяет незащищенный файл новой защищенной версией.

Идентификация уникальных пользователей приложения

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

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

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

• Вы хотите дифференцировать экземпляры своего приложения, работающего на различных устройствах. Используйте identifierForVendor свойство UIDevice класс для получения ID, дифференцирующего пользователя на одном устройстве от пользователей на других устройствах. Этот метод действительно теперь позволяет Вам идентифицировать определенных пользователей. У отдельного пользователя могут быть многократные устройства, каждый с различным Значением идентификатора.

• Вы хотите идентифицировать пользователя в целях распространения. Используйте advertisingIdentifier свойство ASIdentifierManager класс для получения ID для пользователя.

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

Включение сохранения состояния и восстановления в приложении

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

• application:shouldSaveApplicationState:

• application:shouldRestoreApplicationState:

Обычно, Ваши реализации этих методов просто возвращаются YES указать, что могут произойти сохранение состояния и восстановление. Однако приложения, хотящие сохранить и восстановить их состояние условно, могут возвратиться NO в ситуациях, где не должны происходить операции. Например, после выпуска обновления к Вашему приложению, Вы могли бы хотеть возвратиться NO от Вашего application:shouldRestoreApplicationState: метод, если Ваше приложение неспособно полезно восстановить состояние от предыдущей версии.

Процесс сохранения и восстановления

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

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

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

Во время процесса сохранения и восстановления Ваше приложение имеет ряд ответственности.

• Во время сохранения Ваше приложение ответственно за:

  • Сообщение UIKit, что это поддерживает сохранение состояния.

  • Сообщение UIKit, просматривающих контроллеры и представления, должно быть сохранено.

  • Кодирование соответствующих данных для любых сохраненных объектов.

• Во время восстановления Ваше приложение ответственно за:

  • Сообщение UIKit, что это поддерживает восстановление состояния.

  • Обеспечение (или создание) объекты, которые требует UIKit.

  • Декодирование состояния сохраненных объектов и использование его для возврата объекта его предыдущему состоянию.

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

Рисунок 5-1 показывает иерархию контроллера представления интерфейса панели вкладок после того, как пользователь взаимодействовал с несколькими из вкладок. Как Вы видите, некоторые контроллеры представления загружаются автоматически как часть основного файла раскадровки приложения, но некоторые контроллеры представления были представлены или продвинуты на контроллеры представления на различных вкладках. Без восстановления состояния только контроллеры представления от основного файла раскадровки были бы восстановлены во время последующих запусков. Путем добавления поддержки восстановления состояния к приложению можно сохранить все контроллеры представления.

UIKit сохраняет только те объекты, имеющие присвоенный идентификатор восстановления. Идентификатор восстановления является строкой, идентифицирующей контроллер представления или представления для UIKit и Вашего приложения. Значение этой строки является значительным только к Вашему коду, но присутствие этой строки говорит UIKit, что должно сохранить маркированный объект. Во время процесса сохранения UIKit обходит иерархию контроллера представления Вашего приложения и сохраняет все объекты, имеющие идентификатор восстановления. Если контроллер представления не имеет идентификатора восстановления, того контроллера представления и всех его представлений, и дочерние контроллеры представления не сохраняются. Рисунок 5-2 показывает, что обновленная версия предыдущей иерархии представления, теперь с восстановлением идентифицирует, применился к большинству (но не все) контроллеров представления.

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

Для каждого контроллера представления Вы принимаете решение сохранить, также необходимо решить, как Вы хотите восстановить его позже. UIKit предлагает два способа воссоздать объекты. Можно позволить приложению делегировать, воссоздают его, или можно присвоить класс восстановления контроллера представления и позволить тому классу воссоздать его. Класс восстановления реализует UIViewControllerRestoration протокол и ответственен за нахождение или создание заданного объекта во время восстановления. Вот некоторые подсказки для того, когда использовать каждого:

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

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

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

В следующий раз, когда приложение запускается, UIKit загружает основную раскадровку приложения или файл пера, как обычно, вызывает делегата приложения application:willFinishLaunchingWithOptions: метод, и затем пытается восстановить предыдущее состояние приложения. Первая вещь, которую это делает, просят, чтобы Ваше приложение для обеспечения набора контроллера представления возразило, что соответствуют тем, которые были сохранены. Если данный контроллер представления имел присвоенный класс восстановления, тот класс просят обеспечить объект; иначе, делегата приложения просят обеспечить его.

Поток процесса сохранения

Рисунок 5-3 показывает высокоуровневые события, происходящие во время сохранения состояния, и показывает, как затронуты объекты Вашего приложения. Прежде чем сохранение даже происходит, UIKit спрашивает Вашего делегата приложения, если это должно произойти путем вызова application:shouldSaveApplicationState: метод. Если возвращается тот метод YES, UIKit начинает собирать и кодировать представления Вашего приложения и контроллеры представления. Когда это закончено, это пишет закодированные данные в диск.

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

Поток процесса восстановления

Рисунок 5-4 показывает высокоуровневые события, происходящие во время восстановления состояния, и показывает, как затронуты объекты Вашего приложения. После стандартной инициализации и загрузки UI завершено, UIKit спрашивает Вашего делегата приложения, если восстановление состояния должно произойти вообще путем вызова application:shouldRestoreApplicationState: метод. Это - Ваша возможность делегата приложения исследовать сохраненные данные и определить, возможно ли восстановление состояния. Если это, UIKit использует делегата приложения и классы восстановления для получения ссылок на контроллеры представления приложения. Каждый объект тогда предоставлен данными, которые он должен восстановить сам к его предыдущему состоянию.

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

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

Что происходит когда Вы Exclude Groups контроллеров представления?

Когда идентификатор восстановления контроллера представления nil, тот контроллер представления и любые дочерние контроллеры представления, которыми это управляет, не сохраняются автоматически. Например, на рисунке 5-5, потому что контроллер навигации не имел идентификатора восстановления, он и все его дочерние контроллеры представления и представления опущен от сохраненных данных.

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

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

Контрольный список для реализации сохранения состояния и восстановления

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

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

• (Требуемая) Реализация application:shouldSaveApplicationState: и application:shouldRestoreApplicationState: методы в Вашем делегате приложения; посмотрите Включающее Сохранение состояния и Восстановление в Вашем Приложении.

• (Требуемый) Присваивают идентификаторы восстановления каждому контроллеру представления, который Вы хотите сохранить путем присвоения непустой строки их restorationIdentifier свойство; посмотрите отмечание Ваших Контроллеров Представления для Сохранения.

  Если Вы хотите сохранить состояние определенных представлений также, присвоить непустые строки их restorationIdentifier свойства; посмотрите Сохранение состояния Ваших Представлений.

• (Требуемый) Показывают окно Вашего приложения от application:willFinishLaunchingWithOptions: метод Вашего делегата приложения. Машинному оборудованию восстановления состояния нужно окно так, чтобы это могло восстановить позиции прокрутки и другие соответствующие биты интерфейса Вашего приложения.

• Присвойте классы восстановления надлежащих контроллеров представления. (Если Вы не делаете этого, Вашего делегата приложения просят обеспечить соответствующий контроллер представления во время восстановления.) Посмотрите Восстановление Ваших Контроллеров Представления во Время Запуска.

• (Рекомендуемый) Кодируют и декодируют состояние Ваших представлений и просматривают контроллеры с помощью encodeRestorableStateWithCoder: и decodeRestorableStateWithCoder: методы тех объектов; посмотрите Кодирование и Декодирование Вашего состояния Контроллера Представления.

• Закодируйте и декодируйте любую информацию о версии или дополнительную информацию состояния для Вашего приложения с помощью application:willEncodeRestorableStateWithCoder: и application:didDecodeRestorableStateWithCoder: методы Вашего делегата приложения; посмотрите Сохранение Высокоуровневого состояния Вашего Приложения.

• Объекты, действующие как источники данных для табличных представлений и представлений набора, должны реализовать UIDataSourceModelAssociation протокол. Несмотря на то, что не требуемый, этот протокол помогает сохранить выбранные и видимые элементы в тех типах представлений. Посмотрите Реализующие благоприятные для сохранения Источники данных.

Включение сохранения состояния и восстановления в приложении

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

• application:shouldSaveApplicationState:

• application:shouldRestoreApplicationState:

Обычно, Ваши реализации этих методов просто возвращаются YES указать, что могут произойти сохранение состояния и восстановление. Однако приложения, хотящие сохранить и восстановить их состояние условно, могут возвратиться NO в ситуациях, где не должны происходить операции. Например, после выпуска обновления к Вашему приложению, Вы могли бы хотеть возвратиться NO от Вашего application:shouldRestoreApplicationState: метод, если Ваше приложение неспособно полезно восстановить состояние от предыдущей версии.

Сохранение состояния контроллеров представления

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

• (Требуемый) Присваивают идентификатор восстановления контроллеру представления; посмотрите отмечание Ваших Контроллеров Представления для Сохранения.

• (Требуемый) Обеспечивают код, чтобы создать или определить местоположение новых объектов контроллера представления во время запуска; посмотрите Восстановление Ваших Контроллеров Представления во Время Запуска.

• (Необязательно) Реализация encodeRestorableStateWithCoder: и decodeRestorableStateWithCoder: методы, чтобы закодировать и восстановить любую информацию состояния, которая не может быть воссоздана во время последующего запуска; посмотрите Кодирование и Декодирование Вашего состояния Контроллера Представления.

+ (UIViewController*) viewControllerWithRestorationIdentifierPath:(NSArray *)identifierComponents

                      coder:(NSCoder *)coder {

   MyViewController* vc;

   UIStoryboard* sb = [coder decodeObjectForKey:UIStateRestorationViewControllerStoryboardKey];

   if (sb) {

      vc = (PushViewController*)[sb instantiateViewControllerWithIdentifier:@"MyViewController"];

      vc.restorationIdentifier = [identifierComponents lastObject];

      vc.restorationClass = [MyViewController class];

   }

    return vc;

}

- (void)encodeRestorableStateWithCoder:(NSCoder *)coder {

   [super encodeRestorableStateWithCoder:coder];

   [coder encodeInt:self.number forKey:MyViewControllerNumber];

}

- (void)decodeRestorableStateWithCoder:(NSCoder *)coder {

   [super decodeRestorableStateWithCoder:coder];

   self.number = [coder decodeIntForKey:MyViewControllerNumber];

}

Сохранение состояния представлений

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

Чтобы определять, что состояние представления должно быть сохранено, Вы делаете следующее:

• Присвойте допустимую строку представлению restorationIdentifier свойство.

• Используйте представление от контроллера представления, также имеющего допустимый идентификатор восстановления.

• Для табличных представлений и представлений набора, присвойте источник данных, принимающий UIDataSourceModelAssociation протокол.

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

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

// Preserve the text selection

- (void) encodeRestorableStateWithCoder:(NSCoder *)coder {

    [super encodeRestorableStateWithCoder:coder];

    NSRange range = [self selectionRange];

    [coder encodeInt:range.length forKey:kMyTextViewSelectionRangeLength];

    [coder encodeInt:range.location forKey:kMyTextViewSelectionRangeLocation];

}

// Restore the text selection.

- (void) decodeRestorableStateWithCoder:(NSCoder *)coder {

   [super decodeRestorableStateWithCoder:coder];

   if ([coder containsValueForKey:kMyTextViewSelectionRangeLength] &&

           [coder containsValueForKey:kMyTextViewSelectionRangeLocation]) {

      NSRange range;

      range.length = [coder decodeIntForKey:kMyTextViewSelectionRangeLength];

      range.location = [coder decodeIntForKey:kMyTextViewSelectionRangeLocation];

      if (range.length > 0)

         [self setSelectionRange:range];

   }

}

Сохранение высокоуровневого состояния приложения

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

• application:willEncodeRestorableStateWithCoder:

• application:didDecodeRestorableStateWithCoder:

Если Ваше приложение содержит состояние, не живущее в контроллере представления, но это должно быть сохранено, можно использовать предыдущие методы, чтобы сохранить и восстановить его. application:willEncodeRestorableStateWithCoder: метод вызывают в самом начале процесса сохранения так, чтобы можно было выписать любое высокоуровневое состояние приложения, такое как текущая версия пользовательского интерфейса. application:didDecodeRestorableStateWithCoder: метод вызывают в конце состояния восстановления так, чтобы можно было декодировать любые данные и выполнить любую заключительную очистку, которой требует приложение.

Подсказки для сохранения и восстановления информации состояния

Поскольку Вы добавляете поддержку сохранения состояния и восстановления к Вашему приложению, рассматриваете следующие инструкции:

• Закодируйте информацию о версии вместе с остальной частью состояния Вашего приложения. Во время процесса сохранения рекомендуется закодировать строку версии или число, идентифицирующее текущую версию пользовательского интерфейса приложения. Можно закодировать это состояние в application:willEncodeRestorableStateWithCoder: метод Вашего делегата приложения. Когда Ваш делегат приложения application:shouldRestoreApplicationState: метод вызывают, можно получить эту информацию от предоставленного кодера и использовать его, чтобы определить, возможно ли сохранение состояния.

• Не включайте объекты от своей модели данных в состоянии Вашего приложения. Приложения должны продолжать сохранять свои данные отдельно в iCloud или к локальным файлам на диске. Никогда не используйте механизм восстановления состояния для сохранения тех данных. Если проблемы происходят во время работы восстановления, сохраненные интерфейсные данные могут быть удалены. Поэтому любые связанные с сохранением данные, которые Вы пишете в диск, нужно считать purgeable.

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

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

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

• Когда пользовательская сила выходит из приложения, система автоматически удаляет сохраненное состояние приложения. Удаление сохраненной информации состояния, когда приложение уничтожается, является мерами безопасности. (Как меры безопасности, система также удаляет сохраненное состояние если сбои приложения дважды во время запуска.), Если Вы хотите протестировать возможность своего приложения восстановить ее состояние, Вы не должны использовать многозадачную панель для уничтожения приложения во время отладки. Вместо этого используйте XCode, чтобы уничтожить приложение или уничтожить приложение программно путем установки временной команды или жеста для вызова exit по требованию.

Конфигурирование сокетов для использования VoIP

Для Вашего приложения для поддержания постоянного соединения, в то время как это в фоновом режиме необходимо тегировать основной коммуникационный сокет приложения в частности для использования VoIP. Тегирование этого сокета говорит системе, что должно принять управление сокетом, когда приостановлено Ваше приложение. Сам handoff полностью очевиден для Вашего приложения. И когда новые данные поступают в сокет, система будит приложение и возвращает управление сокета так, чтобы приложение могло обработать входящие данные.

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

В iOS большинством сокетов управляют с помощью потоков или других высокоуровневых конструкций. Для конфигурирования сокета для использования VoIP единственная вещь, которую необходимо сделать вне нормальной конфигурации, добавляет специальный ключ, тегирующий интерфейс, как связываемый со службой VoIP. Таблица 5-1 перечисляет потоковые интерфейсы и конфигурацию для каждого.

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

Для получения дополнительной информации о конфигурировании потоковых объектов Какао, см. Потоковое Руководство по программированию. Для получения информации об использовании URL-запросов см. Руководство по программированию Загрузочной системы URL. И для получения информации о конфигурировании потоков с помощью интерфейсов CFNetwork, см. Руководство по программированию CFNetwork.

Установка обработчика проверки активности

Для предотвращения потери его соединения приложение VoIP обычно должно периодически просыпаться и регистрация с его сервером. Для упрощения этого поведения iOS позволяет Вам установить специальный обработчик с помощью setKeepAliveTimeout:handler: метод UIApplication. Вы обычно устанавливаете этот обработчик в applicationDidEnterBackground: метод Вашего делегата приложения. После того, как установленный, системные вызовы Ваш обработчик, по крайней мере, однажды интервал тайм-аута истекает, будя Ваше приложение по мере необходимости, чтобы сделать так.

Ваш обработчик проверки активности выполняется в фоновом режиме и должен возвратиться как можно быстрее. Обработчикам дают максимум 10 секунд для выполнения любых необходимых задач и возврата. Если обработчик не возвратился после 10 секунд или не запросил дополнительное время выполнения, прежде чем тот интервал истечет, система приостанавливает приложение.

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

Конфигурирование аудио сеанса приложения

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

Для получения информации о том, как сконфигурировать и управлять аудио сеансом для приложения VoIP, видит Аудио Руководство по программированию Сеанса.

Используя интерфейсы достижимости для улучшения пользовательского опыта

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

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

1. Создайте a SCNetworkReachabilityRef структура для Вашего целевого удаленного узла.

2. Присвойте функцию обратного вызова своей структуре (использующий SCNetworkReachabilitySetCallback функция), который обрабатывает изменения в состоянии достижимости Вашей цели.

3. Добавьте что цель к активному циклу выполнения Вашего приложения (такого как основной цикл выполнения) использование SCNetworkReachabilityScheduleWithRunLoop функция.

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

Для получения дополнительной информации об интерфейсах достижимости, посмотрите Ссылку Платформы Конфигурации системы.