На данный момент подавляющее большинство мобильных приложений являются клиент-серверными. Повсюду происходит подгрузка, синхронизация, отправка событий и основным способом взаимодействия с сервером является обмен данными посредством формата json.
Key decoding
В Foundation присутствует два механизма сериализации-десереадизации данных. Старый — NSJsonSerialization и новый – Codable. Последний в списке достоинств имеет в себе такую замечательную вещь, как автогенерация ключей для json данных на основе структуры (или класса), реализующей Codable (Encodable, Decodable) и инициализатора для декодирования данных.
И вроде бы всё прекрасно, можно использовать и радоваться, но реальность не так проста.
Довольно часто на сервере можно встретить json вида:
{"topLevelObject": { "underlyingObject": 1 }, "Error": { "ErrorCode": 400, "ErrorDescription": "SomeDescription" } }
Это почти реальный пример с одного из серверов по проекту.
Для класса JsonDecoder можно указать работу со snake_case ключами, но что делать, если у нас UpperCamelCase, dash-snake-case или вообще сборная солянка, а вручную ключи писать не хочется?
К счастью, Apple предоставила возможность конфигурировать преобразование ключей перед их сопоставлением с CodingKeys структуры с помощью JSONDecoder.KeyDecodingStrategy. Этим мы и воспользуемся.
Для начала создадим структуру, реализующую протокол CodingKey, потому что таковой нет в стандартной библиотеке:
struct AnyCodingKey: CodingKey { var stringValue: String var intValue: Int? init(_ base: CodingKey) { self.init(stringValue: base.stringValue, intValue: base.intValue) } init(stringValue: String) { self.stringValue = stringValue } init(intValue: Int) { self.stringValue = "\(intValue)" self.intValue = intValue } init(stringValue: String, intValue: Int?) { self.stringValue = stringValue self.intValue = intValue } }
Затем необходимо отдельно обработать каждый case наших ключей. Основные:
snake_case, dash-snake-case, lowerCamelCase и UpperCamelCase. Проверяем, запускаем, всё работает.
Затем сталкиваемся с довольно ожидаемой проблемой: аббревиатуры в camelCase’ах (вспомните многочисленные id, Id, ID). Чтобы всё заработало, необходимо правильно их преобразовать и ввести правило – аббревиатуры преобразуются в camelCase, сохраняя большой только первую букву и myABBRKey превратится в myAbbrKey.
Данное решение отлично работает и для сочетаний нескольких кейсов.
Note: Implementation will be provided into .custom key decoding strategy.
static func convertToProperLowerCamelCase(keys: [CodingKey]) -> CodingKey { guard let last = keys.last else { assertionFailure() return AnyCodingKey(stringValue: "") } if let fromUpper = convertFromUpperCamelCase(initial: last.stringValue) { return AnyCodingKey(stringValue: fromUpper) } else if let fromSnake = convertFromSnakeCase(initial: last.stringValue) { return AnyCodingKey(stringValue: fromSnake) } else { return AnyCodingKey(last) } }
Date decoding
Следующая рутинная проблема – способ передачи дат. Микросервисов на сервере много, команд чуть меньше, но тоже приличное количество и в итоге мы оказываемся перед кучей форматов дат вида «да я стандартную использую». К тому же, кто-то передаёт даты строкой, кто-то в Epoch-time. В итоге у нас снова оказывается сборная солянка из сочетаний строки-числа-таймзоны-миллисекунд-разделителей, а DateDecoder в iOS жалуется и требует строгий формат дат. Решение тут несложное, просто перебором ищем признаки того или иного формата и комбинируем их, получая в итоге необходимый. Данные форматы успешно и стопроцентно покрывали мои кейсы.
Note: This is custom DateFormatter initializer. Its just set format to created formatter.
static let onlyDate = DateFormatter(format: "yyyy-MM-dd") static let full = DateFormatter(format: "yyyy-MM-dd'T'HH:mm:ss.SSSx") static let noWMS = DateFormatter(format: "yyyy-MM-dd'T'HH:mm:ssZ") static let noWTZ = DateFormatter(format: "yyyy-MM-dd'T'HH:mm:ss.SSS") static let noWMSnoWTZ = DateFormatter(format: "yyyy-MM-dd'T'HH:mm:ss")
Пристёгиваем это к нашему декодеру с помощью JSONDecoder.DateDecodingStrategy и получаем декодер, который обрабатывает почти всё, что угодно и преобразует в удобоваримый для нас формат.
Тесты производительности
Тесты производились для json строки размером 7944 байта.
| convertFromSnakeCase strategy | anyCodingKey strategy | |
|---|---|---|
| Absolute | 0.00170 | 0.00210 |
| Relative | 81% | 100% |
Как мы видим, кастомный Decoder медленее примено на 20% из-за обязательной проверки каждого ключа в json на необходимость трансформирования. Однако, это является небольшой платой за отсутствие необходимости явно прописывать ключи для структур данных, реализуя Codable. Количество боилерплейта очень сильно сократилось в проекте с добавлением данного декодера. Стоит ли его использовать, чтобы сохранить время разработчика, но ухудшить проихводительность? Решать вам.
Полный пример кода в библиотеке на github
