Ios жизненный цикл приложения: iOS Application Lifecycle, жизненный цикл iOS приложения

Содержание

iOS Application Lifecycle, жизненный цикл iOS приложения

admin

Опубликовано

Можно в поисковике набрать iOS Application Lifecycle и вы увидите много диаграмм (сложных и не очень), в которых разобраться без пол-литра не получится. Также будет и рисунок, который представлен выше. Эта диаграмма взята их лекций Stanford University, посвященных разработке iOS приложений, но тут она переведена на русский язык.

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

Обработка событий из различных этапов жизненного цикла iOS приложений очень похожа на обработку событий жизненного цикла View Controller. Т.е. нужно понимать в какой момент какой метод вызывается и что в этот момент времени уже «проинициализировалось», — с чем мы можем в данный момент работать.

Сначала приложение не запущенно. Потом пользователь запускает приложение. Оно переходит в состояние в состояние Foreground, в котором приложение становится сначала Iactive — на этом этапе выполняется код программы, но не обрабатываются события интерфейса пользователя (интерфейс не отображается, касания не обрабатываются и. т.п.). Затем переходит в этап Active, в котором выполняется код и обрабатываются все события UI.

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

//
// proSwift.ru
//
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
    // Override point for customization after application launch.
    return true
}

Также происходит оповещение с именем

UIApplicationDidFinishLaunchingNotification

//
// proSwift.ru
//

func applicationWillResignActive(application: UIApplication) {
    
}

Также происходит оповещение с именем

UIApplicationWillResignActiveNotification

//
// proSwift. ru
//

func applicationDidBecomeActive(application: UIApplication) {
        
}

Также происходит оповещение с именем

UIApplicationDidBecomeActiveNotification

//
// proSwift.ru
//

func applicationDidEnterBackground(application: UIApplication) {

}

Также происходит оповещение с именем

UIApplicationDidEnterBackgroundNotification

//
// proSwift. ru
//
func applicationWillEnterForeground(application: UIApplication) {

}

Также происходит оповещение с именем

UIApplicationWillEnterForegroundNotification

//
// proSwift.ru
//
func applicationWillTerminate(application: UIApplication) {

}

Также происходит оповещение с именем

UIApplicationWillTerminateNotification

UIViewController (ViewController) — Это класс унаследованный от стандартного UIViewController, который является базовым контроллером паттерна MVC, который Apple рекомендует использовать для разработки iOS приложений. Сущность UIViewController’a используется для контроля UIView

Он предоставляет экземпляр NSCoder в качестве параметра, который вам нужен, только если вы используете API-интерфейсы сериализации iOS. Это используется не часто, поэтому вы можете игнорировать этот параметр. Эта сериализация преобразует объект в поток байтов, который вы можете сохранить на диске или отправить по сети.

На этапе инициализации ViewController’a вы обычно выделяете ресурсы, которые потребуются ViewController’у в течение его жизненного цикла. К ним относятся объекты модели или другие вспомогательные контроллеры, такие как сетевые контроллеры.

Имейте в виду, что на данный момент вью ViewController’a еще не создано. Если вы попытаетесь получить к нему доступ через вью свойства ViewController’a, будет вызван метод loadView(). Это может привести к неожиданному поведению и ошибкам, поэтому безопаснее обращаться к вью на более позднем этапе жизненного цикла.

Иногда вы можете решить поместить интерфейс вашего ViewController’a в отдельный nib-файл вместо сториборда. Например, при работе в большой команде, где разные разработчики должны изменять интерфейсы ViewController’a, не влияя на работу друг-друга. У вас также может быть проект, который был создан, когда сторибордов еще не существовало, поэтому у каждого ViewController’a был свой собственный nib-файл. Обратите внимание, что, если ваш Main(Основной) Storyboard становится слишком большой, вы можете разделить его на несколько Storyboard’ов. Вам не нужно перемещать каждый ViewController в отдельный nib-файл.

Этот метод вызывается только один раз за время жизни ViewController’a, поэтому вы используете его для вещей, которые должны произойти только один раз. Если вам нужно выполнять какую-то задачу каждый раз, когда на экране появляется ViewController, вам понадобятся следующие методы.

ViewController исчезает с экрана, но это не означает, что впоследствии он будет освобожден. Многие контейнеры хранят viewController в памяти. Например, когда вы углубляетесь в navigation controller, все предыдущие viewController остаются в памяти. Navigation controller освобождает viewController’ы только при переходе вверх по иерархии. Поэтому вы должны иметь в виду, что viewController, который не находится на экране, все равно работает нормально и получает уведомления. Иногда это желательно, иногда нет, поэтому вам нужно помнить об этом при разработке приложения.

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

Поскольку viewController’ы выполняют управление ресурсами, эти уведомления доставляются им с помощью этого метода. Таким образом, вы можете предпринять действия, чтобы освободить часть памяти. Имейте в виду, что если вы проигнорируете предупреждения о нехватки памяти и память, используемая вашим приложением, превысит определенный порог, iOS завершит работу вашего приложения. Это будет выглядеть как краш для пользователя, и его следует избегать.

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    // Override point for customization after application launch.
    
    FirebaseConfiguration.shared.setLoggerLevel(.min)
    FirebaseApp.configure()
    return true
}

import SwiftUI
import UIKit
// no changes in your AppDelegate class
class AppDelegate: NSObject, UIApplicationDelegate {
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
        print(">> your code here !!")
        return true
    }
}
@main
struct Testing_SwiftUI2App: App {
    // inject into SwiftUI life-cycle via adaptor !!!
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

import SwiftUI
import Firebase
@main
struct BookSpineApp: App {
  
  init() {
    FirebaseApp.configure()
  }
  
