Как распарсить json файл swift

Обновлено: 04.07.2024

Однако, похоже, идеи, изложенные там, неприменимы в этом сценарии.

Как правильно разобрать ответ JSON в Swift 3? Что-то изменилось в способе чтения JSON в Swift 3?

Ниже приведен рассматриваемый код (его можно запустить на детской площадке):

Изменить: вот пример результатов вызова API после print(currentConditions)

Можете ли вы поместить образцы данных, возвращенные вашим вызовом API? Да, я только что добавил образец результатов, напечатанных после печати (currentConditions). Надеюсь, поможет.

Прежде всего, никогда не загружайте данные синхронно с удаленного URL-адреса , всегда используйте асинхронные методы, например URLSession .

происходит потому, что компилятор не знает, к какому типу относятся промежуточные объекты (например, currently в ["currently"]!["temperature"] ), и поскольку вы используете типы коллекций Foundation, такие NSDictionary как компилятор, не имеет никакого представления о типе.

Кроме того, в Swift 3 требуется сообщить компилятору тип всех объектов с индексами.

Вы должны привести результат сериализации JSON к фактическому типу.

Этот код использует URLSession и исключительно Swift собственные типы

Чтобы распечатать все пары ключ / значение, currentConditions вы можете написать

Примечание относительно jsonObject(with data :

Многие (кажется, все) учебники предлагают .mutableContainers или .mutableLeaves варианты, что в Swift - полная ерунда. Эти две опции являются устаревшими опциями Objective-C для присвоения результата NSMutable. объектам. В Swift любой var iable является изменяемым по умолчанию, и передача любого из этих параметров и присвоение результата let константе вообще не имеет никакого эффекта. Кроме того, большинство реализаций никогда не изменяют десериализованный JSON.

Только (редко) вариант , который является полезным в Swift является .allowFragments который необходим , если если корневой объект JSON , может быть типом значения ( String , Number , Bool или null ) , а не один из типов коллекций ( array или dictionary ). Но обычно options параметр опускается, что означает « Нет параметров» .

JSON - это хорошо организованный текстовый формат. Читать строку JSON очень легко. Внимательно прочтите строку . Всего существует шесть различных типов - два типа коллекций и четыре типа значений.

  • Массив - JSON: объекты в квадратных скобках [] - Swift: [Any] но в большинстве случаев [[String:Any]]
  • Словарь - JSON: объекты в фигурных скобках <> - Swift: [String:Any]
  • Строка - JSON: любое значение в двойных кавычках "Foo" , даже "123" или "false" - Swift: String
  • Число - JSON: числовые значения не в двойных кавычках 123 или 123.0 - Swift: Int или Double
  • Bool - JSON: true или false без двойных кавычек - Swift: true или false
  • null - JSON: null - Swift: NSNull

Согласно спецификации JSON все ключи в словарях должны быть String .

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

Если корневой объект является словарем ( <> ), приведите тип к [String:Any]

и получать значения по ключам с ( OneOfSupportedJSONTypes это либо коллекция JSON, либо тип значения, как описано выше).

Если корневой объект является array ( [] ), приведите тип к [[String:Any]]

и перебрать массив с помощью

Если вам нужен элемент в определенном индексе, проверьте также, существует ли индекс

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

Apple опубликовала исчерпывающую статью в блоге Swift: Работа с JSON в Swift

Например, данный образец JSON в вопросе (слегка изменен)

можно декодировать в структуру Weather . Типы Swift такие же, как описано выше. Есть несколько дополнительных опций:



JSON (JavaScript object notation) - это распространенный формат передачи данных на веб-серверы.

JSON очень прост в использовании и удобен для чтения, что делает его невероятно популярным.

Разберем следующий фрагмент JSON:

В Objective-C парсинг и десериализация JSON достаточно просты:

Парсинг и десериализация в Swift проходят более утомительно из-за опционалов Swift:

В коде выше, каждый объект JSON должен быть проверен перед использованием, через опциональную привязку. Это делает наш код более безопасным, но и более уродливым.

В этом руководстве вы изучите более простой способ парсинга JSON в Swift, путем использования открытой библиотеки SwiftyJSON.

В частности, вы будете использовать SwiftyJSON для разбора JSON документа, который содержит 25 топовых приложений в US AppStore. Вы увидите, что разбор JSON в Swift, может быть таким же простым, как и в Objective-C.

Заметка

Чтение этого туториала предполагает наличие у вас начальных знаний в Swift. Если вы таких не имеете, то скорее проходите наше первое знакомство со Swift.

Поехали!

Скачайте начальный проект и запустите его. Вы увидите пустой view controller:


Стоит оговориться, что пользовательский интерфейс не особо важен для данного туториала, так как вы будете работать только с консолью. Привыкайте в вашему белому экрану! :]

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

  1. TopApps.json: содержит JSON для парсинга.
  2. AppModel: Файл отображающий наше приложение. Ваша цель - разобрать JSON в коллекцию этих объектов.
  3. DataManager: Управляет получением данных локально или по сети. Вы будете использовать методы этого файла для загрузки JSON.
  4. ViewController: Пустой view controller. Вы добавите сюда код для запроса данных из DataManager.swift и отпарсите его несколькими способами.

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

