Жесткое кодирование NSUserActivityTypes для восстановления различных моделей данных - PullRequest
Новая
       81

Жесткое кодирование NSUserActivityTypes для восстановления различных моделей данных

2 голосов
/ 20 января 2020

Начиная с iOS 13, Apple рекомендует хранить пользовательское состояние, используя объект NSUserActivity, прикрепленный к сцене, поэтому я пытался а) лучше понять, как работает NSUserActivity, и б) реализовать это в мой собственный код Работая с документацией Apple, я натолкнулся на этот фрагмент кода: 

        class var activityType: String {
        let activityType = ""

        // Load our activity type from our Info.plist.
        if let activityTypes = Bundle.main.infoDictionary?["NSUserActivityTypes"] {
            if let activityArray = activityTypes as? [String] {
                return activityArray[0]
            }
        }

        return activityType
    }

Я понимаю , что делает (он ищет в файле Info.plist запись под названием "NSUserActivityTypes" msgstr ", если он существует, он пытается получить связанный массив ActivityTypes, а затем читает первый элемент в массиве), но я не понимаю, что такое почему . В частности, я не понимаю, почему мы читаем только первый элемент в ActivityArray. В этом случае мы знаем, что первый (и единственный элемент) это «com.apple.apple-samplecode.StateRestoration.activity», потому что мы должны вручную создать эту запись в plist. Но я не понимаю, почему мы жестко программируем, глядя на первый элемент массива, чтобы получить тип активности, потому что, если мы знаем, мы просто собираемся вернуть String "com.apple.apple-samplecode. StateRestoration.activity ", почему бы просто не написать следующий код: 

class var activityType: String {
       return "com.apple.apple-samplecode.StateRestoration.activity"
    }

Я никогда раньше не работал с NSUserActivity, и я понимаю, что его можно (обычно?) Использовать для других целей, кроме сохранение / восстановление состояния, поэтому может быть много разных видов полезных действий, которые может поддерживать ваше приложение (передача обслуживания, интеграция Siri и т. д. c.). Поэтому я хотел бы предположить, что мы хотим, чтобы наш код был максимально надежным, чтобы не делать никаких предположений о видах объектов NSUserActivity, которые мы могли бы получить.

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

Кроме того, это не уникальный пример кода Apple ... В этом блоге * В сообщении 1018 * также используется аналогичный подход при чтении файла Info.plist: 

extension Bundle {
    var activityType: String {
        return Bundle.main.infoDictionary?["NSUserActivityTypes"].flatMap { ($0 as? [String])?.first } ?? ""
    }
}

1 Ответ

0 голосов
/ 27 апреля 2020

Я думаю, что оба примера кода являются просто фиктивными способами объяснить, как работают состояния. Там они используют один идентификатор восстановления (com.apple.apple-samplecode.StateRestoration.activity), но ваше приложение может иметь больше, чем, поэтому, как вы говорите, пример кода больше не будет иметь смысла.

Также обратите внимание, что даже при использовании один идентификатор восстановления у вас есть все поля NSUserActivity (включая userInfo), чтобы помочь вам различать guish между состояниями. Конечно, было бы грязно иметь разные состояния с одним и тем же идентификатором восстановления.

...