  var body: some Scene {
    WindowGroup {
      BooksListView()
    }
  }
}

Вы не должны вообще помещать такие коды в делегат приложения, иначе вы столкнетесь с Massive App Delegate. Вместо этого вам следует подумать о рефакторинге кода, чтобы получить более значимые части, а затем поместить нужную часть в нужное место. В этом случае единственное, что вам нужно, — это убедиться, что код выполняет эти функции после того, как приложение будет готово и только один раз. Так что метод init мог бы быть отличным:

@main
struct MyApp: App {
    init() {
        setupFirebase()
    }
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}
private extension MyApp {
    func setupFirebase() {
        FirebaseConfiguration.shared.setLoggerLevel(.min)
        FirebaseApp.configure()
    }
}

class CustomDelegate: NSObject, UIApplicationDelegate {
    static let Shared = CustomDelegate()
}

UIApplication.shared.delegate = CustomDelegate.Shared

NotificationCenter.default.addObserver(
    self,
    selector: #selector(<#T##@objc method#>),
    name: UIApplication.didBecomeActiveNotification,
    object: nil
)

@UIApplicationDelegateAdaptor(CustomDelegate.self) var appDelegate

struct PodcastScene: Scene {
    @Environment(\. scenePhase) private var phase
    var body: some Scene {
        WindowGroup {
            TabView {
                LibraryView()
                DiscoverView()
                SearchView()
            }
        }
        .onChange(of: phase) { newPhase in
            switch newPhase {
            case .active:
                // App became active
            case .inactive:
                // App became inactive
            case .background:
                // App is running in the background
            @unknown default:
                // Fallback for future cases
            }
        }
    }
}

class AppDelegate: NSObject, UIApplicationDelegate {
  var didFinishLaunching: ((AppDelegate) -> Void)?
  func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions
      launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil
  ) -> Bool {
    didFinishLaunching?(self)
    return true
  }
}
@main
struct MyApp: App {
  @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
  @ObservedObject private var applicationModel = ApplicationModel()
  // `init` gets called BEFORE `didFinishLaunchingWithOptions`
  init() {
    // Subscribe to get a `didFinishLaunching` call
    appDelegate.didFinishLaunching = { [weak applicationObject] appDelegate in
      // Setup any application code...
      applicationModel?.setup()
    }
  }
  var body: some Scene {
    return WindowGroup {
      if applicationObject.isUserLoggedIn {
        LoggedInView()
      } else {
        LoggedOutView()
      }
    }
  }
}

Значение этого свойства по умолчанию — false. Когда вы устанавливаете для него значение true, UIKit игнорирует события за пределами границ контроллера представления и предотвращает интерактивное отключение контроллера представления, пока он находится на экране . — Документация разработчика Apple

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

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

Долгое время разработчики iOS использовали AppDelegate в качестве основной точки входа для своих приложений. С запуском SwiftUI2 на WWDC 2020 Apple представила новый жизненный цикл приложения, который (почти) полностью устраняет AppDelegate, уступая место подходу, подобному DSL.

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

Поскольку фреймворк SwiftUI не является открытым исходным кодом, мы не можем увидеть, как Apple реализовала это, но Swift Argument Parser является открытым исходным кодом и также использует этот подход. Изучите исходный код ParsableCommand, чтобы узнать, как они используют расширение протокола для обеспечения реализации по умолчанию статической функции main, которая служит точкой входа в программу:

Если все это звучит немного сложно, хорошая новость заключается в том, что вам на самом деле не нужно беспокоиться об этом при создании нового приложения SwiftUI: просто не забудьте выбрать «SwiftUI App» в раскрывающемся списке Life Cycle при создании приложения, и вы сделали:

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

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

Начиная с iOS 14.0, Apple предоставила новый API, который позволяет более элегантно и удобно отслеживать состояние приложения: ScenePhase. В вашем проекте может быть несколько сцен, но есть вероятность, что у вас есть только одна сцена, обозначенная WindowGroup.

SwiftUI отслеживает состояние сцены в среде, и вы можете сделать текущее значение доступным для вашего кода, загрузив его с помощью оболочки свойства @Environment, а затем используя модификатор onChange(of:) для прослушивания любых изменений:

Стоит отметить, что вы также можете прочитать фазу из других мест в своем приложении. При чтении фазы на верхнем уровне приложения (как показано во фрагменте кода) вы получите совокупность всех фаз в вашем приложении. Значение .inactive означает, что ни одна из сцен в вашем приложении не активна.

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

Что действительно круто: вы можете установить несколько обработчиков URL-адресов в своем приложении, что значительно упростит создание ссылок на контент, поскольку вы можете обрабатывать входящие ссылки там, где это наиболее удобно.

Если возможно, вам следует использовать универсальные ссылки (или динамические ссылки Firebase, которые используют универсальные ссылки для приложений iOS), поскольку они используют связанные домены для создания связи между вашим веб-сайтом и вашим приложением. — это позволит вам безопасно обмениваться данными.

Еще одна причина, по которой вам может потребоваться AppDelegate, заключается в том, что вы используете какие-либо сторонние SDK, которые используют переключение методов для внедрения в жизненный цикл приложения. Firebase — это всем известный случай.

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

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

Большинство приложения под iOS пишутся с использованием UIKit, а значит, используют UIViewController. Они настолько же просты, насколько и сложны. Основная масса сложностей возникает из-за непонимания что, когда, как и зачем происходит внутри стандартных методов UIViewController.
Сразу определимся, разговор пойдет только о самых важных события жизненного цикла. Мы не будем касаться вопросов смены ориентации устройства, обработки событий клавиатуры, прерываний процесса работы и прочего.