Разбираем JSON нативным способом Swift

Заметка

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

Сначала, мы отпарсим JSON оригинальным способом Swift, то есть мы не будем использовать никаких внешних библиотек. Это поможет нам оценить пользу библиотеки SwiftyJSON.

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

Откройте ViewController.swift и добавьте следующий код в конец метода viewDidLoad():

Прокручиваете глазами этот каскадный список закрывающихся скобок? :] Вот что у нас тут происходит:

  1. Сначала вы десериализуете (преобразуете из последовательного формата в параллельный), используя NSJSONSerialization .
  2. Затем, вам нужно проверить каждое значение сабскрипта в объекте JSON, чтобы убедиться, что они не nil .
  3. После того, как вы уверены, что они не nil , вы ищите следующий объект.
  4. После того, как вы прошли весь путь через все сабскрипты, вы получаете отображение значения appName .

Если какой-либо элемент в JSON будет неожиданным, то вы получите полный беспорядок и имя приложения никогда не появится у вас на экране.

  1. Последний шаг - просто выводим значения appName в дебаггере.

Запустите ваше приложение: вы должны увидеть в вашей консоли дебаггера вот что:

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

Интрегрирование SwiftyJSON в ваш проект

Эту библиотеку очень просто интегрировать.

Перейдите на страницу SwiftyJSON github. Затем, перетащите SwiftyJSON\SwiftyJSON.swift в наигацию вашего проекта Xcode. Убедитесь, что у вас стоит галочка на Copy items if needed и что у вас выбрано TopApps, затем, нажмите Finish

Вот и все! Вы только что интегрировали библиотеку в ваш проект, и теперь вы можете парсить JSON без головной боли опциональной привязки!

Парсим JSON через SwiftyJSON

Замените метод viewDidLoad() следующим:

И это весь код, который вам понадобится!

Сначала, вы создаете константу JSON , через метод int типа JSON() и ваш объект данных. Затем, SwiftyJSON конвертирует эти данные в объект JSON, используя NSJSONSerialization .

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

Итак, мы хотим получить строковое значение, по этому передаем .stringValue в конец процесса парсинга. Если необходимо получить массив, то передаем .arrayValue . Остальные возвращаемые типы используют аналогичную конструкцию.

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

Библиотека берет на себя парсинг локальных данных, но как она работает с удаленным источником данных?

Получение удаленного JSON

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

Идем в DataManager.swift и добавляем следующий метод:

Этот код выглядит достаточно знакомым, но вместо получения локального файла, вы используете NSURLSession , для извлечения данных с iTunes. Вот что происходит в деталях:

Сначала вы вызываете метод loadDataFromURL() , который принимает URL и замыкание (closure), которое передает объект NSData . Следующим шагом вы проверяете существование значения, используя опциональную привязку. Наконец, вы передаете данные в замыкание success, как мы делали ранее. Откройте ViewController.swift и добавьте следующие строки в конец метода viewDidLoad() :

Код выше практически такой же, как тот, который вы писали в первой секции, но теперь вы получаете данные из iTunes.

На самом деле, значения сверху могут отличаться, так как лучшие приложения AppStore тоже меняются.

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

Разбираем JSON для заполнения массивов

Добавьте следующий код в ViewController.swift, сразу после комментария "More soon":

