For some weird reason when decoding JSON which contains the UUID as String, the resultant UUID property is always coming to be nil.
UPDATE:
struct Movie: Codable {
var id: UUID?
var title: String
var poster: String
UPDATE:
This is unbelievable. Debugger was lying the value was NOT NULL.
Related
import FirebaseFirestoreSwift
import Firebase
// I created this object so that i can map the users data and access it threw this object. example I could say thigs like user.username
// The decodable protocall will read the data dictonary and looks for the exact name for the keys/property names I have listed in the data dictonary, this makes life easier when working with objects and downloading information from an api
struct User: Identifiable, Decodable {
// Im able to delete the uid field out of firebase because this will read the documentID from firebase and store it in this id property, so that I dont have to dupicate that data in the actual body of the object
#DocumentID var id: String?
let username: String
let fullname: String
let profileImageUrl: String
let email: String
let stats: UserStats
// This is a computed property saying if the currently logged in user's id is equal to the id on my object (#DocumentID)
var isCurrentUser: Bool { return Auth.auth().currentUser?.uid == id }
}
struct UserStats: Decodable {
let followers: Int
let following: Int
}
Add ? at the end of each variable.
#FirestoreQuery does little error handling when it comes to decoding.
Also, if you are not using #FirestoreQuery use do try catch instead of try?
Let's say I want to decode a Person struct as follows.
struct Person: Decodable {
let firstName: String
let lastName: String
let age: Int: String
}
I understand that the data can be decoded only with above. Therefore if I'm not changing the properties to a custom name if there no difference between the above and below implementation?
Further is there other cases where you want to use CodingKeys? I'm confused when they are necessary other than for renaming purposes.
struct Person: Decodable {
let firstName: String
let lastName: String
let age: Int: String
}
enum CodingKeys: String, CodingKey {
case firstName
case lastName
case age
}
First of all there is a make-or-break rule for using CodingKeys:
You can omit CodingKeys completely if the JSON – or whatever Codable conforming format – keys match exactly the corresponding properties (like in your example) or the conversion is covered by an appropriate keyDecodingStrategy.
Otherwise you have to specify all CodingKeys you need to be decoded (see also reason #3 below).
There are three major reasons to use CodingKeys:
A Swift variable/property name must not start with a number. If a key does start with a number you have to specify a compatible CodingKey to be able to decode the key at all.
You want to use a different property name.
You want to exclude keys from being decoded for example an id property which is not in the JSON and is initialized with an UUID constant.
And CodingKeys are mandatory if you implement init(from decoder to decode a keyed container.
You can use CodingKeys in different ways for example, when you know that at least one of the name of values that you are expecting in your JSON is actually different from your "let or var" name.
Example:
struct Person: Decodable {
let firstName: String
let lastName: String
let age: Int: String
}
enum CodingKeys: String, CodingKey {
case firstName = "first_name"
case lastName
case age
}
Other case is when you are using class inheritance.
In conclusion, if you are absolutely sure that you are using the same variable name as your encoding key(JSON), you can omit it (but if you want to put it, it doesn't matter), but if there's a difference, maybe a change of your codingKeys like an uppercase or using different words, you should use the enum to map the correct key with the variable name.
CodingKeys can be extremely helpful if you have a JSON with arbitrary number of coding keys (also called dynamic keys). Here is an example.
import UIKit
// Consider JSON with infinite number of keys: "S001", "S002" and so on
let jsonData = """
{
"S001": {
"firstName": "Tony",
"lastName": "Stark"
},
"S002": {
"firstName": "Peter",
"lastName": "Parker"
},
"S003": {
"firstName": "Bruce",
"lastName": "Wayne"
}
}
""".data(using: .utf8)!
struct Student: Decodable {
let firstName: String
let lastName: String
}
struct DecodedArray: Decodable {
var array: [Student]
// Define DynamicCodingKeys type needed for creating
// decoding container from JSONDecoder
private struct DynamicCodingKeys: CodingKey {
// Use for string-keyed dictionary
var stringValue: String
init?(stringValue: String) {
self.stringValue = stringValue
}
// Use for integer-keyed dictionary
var intValue: Int?
init?(intValue: Int) {
// We are not using this, thus just return nil
return nil
}
}
init(from decoder: Decoder) throws {
// 1
// Create a decoding container using DynamicCodingKeys
// The container will contain all the JSON first level key
let container = try decoder.container(keyedBy: DynamicCodingKeys.self)
var tempArray = [Student]()
// 2
// Loop through each key (student ID) in container
for key in container.allKeys {
// Decode Student using key & keep decoded Student object in tempArray
let decodedObject = try container.decode(Student.self, forKey: DynamicCodingKeys(stringValue: key.stringValue)!)
tempArray.append(decodedObject)
}
// 3
// Finish decoding all Student objects. Thus assign tempArray to array.
array = tempArray
}
}
let decodedResult = try! JSONDecoder().decode(DecodedArray.self, from: jsonData)
Therefore if I'm not changing the properties to a custom name if there no difference between the above and below implementation?
Yes, but there's a bit of misunderstanding here. The two implementations you have are literally identical because in the second one the CodingKeys enum would never be used. To be used, the enum must be nested within the Decodable conforming type (Person in this case):
struct Person: Decodable {
let firstName: String
let lastName: String
let age: Int
enum CodingKeys: String, CodingKey {
case firstName
case lastName
case age
}
}
There is in practice no difference between this implementation and the ones you provided.
Further is there other cases where you want to use CodingKeys?
CodingKeys are not used solely by Decodable, they are also used by Encodable. When using Encodable, a reason to use CodingKeys is to specify only a subset of the instances fields should be serialized.
I am trying to follow the Model View ViewModel format for SwiftUI, but am running into an issue with UUID. I have an object of type TimeCode that has an attribute id of type UUID (TimeCode is created in xcdatamodels as a CoreData model). In order to create a TimeCodeViewModel object, I need to assign the id attribute in TimeCodeViewModel with the same UUID from the original TimeCode object. I therefore created this class definition to do so:
class TimeCodeViewModel: Identifiable {
var id: UUID
var fullName = ""
init(timeCode: TimeCode) {
self.id = timeCode.id
self.fullName = timeCode.fullName
}
// class methods
}
However, I get a compile time error saying that UUID is a get-only property. This makes sense, since you shouldn't be able to reassign the unique ID of an object to a different object, but in this case I am actually trying to describe the same object. Is it possible to assign self.id with the same UUID?
I guess another approach could be to make the UUID a string and then assign it to the view model, but is it then possible to convert the string back into a UUID? For example, I want to fetch the original TimeCode from CoreData using the UUID from the TimeCodeViewModel so I can save edits to other attributes of the TimeCode.
It would be interesting to see how the TimeCode Class looks like. I don't think that the id is set correctly. If you want a unique identifier as a String add the following to generate one:
var id: String = UUID().uuidString
You can share the string and therefore reference to the same object.
EDIT:
Regarding the new information, changing the class to the following might be an idea:
class TimeCodeViewModel: Identifiable {
var id: UUID {
return timeCode.id
}
var fullName = ""
private var timeCode: TimeCode
init(timeCode: TimeCode) {
self.timeCode = timeCode
self.fullName = timeCode.fullName
}
// class methods
}
I have the following struct
struct Vehicle: Codable, Identifiable {
#DocumentID var id: String?
var name: String
}
As long as I use the default Swift decoder I can load Firestore entries without any issue (using document.data(as: ), and id contains the document ID.
However I now need a custom decode function inside that struct, and that's where things go wrong.
I can load all fields without any issue, but the document ID is not filled out.
I tried like this:
init(from decoder: Decoder) throws {
let container = try decoder.container(keyedBy: CodingKeys.self)
if let id = try container.decodeIfPresent(DocumentID<String>.self, forKey: .id) {
self.id = id.wrappedValue
}
But it gives me nil.
I found some other answers but they talk about DocumentReference which is a type that doesn't (or no longer?) exist.
How can I solve this?
Thanks
Decode the Document ID using:
_id = try container.decode(DocumentID<String>.self, forKey: .id)
for the corresponding variable:
#DocumentID var id: String?
This will place the document ID into the ID variable (note the required "_" before id).
To clarify, a DocumentReference is an object that holds the path to a firestore document and is the object you would call your platforms equivalent of .get() to retrieve data through a DocumentSnapshot.
I am not terribly familiar with swift, but when decoding the object, you should be able to reference the ID as needed from the documentID property rather than the .data() method
Source: iOS Document Snapshot ID
I have a Realm model class that I need to be Decodable so I can serialize it from JSON and save it to database. Every PortfolioItem is associated with one Product and at some point I need to get to PortfolioItem from Product via inverse relationship. That's why I have LinkingObjects property. The problem is when I try to conform to Decodable protocol. The compiler is giving me an error Cannot automatically synthesize 'Decodable' because 'LinkingObjects<PortfolioItem>' does not conform to 'Decodable' . How to deal with this? I found very little about LinkingObjects and Decodable online and I have no idea how to approach this.
class PortfolioItem: Object {
#objc dynamic var id: String = ""
#objc dynamic var productId: String = ""
#objc dynamic public var product: Product?
convenience init(id: String, productId: String) {
self.init()
self.id = id
}
}
final class Product: Object, Decodable {
#objc dynamic var id: String = ""
#objc dynamic var name: String = ""
private let portfolioItems = LinkingObjects(fromType: PortfolioItem.self, property: "product")
public var portfolioItem: PortfolioItem? {
return portfolioItems.first
}
convenience init(id: String, name: String) {
self.init()
self.id = id
}
}
Big thanks to Chris Shaw for helping me figure this out. I wrote a more in-depth article how to setup Decodable and LinkingObjects, look HERE.
Well unless I'm missing something then the LinkingObjects properties does not need to be included in the decoding.
My assumption here is that you're receiving JSON from some online source, where the JSON for a Product consists of { id: "", name: "" }. As long as you're creating the PortfolioItem correctly with associated Product, then the resulting LinkingObjects property is the result of a dynamic query within Realm (and will thus work without any JSON source).
I'm not in a position to test compile an answer today, but you should be able to use CodingKeys to simply exclude that property, i.e. by adding this to Product:-
private enum CodingKeys: String, CodingKey {
case id
case name
}
Also, unrelated, but note that your convenience init function are not initialising all properties that you're passing in.