«Жизнь» начинается.
Независимо от того, как именно инциализируется контроллер (UIViewController) (с подключение *.NIB файла или нормально), происходит вызов метода init, в котором и появляется значение переменной self, вернее, ее значение перестает быть nil и заменяется указателем на конкретный блок памяти.
ВАЖНО! Инициализируется только сам контроллер. Никакого вида (UIView) не существует (хотя он и инициализирован, т.е. обращение к self.view возможно). Если вы использует NIB-ы — никаких оутлетов на этом этапе еще нет. Соответственно — попытка создания или обращения к визуальным компонентам приведет к ошибке.
СТОИТ ПОМНИТЬ! В любой момент можно проверить, загружен вид в память или нет (а соответственно, можно ли обращаться к визуальным элементам) с помощью метода isViewLoaded. Главная его особенность в том, что он не «провоцирует» загрузку вида, если еще не загружен.

Создание вида (UIView).
В самом общем случае, создание вида (его загрузка в память) начинается в тот момент, когда произойдет любое обращение к self.view. Будет вызван метод loadView, результатом которого будет или созданный пустой вид, либо вид с элементами из NIB-а. Именно в этот момент наш котроллер и его вид становятся полностью доступными.
По оканчании загрузки будет вызван метод viewDidLoad
ВАЖНО! Загрузка вида, это именно загрузка, т.е. размещение всего необходимого для отображения вида в памяти. Не более того. Все загрузили и подготовили. Ждем команды «показать».
СТОИТ ПОМНИТЬ! Если вы интерфейс создаете нормально, т.е. с использованием кода, то собственные элементы интерфейса вы можете создавать/добавлять на вид/настраивать как в методе loadView, так и в метода viewDidLoad.
Если вы используете NIB-ы, то для настройки элементов интерфейса вам доступен только метод viewDidLoad.

Жизнь вида.
viewDidLoad — вид загружен и полностью готов к работе. Многим нравится именно в этом методе делать, т.с. «вторую часть инициализации контроллера». Привычка — вторая натура.
viewWillAppear — будет вызван перед тем, как начать отображение вида. В случае, если для отображения используется анимация — перед началом анимации.
viewDidAppear — будет вызван после окончания отображение вида. В случае, если для отображения используется анимация — после окончания анимации отображения.

viewDidUnload — вид выгружен из памяти
ВАЖНО! Выгружен сам вид, но не элементы интерфейса, которые мы создавали. Именно в этом методе их нужно уничтожить. Если вы используете NIB-ы — пришла пора очистить все оутлеты. Если вы этого не сделаете, система за вас это делать не будет.

Конец жизненного пути контроллера.
Когда вы уничтожите контроллер (указатель на него сбросите в nil) ARC очистит выделенную для него память. Перед этим будет вызван метод dealloc. Именно в нем нобходимо выполнить очистку и обнуление всех указтелей, которые вы создали для использования внутри контроллера.
ВАЖНО! Если вид контроллера еще отображается, а вы обнулите указатель на сам контроллер, то dealloc — будет вызван, а viewDidUnload — нет, вернее, скорее всего, что нет.

Обработка нехватки памяти
Метод didReceiveMemoryWarning вызывается системой, при нехватке памяти.
По умолчанию, реализация этого метода для контроллера, который не находится в видимой области, вызывает освобождение и удаление вида, что, в свою очередь, приведет к вызову viewDidUnload.
В любом случае — если система «потребовала» (этот метод — это именно требование) вам необходимо его исполнить как можно эффективней.
СТОИТ ПОМНИТЬ! Бог любит троицу. Система дажды потребует освобождения памяти (если вы не поняли с первого раза). Третий раз требование придет вместе с остановкой программы по критической ошибке. Все очень просто и надежно.

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

Независимо от того, интересуетесь ли вы тем, как тратите свое время, или хотите что-то изменить, Life Cycle станет вашим ежедневным помощником и предоставит вам всю необходимую информацию и идеи. Более того, он использует только 1% заряда аккумулятора вашего телефона, при этом без проблем выполняя свою работу.

• Автоматически — Life Cycle работает в фоновом режиме, записывая и сортируя то, что вы делаете, когда занимаетесь своими повседневными делами.
• Менее 1 % заряда батареи — Life Cycle использует менее 1 % заряда батареи в день, поскольку работает в фоновом режиме.
• Еженедельный журнал. Еженедельный обзор деятельности, сопровождаемый фотографиями, привязанными к прошедшим моментам.
• Из дня в год — просматривайте свою жизнь день за днем, неделю за неделей, месяц за месяцем или даже год за годом.
• Apple Health — полностью интегрирован. Импортирует все данные о деятельности, внимательности и сне.
• Друзья. Общайтесь со своими друзьями на Facebook и узнавайте, с кем вы проводите время, чем занимаетесь и где.
• Соединение цикла сна — для получения точных данных о сне подключитесь к будильнику цикла сна через Apple Health. (Life Cycle только считывает данные из Health, он не передает какие-либо данные. Он считывает данные анализа сна и шагов.)

• Подключитесь к своей учетной записи Sleep Cycle. Если у вас есть учетная запись онлайн-резервного копирования с помощью Sleep Cycle, Жизненный цикл позволит вам узнать, как ваши ежедневные привычки влияют на показатель качества сна.
• Резервное копирование. Защитите свои данные с помощью нашей системы резервного копирования. Никогда больше не беспокойтесь о потере журналов жизненного цикла.
• Графики. Помимо пончиков, Life Cycle показывает, что вы делаете со своим временем, в подробных графиках для более глубокого анализа. Визуальные эффекты дают вам представление о том, тратите ли вы свое время на то, что для вас наиболее важно.
• Сравните тенденции — узнайте, сокращается ли ваше время сна, слишком много ли вы работаете или больше гуляете на этой неделе. Сравните тенденции за недели, месяцы или годы.