Код, который приведен выше, перебирает все приложения в ответе JSON и создает модели объекта AppModel:

  1. Сначала вы получаете список приложений с SwiftyJSON
  2. Следующим шагом вы создаете изменяемый массив для хранения объектов, которые будут созданы.
  3. Затем, вы перебираете все элементы и создаете AppModel из данных JSON.
  4. И последнее, вы выводите на экран список новых объектов в консоли дебаггера.


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

Вот и все что нужно, для использования JSON в Swift. Остальная часть туториала опциональна, так как она посвящена работе SwiftyJSON непосредственно под "капотом".

Заглядываем под капот SwiftyJSON

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

Когда вы вызываете JSON() , вы передаете экземпляр опционального NSData или даже AnyObject . JSONValue() является инициализатором для перечисления (enum) в SwiftyJSON:

Оно работает через сабскрипт языка Swift:

Обратите внимание, что результатом оператора сабскрипта является другой объект JSON. Зависит от вас, какой тип вы хотите вернуть из этого JSON. В нашем случае, мы хотим вернуть имя приложения, то есть тип Sting , так что вы просто добавляете .stringValue в конец объекта JSON.

Метод string() один из множества способов, которые названы в честь типа, который они возвращают из объекта JSON. Каждая функция возвращает опциональную тезку типа.

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

Но, мы пока что еще не затронули обработку ошибки в SwiftyJSON. Вот как можно обработать неправильное условие в SwiftyJSON:

Мы очень рекомендуем посмотреть как работает SwiftyJSON, так как эта библиотека демонстрирует качественную комбинацию полезных техник Swift, для получения отличного результата.

Конечный проект вы можете скачать здесь.

Что дальше?

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

Написать эту статью меня сподвиг почти случившийся нервный срыв, причиной которого стало мое желание научиться общаться с сторонними API, конкретно меня интересовал процесс декодирования JSON-докуметов! Нервного срыва я, к счастью, избежал, поэтому теперь настало время сделать вклад в сообщество и попробовать опубликовать свою первую статью на Хабре.

Почему вообще возникли проблемы с такой простой задачей?

Чтобы понять, откуда проблемы, нужно сначала рассказать об инструментарии, которым я пользовался. Для декодирования JSON-объектов я использовал относительно новый синтезированный (synthesized) протокол библиотеки Foundation - Сodable.

Codable - это встроенный протокол, позволяющий заниматься кодированием в объект текстового формата и декодированием из текстового формата. Codable - это протокол-сумма двух других протоколов: Decodable и Encodable.

Cтоит сделать оговорку, что протокол называется синтезированным тогда, когда часть его методов и свойств имеют дефолтную реализацию. Зачем такие протоколы нужны? Чтобы облегчить работу с их подписанием, как минимум уменьшив количество boilerplate-кода.

Еще такие протоколы позволяют работать с композицией, а не наследованием!

Вот теперь поговорим о проблемах:

Во-первых, как и все новое, этот протокол плохо описан в документации Apple. Что я имею в виду под "плохо описан"? Разбираются самые простые случаи работы с JSON объектами; очень кратко описаны методы и свойства протокола.

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

В-третьих, то что гуглится простыми методами не рассказывает о сложных случаях

Теперь давайте поговорим о конкретном кейсе. Кейс такой: используя API сервиса Flickr, произвести поиск N-фотографий по ключевому слову (ключевое слово: читай поисковой запрос) и вывести их на экран.

Сначала все стандартно: получаем ключ к API, ищем нужный REST-метод в документации к API, смотрим описание аргументов запроса к ресурсу, cоставляем и отправляем GET-запрос.

И тут видим это в качестве полученного от Flickr JSON объекта:

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

Что имеем? Имеем ситуацию, где необходимо составить два последовательных GET-запроса к разным ресурсам, причем второй запрос будет использовать информацию первого! Соответственно алгоритм действий: запрос-декодирование-запрос-декодирование. И вот тут. и начались проблемы. От JSON-объекта полученного после первого запроса мне были нужен только массив с информацией о фото и то не всей, а только той, которая репрезентует информацию о его положении на сервере. Эту информацию предоставляют поля объекта "photo": "id", "secret", "server"

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

Вся остальная "мишура" на не нужна. Так вот материала, описывающего best practices обработки такого JSON-объекта очень мало.

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

