The short answer is no. The long answer is that you should only use a unique object to cache database hits but keep the data you want to keep track of actively in a structure or named tuple. It would make much more sense to have a structure like so
struct DayState {
typealias Task = (Name:String, Complete:Bool)
// Tasks and its derivatives could be unordered as it wouldn’t be significant
var Tasks: [Task] = []
var CompletedTasks: [Task] {
Tasks.filter{ $0.Complete }
}
var UncompletedTasks: [Task] {
Tasks.filter{ !$0.Complete }
}
var sparkleSeen: Bool
// More Clear variant of startedAt
var startTime: Date
// More Clear variant of percentage with a error safe read only value
var completionPercent: Double {
get {
guard Tasks.count != 0 else { return <#0.0#> }
return (CompletedTasks.count / Tasks.count) * 100.0
}
}
}
struct DayCache {
// Left for modification Purposes
// You should drop this typealias after you make your choice
typealias QuoteType = Int?
var Quote:QuoteType
// 86400.0 is an approximate of the seconds in a day
var Validity:DateInterval
var valid:Bool { Validity.contains( .now ) }
public init() {
self.Invalidate()
self.update(force : true)
}
func Revalidate() {
self.Validity = (start: .now, 86400.0)
}
func Invalidate() {
self.Validity = (start: .now, 0.0)
}
async func update(<#Your Attributes#>, force:Bool = false) {
guard force || !valid else { return }
guard <#online#> else { return }
<#Your Network Calls#>
Revalidate()
}
}
Note:
You should implementCodable
if you want to have a “Streak Calendar” or history so that you can get your values back later.
If you implementCodable
any procedural values aren’t stored.Codable
usesJSON
to store its data meaning that compression of user data shouldn’t be too difficult.
Objects that are specific to contexts should not persist outside of their context and deinitalization to decrease memory usage and to minimize the complexity of systems that use/manage these resources. If you need to keep an object for record keeping you should try and minimize the state required to hold the record by doing things like removing caches, deleting recoverable data, etc.
You should never precalculate multiple distinct objects for events in the significant future(excluding downloads) as it causes higher overhead in processing and memory but if you need to, use lighter weight structures. Practice Separation of concerns; if the app needs to review previous Quotes while offline you may want to store these however, it is memory cheap to simply make a GET
request to get a day’s quote; can your values be considered decoupled from each other but be complementary to each other, decoupling them also means that you can store less data about each day on device.