ПОТРЕБЛЕНИЕ БАТАРЕИ
Продолжительное использование GPS в фоновом режиме может значительно сократить срок службы батареи. Life Cycle не использует GPS в фоновом режиме, а вместо этого полагается на вышки сотовой связи и местоположения Wi-Fi. В результате оно потребляет менее 1% заряда батареи в день, когда приложение работает в фоновом режиме.

• Жизненный цикл должен работать в фоновом режиме, чтобы иметь возможность записывать ваши данные. При этом он использует только 1% вашей батареи в день.
• Вам нужно носить с собой телефон, чтобы программа Life Cycle могла точно записывать и интерпретировать ваши действия.
• Для работы отслеживания на вашем телефоне должен быть включен Wi-Fi.

Если вы решите подписаться на Life Cycle Premium, стоимость покупки будет снята с вашей учетной записи iTunes. Вы можете управлять своей автоматически продлеваемой подпиской или отменить ее, войдя в настройки пользователя в iTunes после покупки. Подписка будет автоматически продлена за 24 часа до окончания периода подписки с той же подпиской, которую вы уже купили, и по той же цене. С вашего аккаунта будет взиматься плата за продление в течение 24 часов до окончания текущего периода. Любая неиспользованная часть бесплатного пробного периода, если она предлагается, будет аннулирована, когда пользователь приобретет подписку на эту публикацию, где это применимо.

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

Я тестирую бесплатную пробную версию уже несколько недель, и мне пока нравится идея этого приложения. Тем не менее, я не буду платить за премиум и не думаю, что буду придерживаться даже бесплатной версии из-за нескольких мелких ошибок, которые меня раздражают. Во-первых, есть некоторые ошибки с этим местоположением отслеживания приложения. Иногда это может занять пару дней, прежде чем всплывет сообщение о том, что я был в каком-то районе, или оно вообще не появится, тогда мне приходится вводить его вручную (что и раздражает, и неточно). Во-вторых, почему я не могу редактировать действия, которые уже есть в приложении? Мне не нужен вариант обеда и ужина, просто вариант «еда». Я мог бы создать свой собственный, но меня все равно раздражает, что другие варианты загромождают мою деятельность. В-третьих, действие в некатегоризированном месте будет иметь общую область на карте, помеченную для него. Но как только я ввожу пользовательское имя для местоположения, иногда местоположение не помечается? В-четвертых, хотелось бы иметь возможность как-то запускать активность в приложении и останавливать ее вручную. Вместо того, чтобы запоминать время начала и окончания и вводить его после того, как я закончу, если я хочу вручную создать действие. Наконец, было бы неплохо иметь больше вариантов цвета и иметь возможность просматривать свой день в хронологическом порядке, а также по категориям. В целом, концепция этого приложения великолепна, но я собираюсь удалить ее, потому что выполнение делает приложение более сложным в использовании, чем оно того стоит.

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