Здесь все предельно просто. Нужно создать структуру данных, имена свойств которой будут совпадать с ключами JSON-объекта (здесь это "id", "secret", "server"); типы свойств нашей структуры также обязаны удовлетворять типам, которым равны значения ключей (надеюсь, не запутал). Далее нужно просто подписаться на протокол Decodable, который сделает все за нас, потому что он умеет работать с вложенными типами (то есть если типы свойств являются его подписчиками, то и сам объект тоже будет по умолчанию на нее подписан). Что значит подписан? Это значит, что все методы смогут определиться со своей реализацией "по умолчанию". Далее процесс парсинга целиком. (Я декодирую из строки, которую предварительно перевожу в объект типа Data, потому что метод decode(. ) объекта JSONDecoder работает с Data).

Полезные советы:

Также полезным на мой взгляд является сервис jsonformatter.curiousconcept.com . Он предоставляет доступ к функционал выравниванивания "кривых" REST объектов, которые обычно показывает нам консоль Playground Xcode.

Последний мощный tool - app.quicktype.io - он описывает структуру данных на Swift по конкретному JSON-объекту.

Вернемся к мучениям. Парсинг:

Обратите внимание на то, что любой ключ JSON-объекта, использующий следующую нотацию "key" : "sometexthere" для Decodable видится как видится как String, поэтому такой код создаст ошибку в run-time. Decodable не умеет явно coerce-ить (приводить типы).

Усложним задачу. А что если нам пришел такой объект?

Здесь все элементарно, потому что Decodable умный протокол, который умеет парсить только те свойства, которые описывает наша структура и не "ругаться " на то, что некоторые свойства отсутствуют. Это логично, потому что хоть API и должно являться устойчивым, по мнению последователей "Чистого архитектора" Роберта Мартина, но никто не гарантирует нам то, что его разработчики баз данных не захотят, например, внести новых свойств. Если бы это не работало - наши приложения бы постоянно "крашились".

Разберем дополнительный функционал доступный из коробки. Следующий вид JSON-объекта:

Тут придется добавить всего несколько логичных строк (или даже символов) кода. Помним, что массив объектов конкретного типа - это тоже тип!

Добавление квадратных скобок к имени типа все сделало за нас, а все потому что [Photo] - это конкретный тип в нотации Swift. На что можно напороться с массивами: массив из одного объекта - тоже массив!

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

Сначала залезем немного "под капот" Decodable и еще раз поймем, что такое JSON.

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

JSON - ОО текстовый формат. Что же это значит? То, что он общается с программистами на уровне объектов в привычном понимании ООП, только объекты эти утрированные: методы с помощью JSON мы передать не можем (можем, но зачем). Что все это значит? Это значит то, что любая открывающая фигурная скобка открывает новый контейнер (область видимости)

Decodable может перемещаться по этим контейнерам и забирать оттуда только необходимую нам информацию.

Сначала поймем, каким инструментарием необходимо пользоваться. Протокол Decodable определяет generic enum CodingKeys, который сообщает парсеру (декодеру) то, как именно необходимо соотносить ключ JSON объекта с названием свойства нашей структуры данных, то есть это перечисление является ключевым для декодера объектом, с помощью него он понимает, в какое именно свойство клиентской структуры присваивать следующее значение ключа! Для чего может быть полезна перегрузка этого перечисления в топорных условиях, я думаю всем ясно. Например, для того, чтобы соблюсти стиль кодирования при парсинге: JSON-объект использует snake case для имен ключей, а Swift поощряет camel case. Как это работает?

rawValue перечисления CodingKeys говорят, как выглядят имена наших свойств в JSON-документе!

Отсюда мы и начнем наше путешествие внутрь контейнера! Еще раз посмотрим на JSON который нужно было изначально декодировать!

Первый контейнер определяет объект, состоящий из двух свойств: "photos", "stat"

Контейнер "photos" в свою очередь определяет объект состоящий из пяти свойств: "page", "pages", "perpages", "total", "photo"

"photo" - просто массив контейнеров, некоторый свойства из которых нам нужны.

Как можно решать задачу в лоб?

Объявить кучу вложенных типов и радоваться жизни. Итог пишем dummy алгоритмы ручного приведение между уже клиентскими объектами. Это нехорошо!

Пользоваться функционалом Decodable протокола, а точнее его перегружать дефолтную реализацию инициализатора и переопределять CodingKeys! Это хорошо! Оговорка: к сожалению Swift (по понятным причинам!) не дает определять в extension stored properties, а computed properties не видны Сodable/Encodable/Decodable, поэтому красиво работать с чистыми JSON массивами не получится.

