App fetches products from the server, then writes them into the phone's database (CoreData, a wrapper around Sqlite) and then refreshes the TableUI, which pulls the data from the database.
Currently it keeps writing more products to the db upon every load, so now there's too many (duplicates). But the Next Steps defined here will fix that. I want to merge this as a lot of the work was very delicate.
The major updates were to EmpowerPlantViewController.swift
Upgraded SDK to 7.11.0 as well
Decision
Do not Decode the http response directly into the Product Entity class - because this bloated the model classes with a lot of boilerplate code, which we couldn't get to work (though we did learn afterwards that the only remaining step was probably to manually map each product key:value in the Product.swift class, but still involved a ton of boilerplate, and I was advised that tweaking any of this the future could become more cumbersome.) so sticking with the ProductMap intermediary, which uses the Decodable interface.
Next
/* TODO
1 get products from server (so we get http.client span)
2 check if any products in Core Data -> If Not -> insert the products from response into Core Data
3 get products from DB (so we get db.query span) and reload the Table with this data
*/
and I think remove /Pods for source control.
Testing
transaction link transaction for EmpowerPlantViewController shows spans for http.client and db.query
Overview
App fetches products from the server, then writes them into the phone's database (CoreData, a wrapper around Sqlite) and then refreshes the TableUI, which pulls the data from the database.
Currently it keeps writing more products to the db upon every load, so now there's too many (duplicates). But the Next Steps defined here will fix that. I want to merge this as a lot of the work was very delicate.
The major updates were to
EmpowerPlantViewController.swiftUpgraded SDK to
7.11.0as wellDecision
Do not Decode the http response directly into the Product Entity class - because this bloated the model classes with a lot of boilerplate code, which we couldn't get to work (though we did learn afterwards that the only remaining step was probably to manually map each product key:value in the Product.swift class, but still involved a ton of boilerplate, and I was advised that tweaking any of this the future could become more cumbersome.) so sticking with the
ProductMapintermediary, which uses the Decodable interface.Next
and I think remove /Pods for source control.
Testing
transaction link transaction for EmpowerPlantViewController shows spans for http.client and db.query
transaction link List App still loads fine
ignore the 'SDFSDF' that was from an initial experiment to test DB writes. I'll delete it and duplicate products.