SpringBoard — это стандартное приложение для управления домашним экраном iPhone. Другие задачи включают в себя запуск WindowServer, запуск и загрузку приложений, а также настройку некоторых параметров устройства при запуске. В конце концов ваше приложение начинает выполняться, и делегат приложения получает уведомления.
Основная запись в приложениях iOS — это UIApplicationDelegate . Это — это протокол, и вам необходимо внедрить его в свое приложение, чтобы получать уведомления о пользовательских событиях, таких как запуск приложения, переход приложения в фоновый или активный режим, завершение работы приложения, открытие push-уведомления и т. д.
следующий →
← предыдущая
Приложение iOS работает в нескольких состояниях, которые называются состояниями жизненного цикла приложения. Каждый разработчик iOS должен знать о жизненном цикле приложения, что помогает понять его поведение. Каждое приложение iOS проходит через следующие состояния во время работы.
Не работает: считается, что приложение находится в состоянии «Не работает», если оно еще не запущено или не завершено системой или пользователем.
Неактивно: приложение находится в неактивном состоянии, когда оно находится на переднем плане, но получает события. Другими словами, мы можем сказать, что оно действует как состояние моста, в котором приложение ненадолго остается при переходе в другое состояние.
Active: это нормальный режим для приложения, когда оно находится в состоянии переднего плана и получает все пользовательские события.
Фон: приложение переходит в фоновое состояние, когда пользователь нажимает на главном экране во время использования приложения, или это требует дополнительного времени выполнения. Когда приложение вот-вот будет приостановлено, оно также переходит в это состояние на небольшой промежуток времени. В этом состоянии приложение остается в фоновом режиме и выполняет код.
Приостановлено: в этом состоянии приложение остается в фоновом режиме и не выполняет код. Приложение автоматически переводится в это состояние. В этом состоянии приложение остается в памяти. Однако активные приложения всегда имеют приоритет над приостановленными приложениями и могут быть удалены в любое время без предварительного уведомления.
Мы должны заметить, что когда мы создаем и запускаем приложение iOS в XCode, основной точкой входа приложения является UIApplicationDelegate, который представляет собой протокол, который приложение должно реализовать, чтобы получать уведомления о нескольких пользовательских событиях, таких как запуск приложения, приложение переходит в фоновом режиме, приложение переходит на передний план, push-уведомления и т. д.
UIApplicationDelegate содержит определенные методы жизненного цикла приложения, которые получают уведомление при запуске приложения. Методы UIApplicationDelegate приведены ниже.
application: didFinishLaunchingWithOptions:-> Bool: при первоначальном запуске приложения вызывается этот метод. В этом методе мы можем выполнить любую первоначальную настройку приложения, например настройку Firebase, пользовательскую навигацию и т. д. На этом этапе загружается раскадровка, но мы можем поддерживать восстановление состояния.
applicationWillEnterForeground: этот метод вызывается после didFinishLaunchingWithOptions. Он также вызывается, когда приложение переходит из фона на передний план.
applicationDidBecomeActive: этот метод вызывается после applicationWillEnterForeground. Если нам нужно выполнить какую-то конкретную задачу, когда приложение выходит на передний план, например, обновить шрифт и т. д., мы можем поместить код в этот метод.
applicationWillResignActive: этот метод уведомляется, когда приложение собирается стать неактивным. Например, пользователь получает телефонный звонок; пользователь нажимает кнопку «Домой» и т. д.).
приложениеDidEnterBackground: этот метод уведомляется, когда приложение переходит в фоновое состояние после того, как стало неактивным.
applicationWillTerminate: этот метод вызывается, когда приложение должно быть окончательно завершено из памяти. Если нам нужно выполнить какие-либо финальные очистки, мы можем поместить код в этот метод.
Мы можем поместить код, который будет выполняться при запуске приложения, в методе didFinishLaunchingWithOptions . Например, в приложении, в котором для использования приложения требуется вход пользователя в систему, мы можем проверить, вошел ли пользователь в приложение, проверив UserDefaults. Если пользователь вошел в систему, мы можем перейти к главному экрану; в противном случае мы можем перейти к экрану входа в систему.
Ниже приведен класс AppDelegate, который создается в первую очередь при создании любого проекта iOS.
@UIApplicationMain
класс AppDelegate: UIResponder, UIApplicationDelegate {
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
// Точка переопределения для настройки после запуска приложения.
вернуть истину
}
func applicationWillResignActive(_ приложение: UIApplication) {
// Отправляется, когда приложение собирается перейти из активного в неактивное состояние. Это может происходить при определенных типах временных прерываний (таких как входящий телефонный звонок или SMS-сообщение) или когда пользователь выходит из приложения, и оно начинает переход в фоновое состояние.
// Используйте этот метод, чтобы приостановить текущие задачи, отключить таймеры и сделать недействительными обратные вызовы рендеринга графики. Игры должны использовать этот метод для приостановки игры.
}
func applicationDidEnterBackground(_ приложение: UIApplication) {
// Используйте этот метод для освобождения общих ресурсов, сохранения пользовательских данных, аннулирования таймеров и сохранения достаточного количества информации о состоянии приложения, чтобы восстановить ваше приложение до его текущего состояния в случае, если оно будет остановлено позже.
// Если ваше приложение поддерживает фоновое выполнение, этот метод вызывается вместо applicationWillTerminate: когда пользователь завершает работу.
}
func applicationWillEnterForeground (_ приложение: UIApplication) {
// Вызывается при переходе из фонового состояния в активное; здесь вы можете отменить многие изменения, сделанные при входе в фон.
Utile.getCurrentViewController()?.viewDidLayoutSubviews()
}
func applicationDidBecomeActive(_ приложение: UIApplication) {
// Перезапустить все задачи, которые были приостановлены (или еще не запущены), пока приложение неактивно. Если приложение ранее работало в фоновом режиме, при необходимости обновите пользовательский интерфейс.
}
func applicationWillTerminate(_ приложение: UIApplication) {
// Вызывается, когда приложение вот-вот завершится. Сохраните данные, если это необходимо. См. также приложениеDidEnterBackground:.
}
Следующая темаЧто такое джейлбрейк в iOS
← предыдущая
следующий →
iOS предназначена для делегирования полномочий пользователей и предоставления им возможности использовать приложения интуитивно понятным и эффективным способом. Вся идея разработки приложения для iOS должна быть направлена на то, чтобы предоставить пользователям беспроблемный опыт работы с приложением. Таким образом, каждый разработчик должен понимать последовательность событий, происходящих в приложении. Эти серии событий называются Жизненный цикл приложения iOS .
Как только пользователь коснется значка приложения, Springboard, часть операционной системы, управляющая домашним экраном iOS, запускает приложение, которое начинает выполнение приложения, и делегат приложения получает уведомление.
Теперь, если у вас есть некоторое знание JAVA или C, вы знаете, что первый метод, который вызывается в вашей программе, это Основной . Точно так же в iOS у нас есть объект UIApplication , который будет внутренне вызывать UIApplicationMain . UIApplication отвечает за передачу всех ключевых событий своему делегату. Таким образом, можно сказать, что функция UIApplicationMain является основной точкой входа для создания объекта приложения, делегата приложения и настройки цикла событий.
« @UIApplicationMain » вызывается в классе AppDelegate, который использует Протокол UIApplicationDelegate . Каждое приложение iOS должно реализовать этот протокол, чтобы получать уведомления о пользовательских событиях, таких как запуск приложения, переход приложения в фоновый режим, переход приложения на передний план и т. д. : willFinishLaunchingWithOptions — Этот метод вызывается после успешного запуска приложения. Это первый метод из делегата приложения, который будет вызываться. Код выполняется, если запуск прошел успешно.
приложение: didFinishLaunchingWithOptions — вызывается далее. Этот метод обратного вызова вызывается, когда приложение завершило запуск и восстановило свое состояние. Этот метод можно использовать для доработки интерфейса и предоставления окну корневого контроллера представления.
Согласно документации Apple, вернуть false , если приложение не может обработать ресурс URL или продолжить действие пользователя, в противном случае вернуть верно . Возвращаемое значение игнорируется, если приложение запускается в результате удаленного уведомления.
applicationWillEnterForeground: Этот метод вызывается, когда приложение переходит из фонового состояния в активное, т. е. когда приложение перезапускается. Этот метод не вызывается, когда приложение запускается в первый раз, т.е. когда applicationDidFinishLaunch вызывается, но только когда он исходит из фона, т.е. applicationDidBecomeActive .
applicationDidBecomeActive: Этот метод вызывается сразу после applicationWillEnterForeground . Это должно сообщить вашему приложению, что оно перешло из неактивного состояния в активное. Вы должны использовать этот метод для перезапуска любых задач, которые были приостановлены.
applicationDidEnterBackground: Этот метод вызывается, когда ваше приложение переходит в фоновый режим после того, как стало неактивным. У вас есть примерно 5 секунд, чтобы выполнить любые задачи, необходимые для резервного копирования на случай, если приложение будет закрыто позже или сразу после этого.
applicationWillResignActive : этот метод вызывается, когда ваше приложение собирается перейти в неактивное состояние из активного состояния. Рассмотрим случай входящего телефонного звонка или случай, когда пользователь выходит из приложения, нажав кнопку «Домой». Любые текущие задачи могут быть приостановлены в этом методе.
applicationWillTerminate: Этот метод вызывается, когда ваше приложение вот-вот завершит работу. Здесь можно выполнить любую окончательную очистку вызова. Бывают случаи, когда этот метод может не вызываться, например, в случае перезагрузки устройства. Следовательно, разработчикам не следует ждать вызова этого метода для сохранения данных.
Здравствуйте! Я инженер iOS в Usetech, и в этой статье мы узнаем о жизненном цикле приложения iOS. Кроме того, мы также изучим различия в жизненном цикле в iOS 12 и 13, проверив выполнение этих методов жизненного цикла в симуляторе. Вот что вы узнаете к концу урока:
Наша цель — реализовать методы жизненного цикла, а затем посмотреть, в каком порядке они вызываются. Кроме того, мы также хотим знать, для чего лучше всего подходит каждый метод. Прежде чем приступить к изучению кода, давайте вспомним состояния любого iOS-приложения:
application(_:willFinishLaunchingWithOptions:) — вызывается при запуске приложения. В момент вызова метода наше приложение находится в неактивном состоянии, но уже загрузило основную раскадровку. Кроме того, восстановление состояния (восстановление иерархии экранов и состояния пользовательского интерфейса с момента последнего использования приложения пользователем) еще не запущено. Имеет параметр userInfo , который мы можем использовать для определения причины запуска приложения. Например, если приложение было запущено для открытия документа по определенному URL-адресу, мы можем захотеть предотвратить восстановление состояния. Чтобы узнать больше о возможных причинах запуска, посетите документацию.
application(_:didFinishLaunchingWithOptions:) — вызывается при запуске нашего приложения и восстановлении состояния приложения при необходимости. Однако пользовательский интерфейс еще не показан. Как и предыдущий метод, также имеет параметр userInfo . Как отмечает Apple, это последняя возможность выполнить логику, относящуюся к этому свойству.
applicationWillEnterForeground(_:) — вызывается в приложениях, не поддерживающих сцены. В противном случае он заменяется своим 9Ковариант 0261 sceneWillEnterForeground(_:) , который мы подробно рассмотрим при рассмотрении SceneDelegate позже. Метод вызывается, когда приложение переходит в активное состояние из фона .
applicationDidBecomeActive(_:) — вызывается в приложениях, не поддерживающих сцены. В противном случае он заменяется своим ковариантом sceneDidBecomeActive(_:) в SceneDelegate . Метод вызывается, когда приложение переходит в активное состояние. На данный момент пользовательский интерфейс загружен, но еще не показан.
applicationWillResignActive(_:) — вызывается в приложениях, не поддерживающих сцены. В противном случае он заменяется своим ковариантом sceneWillResignActive(_:) в SceneDelegate . Метод вызывается, когда приложение прерывается системными предупреждениями, телефонными звонками и т. д. Мы также запускаем его, когда закрываем приложение с помощью кнопки «Домой». Мы можем использовать этот метод для сохранения несохраненных данных. Например, мы можем захотеть сохранить список элементов на диске, чтобы, если система убьет приложение или мы принудительно закроем его, при следующем запуске мы могли снова увидеть все отображаемые элементы.
applicationDidEnterBackground(_:) — вызывается в приложениях, не поддерживающих сцены. В противном случае он заменяется своим ковариантом sceneDidEnterBackground(_:) в SceneDelegate . Метод вызывается, когда мы переводим приложение в фоновый режим. Здесь нам нужно убедиться, что мы остановили таймеры, уменьшили использование памяти приложением и, при необходимости, подготовились к восстановлению состояния в случае завершения работы приложения. Кроме того, после возвращает этот метод, UIKit делает снимок последнего пользовательского интерфейса приложения, чтобы отобразить его в переключателе приложений. Поэтому нам нужно скрыть от пользовательского интерфейса конфиденциальную информацию, например, пароли.
applicationWillTerminate(_:) — этот метод вызывается, когда приложение должно быть завершено и удалено из памяти. Он всегда вызывается для приложений, которые не поддерживают фоновый режим. Однако для приложений, у которых есть фоновые возможности, метод обычно не вызывается, так как приложение переходит в фоновое состояние. С другой стороны, если система решит освободить свою память и убьет приложение, работающее в фоновом режиме, будет вызван этот метод.
scene(_:willConnectTo:options:) — вызывается, когда приложение запрашивает пользовательский интерфейс. Как поясняется в документации по сценам, сцена содержит контроллеры окна и представления. По сути, этот метод вызывается, когда мы добавляем сцену в приложение. Большинство приложений имеют только одну сцену, поэтому в таких случаях этот метод вызывается один раз. Внутри метода мы настраиваем иерархию и устанавливаем корневой контроллер представления для окна. Например:
sceneWillResignActive(_:) — так же, как и его несценовый ковариант applicationWillResignActive(_:) , метод вызывается, когда приложение прерывается телефонным звонком или системным предупреждением. Мы также запускаем его, нажав на кнопку «Домой».
sceneDidEnterBackground(_:) — вызывается, когда приложение больше не отображается на экране. Как предлагает Apple, мы можем использовать этот метод, чтобы уменьшить использование памяти сценой и скрыть конфиденциальную информацию о пользователе с экрана, поскольку после возврата этого метода UIKit создаст снимок пользовательского интерфейса и покажет его в переключателе приложений.
Приложение. в то время как на iOS 13+ ковариантный метод sceneDidEnterBackground(_:) не вызывался. 3. В iOS 13+, когда приложение просто закрывалось, а не закрывалось, выполнялись следующие методы: sceneWillResignActive(_:) sceneDidEnterBackground(_:) On iOS 12: applicationWillResignActive(_:) applicationDidEnterBackground(_:) In this phase мы не замечаем никакой разницы, поскольку, как говорится в официальной документации, методы приложения iOS 12 и более ранних версий были заменены методами сцены iOS 13 и более поздних версий. 4. В iOS 13+, когда мы вернули приложение в активное состояние из фона, мы увидели следующие напечатанные методы: sceneWillEnterForeground(_:) sceneDidBecomeActive(_:)
В iOS 13 и более поздних версиях приложения могут поддерживать несколько окон на iPad. Это долгожданное дополнение, которое выводит многозадачность на iPad на новый уровень. В iOS 12 и более ранних версиях приложения управляют одним пользовательским интерфейсом и, как правило, одним окном. Чтобы добавить поддержку нескольких окон, Apple была вынуждена радикально переработать жизненные циклы приложения и пользовательского интерфейса на iOS.
Что эти изменения означают для вас и ваших приложений? Как никогда важно хорошо понимать жизненные циклы приложений и пользовательского интерфейса на iOS. Мы подробно исследуем оба жизненных цикла в этом и следующем эпизодах.
Что это значит для вас? Плохая новость заключается в том, что изменения значительны. Кривая обучения для разработчиков, плохо знакомых с iOS, стала немного круче, даже если вы создаете приложение, которое не поддерживает iPad или несколько окон.
Хорошая новость в том, что у вас есть время. Существующие приложения сегодня не нуждаются в реализации нового API. Тем не менее, вполне вероятно, что Apple потребует от разработчиков принять новый API в какой-то момент в будущем.
Если вы начинаете совершенно новый проект, предназначенный для iOS 13 и более поздних версий, я рекомендую использовать новый API. Важно, чтобы вы как можно раньше ознакомились с новым API. У приложений, которые хотят поддерживать несколько окон, нет другого выбора, кроме как принять новый API.
В iOS 12 и более ранних версиях жизненные циклы приложения и пользовательского интерфейса тесно связаны. Давайте подробнее рассмотрим оба жизненных цикла. Когда пользователь нажимает на значок вашего приложения, система создает процесс для вашего приложения, запускает ваше приложение и вызывает UIApplicationMain(_:_:_:_:) функция. Эта функция создает экземпляр класса UIApplication . Каждое приложение имеет один экземпляр класса UIApplication . Синглтон доступен через общий метод класса приложения UIApplication .
Синглтон UIApplication имеет объект делегата, который соответствует протоколу UIApplicationDelegate . Когда вы создаете новый проект, выбрав Single View App , Xcode создает для вас класс AppDelegate . Он соответствует протоколу UIApplicationDelegate и часто считается корневым объектом вашего приложения.
Синглтон UIApplication уведомляет делегата приложения о ряде событий жизненного цикла приложения, например, когда приложение завершило запуск и когда оно собирается быть завершенным системой. Я хочу, чтобы вы помнили, что приложение привязано к одному процессу и одному процессу.0261 Экземпляр UIApplication . Это верно для iOS 12 и более ранних версий и остается верным для iOS 13 и более поздних версий.
Когда система запускает ваше приложение, делегат приложения уведомляется об этом событии с помощью методов application(_:willFinishLaunchingWithOptions:) и application(_:didFinishLaunchingWithOptions:) . Обычно вы готовите приложение к запуску в application(_:didFinishLaunchingWithOptions:) . В этом методе вы настраиваете пользовательский интерфейс, создавая окно приложения, или окно создается за вас, если вы используете раскадровки.
Делегат приложения также уведомляется о событиях жизненного цикла пользовательского интерфейса, например, когда приложение переходит в активный или фоновый режим. Делегат приложения уведомляется о событиях жизненного цикла приложения, а также о событиях жизненного цикла пользовательского интерфейса.
Таким образом, приложение привязано к одному процессу, управляемому системой. Это просто означает, что невозможно запустить несколько экземпляров вашего приложения на iOS. Приложение UI singleton управляет одним пользовательским интерфейсом и одним окном. Делегат приложения уведомляется о событиях жизненного цикла пользовательского интерфейса приложений и . Это имеет смысл, потому что работает только один экземпляр вашего приложения, и этот экземпляр управляет одним пользовательским интерфейсом.
В iOS 13 и более поздних версиях приложение по-прежнему привязано к одному процессу, управляемому системой. Ваше приложение привязано к одному процессу, а это значит, что существует один Экземпляр UIApplication . Вы по-прежнему можете получить доступ к синглтону UIApplication через общий метод класса UIApplication . Синглтон UIApplication имеет делегат приложения, который соответствует протоколу UIApplicationDelegate .
Что изменилось, так это то, что делегат приложения больше не уведомляется о событиях жизненного цикла пользовательского интерфейса и что приложение может иметь несколько пользовательских интерфейсов или сцен . Делегат приложения больше не уведомляется, когда приложение переходит на передний или задний план, если приложение работает на iOS 13 или более поздней версии и принимает API на основе сцены .
То, как настраивается, управляется и отключается пользовательский интерфейс, сильно отличается в приложении на основе сцены . Делегат приложения больше не отвечает за создание окна приложения и управление им. Эта ответственность перекладывается на другого делегата, делегат сцены , объект, соответствующий протоколу UIWindowSceneDelegate . Это подразумевает, что любые события, связанные с жизненным циклом пользовательского интерфейса, например, выход приложения на передний или задний план, обрабатываются делегатом сцены, а не делегатом приложения.
В iOS 13 и более поздних версиях приложения могут поддерживать несколько сцен на iPad. Каждая сцена имеет свое состояние. Одна сцена может быть на переднем плане, а другая сцена может быть на заднем плане. Это означает, что больше нет смысла возлагать на делегата приложения ответственность за обработку событий жизненного цикла пользовательского интерфейса. Каждая сцена имеет по UIWindowSceneDelegate Объект, обрабатывающий события жизненного цикла пользовательского интерфейса сцены, к которой он привязан.
Важно понимать, что несколько сцен привязаны к одному процессу и одному экземпляру UIApplication . Существует один делегат приложения и один или несколько делегатов сцены. Другими словами, несколько сцен не являются результатом работы нескольких процессов или экземпляров вашего приложения. Система управляет одним процессом для вашего приложения, и этот процесс управляет одной или несколькими сценами.
Каждый проект, созданный с помощью Xcode 11, по умолчанию основан на сцене . Начните с открытия AppDelegate.swift . Шаблон для класса AppDelegate стал намного короче, чем раньше. Обратите внимание, что свойство окна отсутствует. Помните, что делегат приложения больше не отвечает за создание и настройку окна приложения. Это также означает, что он больше не имеет ссылки на окно.
 импорт UIKit