Решая вторым способом, мы прокладываем для декодера маршрут к тем данным, которые нам нужны: говорим ему зайди в контейнера photos и забери массив из свойства photo c выбранными нами свойствами

Сразу приведу код этого решения и уже потом объясню, как он работает!

Вот и все, теперь когда экземпляр объекта JSONDecoder. Будет вызывать decode() - под капотом он будет использовать наш инициализатор для работы с декодированием

Подводя итоги, хотелось бы сказать, что работа с сетью в iOS-разработке наполнена разнообразными "сюрпризами", поэтому если вы можете что-то добавить в комментариях - обязательно делайте это!


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

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

Тогда я открыл документацию Свифта и прочел там каждую строчку по тому, как нужно правильно парсить JSON файлы.

Прочитал и ничего не понял.

Наверное, именно этот туториал я бы отправил себе в 2014г, когда я только начал разработку на свифте.

Для того, чтобы следовать этому туториалу, вам понадобится Xcode (можно скачать в App Store), cocoapods (можно скачать здесь), а еще я архив со стартером и готовым проектом проготовил. Они здесь.

Поехали! 🚀

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

Во второй части я расскажу, как можно быстро запилить собственный парсер, используя только те инструменты, которые предлагает нам Xcode out of the box.

А теперь точно поехали 😅🚀

Скачиваем проект и заходим в папку. Открываем в терминале и пишем

После этого cocoapods загрузит нам SwiftyJSON. Открываем .xcworkspace файл и давайте немного осмотримся.

Итак, в папке ParseJSON мы видим ParseJSON.playground. Именно здесь мы и проведем большую часть времени.

Нажимаем на черную стрелочку и обнаруживаем две папки:


В первой лежит наш JSONHelper — небольшой метод, который позволяет прочитать JSON — файл, во второй же — сам тестовый JSON.

Также мы видим проект, который называется Pods, там лежит наша библиотека.

Открываем ParseJSON.playground. В верхней части файла, прямо под “import UIKit” добавим “import SwiftyJSON”, что подключит нашу библиотеку к плейграунду.

Пришла пора вызвать наш JSON.

Осталось его распарсить. Для этого я предлагаю создать несколько объектов.

Как мы могли заметить, когда открывали файл, или когда посмотрели в экран дебага, наш JSON состоит, потенциально, из двух объектов: User и Location. Теоретически, никто не мешает нам впихнуть все в одну модель, но вдруг Location придется где-то еще использовать 🤔

Создадим новый файл в Resources. Придется все делать public, потому что таково желание playground, но в реальном проекте ни классу, ни переменным не придется public добавлять.

Вместо “import Foundation” пишем “import SwiftyJSON”.

В качестве переменных укажем те поля, которые нам приходят в JSON-файле, а именно, firstName, lastName, email и остальное, кроме Location.

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

Не забудьте добавить метод инициализатора (init), чтобы данные из JSON как-то попали в класс.

А дальше все просто — проверяем наличие того или иного поля и добавляем его в наш класс:

К слову, перед этим можно проверить, не nil ли наш JSON. (В данном случае это излишне, потому как мы точно знаем, что он есть, но в настоящем проекте лишним не будет.)

Такая проверка позволит нам безопасно проверить, есть ли такой объект в JSON-файле, и добавить его значение к соответствующей переменной в классе.

После того, как все переменные из пользователя оказались в классе User, мы получаем примерно такую структуру:

Итак, пришла пора проверить, насколько нам это удалось. Возвращаемся в playground и добавляем следующую строку:

И вуаля, мы получили first и last name нашего пользователя в debug window!

Теперь ваша очередь, попробуйте создать Location и включить его в класс User 😏

На вашем месте я бы сделал примерно так:

А затем добавил этот класс к пользователю:

Осталось проверить это в playground 😉

Поздравляем, вы только что распарсили JSON 😎

Надеюсь, это было не скучно, и вы узнали из этого туториала что-то новое и интересное. Если вам тоже так кажется, то лайк-репост. И не забывайте, это была только первая часть, во второй я покажу, как можно парсить JSON без использования сторонних библиотек.
Только стандартные методы из Foundation, только хардкор 🔥

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