@UIApplicationMain
класс AppDelegate: UIResponder, UIApplicationDelegate {
    // MARK: - Жизненный цикл приложения
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication. LaunchOptionsKey: Any]?) -> Bool {
        вернуть истину
    }
    // MARK: - Жизненный цикл сеанса сцены
    func application(_ application: UIApplication, configurationForConnecting connectionSceneSession: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration {
        вернуть UISceneConfiguration (имя: «Конфигурация по умолчанию», sessionRole: connectSceneSession.role)
    }
    func application(_ application: UIApplication, didDiscardSceneSessions sceneSessions: Set) {
    
    }
}
 
Шаблон содержит знакомый метод application(_:didFinishLaunchingWithOptions:) протокола UIApplicationDelegate . Это не изменилось. Как следует из названия, метод application(_:didFinishLaunchingWithOptions:) вызывается после завершения запуска приложения. Делегат приложения уведомляется о том, что он может начать подготовку приложения к использованию. Приложение. Не пользовательский интерфейс.
 // ЗНАК: - Жизненный цикл приложения
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication. LaunchOptionsKey: Any]?) -> Bool {
    вернуть истину
}
 
Обратите внимание, что класс AppDelegate включает два дополнительных метода: application(_:configurationForConnecting:options:) и application(_:didDiscardSceneSessions:) . Мы рассмотрим эти методы позже. На данный момент вам нужно знать, что application(_:configurationForConnecting:options:) вызывается при создании сцены. Система спрашивает, какую конфигурацию следует использовать для создания сцены. Мы рассмотрим сцены более подробно позже. Запомните пока, что сцена — это то же самое, что и экземпляр пользовательского интерфейса вашего приложения.
Метод application(_:didDiscardSceneSessions:) вызывается при удалении сцены, например, когда пользователь открывает переключатель приложений и удаляет одну или несколько сцен, проводя пальцем вверх. Обратите внимание, что второй аргумент — это набор сеансов сцены. Возможно, что пользователь отбрасывает несколько сцен одновременно.
 // MARK: - Жизненный цикл сеанса сцены
func application(_ application: UIApplication, configurationForConnecting connectionSceneSession: UISceneSession, options: UIScene.ConnectionOptions) -> UISceneConfiguration {
    вернуть UISceneConfiguration (имя: «Конфигурация по умолчанию», sessionRole: connectSceneSession.role)
}
func application(_ application: UIApplication, didDiscardSceneSessions sceneSessions: Set) {
    
}
 
Теперь посмотрим на SceneDelegate.swift . Класс SceneDelegate является новым и автоматически добавляется в проекты на основе сцен. Обратите внимание, что свойство окна , которое отсутствовало в классе AppDelegate , было перемещено в класс SceneDelegate . Мы рассмотрим содержимое класса SceneDelegate более подробно позже.
 импорт UIKit
класс SceneDelegate: UIResponder, UIWindowSceneDelegate {
    // МЕТКА: - Свойства
    
    переменное окно: UIWindow?
    // MARK: - Делегат сцены окна
    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene. ConnectionOptions) {
        guard let _ = (сцена как? UIWindowScene) else { return }
    }
    func sceneDidDisconnect (_ сцена: UIScene) {
        
    }
    // ОТМЕТКА: -
    
    func sceneDidBecomeActive (_ сцена: UIScene) {
    }
    func sceneWillResignActive(_сцена: UIScene) {
    }
    func sceneWillEnterForeground (_ сцена: UIScene) {
    }
    func sceneDidEnterBackground (_ сцена: UIScene) {
    }
}
 
Прежде чем мы закончим этот эпизод, я хочу показать вам еще одно важное изменение. Откройте Info.plist . Он содержит ключ с именем Application Scene Manifest . Наличие этого ключа указывает на то, что приложение принимает API на основе сцен .
Значение представляет собой словарь с двумя ключами, Включить несколько окон и Конфигурация сцены . Значение Enable Multiple Windows установлено на НЕТ по умолчанию. Для приложений, поддерживающих несколько окон на iPad, устанавливается значение YES .