I’ve spend the last few weeks working on schema and core data. I’m ready to start working on some more advanced user interfaces. Before I begin I wanted to share some images of what the app looks like as of Oct. 14, 2019. Timelines will likely change very little, but I have a lot of work to do on the Events layouts.
I based most of my core data code for Retrospective Timelines on an example project that you can check out here. The developer sent me the link to this in a comment on stack overflow a couple of months ago. Throughout the project I’ve made small changes to this to better suite my needs.
Today I made a huge set of changes. I wanted a way to build UI controls that can modify the sort descriptors and predicates that the fetch requests used to drive the FRC. In the sample project this is done by passing in some optional strings, then parsing them into the objects they need to be in the a function that prepares the fetch request. This approach did not scale for what I need, as some of the layouts need complex sorting and/or predicates. I made a new version of this that replaces the optional string properties with some alternatives.
First the sort descriptors. Core Data has a way to apply multiple sort descriptors by passing them as an array. Even if I only have one sort order (rare for this project) I can just pass a single descriptor in the array
private var sortDescriptors: [NSSortDescriptor]?The predicates were a bit different. Core data accepts one predicate for a fetch request, not multiple… kinda. Predicates can be combined using compounds. I can make compound predicates on each layout as needed.
private var predicate: NSPredicate?Then I needed a way to add these to the fetched request.
private func configureFetchRequest() -> NSFetchRequest<T> {
let fetchRequest: NSFetchRequest<T> = T.fetchRequest() as! NSFetchRequest<T>
fetchRequest.fetchBatchSize = 0
if let sortDescriptors = self.sortDescriptors {
fetchRequest.sortDescriptors = sortDescriptors
}
if let predicate = self.predicate {
fetchRequest.predicate = predicate
}
return fetchRequest
}I need a way to call this publicly as well. This calls the private method after checking the optionals. If I no longer have a descriptor or predicate, I set the property back to nil so it’s no longer used in configureFetchRequest
public func loadDataSource(sort: [NSSortDescriptor]?, predicate: NSPredicate?) -> [T] {
if let sort = sort {
self.sortDescriptors = sort
} else {
self.sortDescriptors = nil
}
if let predicate = predicate {
self.predicate = predicate
} else {
self.predicate = nil
}
self.fetchRequest = configureFetchRequest()
self.frc = configureFetchedResultsController()
return self.allInOrder
}Now for the cool part. I can make a View Model for each layout where I can place some properties to drive controls in the user interface. This View Model will also handle building the sort descriptors and predicates for the layout. They can then be used as a parameter when I call loadDataSource.
Here is a basic example of the View Model that drives the list of event dates. The sortToggle variable is bound to a UI toggle so when the user taps it the sort order changes. I’ll replace this with a better sort button, but the underlying concept will remain the same.
class EventListVM: ObservableObject {
@Published var sortToggle = false
public func getSort() -> [NSSortDescriptor] {
return [NSSortDescriptor(key: "isOngoing", ascending: sortToggle), NSSortDescriptor(key: "date", ascending: sortToggle)]
}
public func getPredicate(timeline: Timeline?) -> NSPredicate? {
if let timeline = timeline {
let startString = String(format: "%@%@", "dateStartEvent.eventTimeline", " == %@")
let startPredicate = NSPredicate(format: startString, timeline)
let endString = String(format: "%@%@", "dateEndEvent.eventTimeline", " == %@")
let endPredicate = NSPredicate(format: endString, timeline)
let compoundPredicate = NSCompoundPredicate(orPredicateWithSubpredicates: [startPredicate, endPredicate])
return compoundPredicate
}
return nil
}
}The only thing that is a little nuts is the way I get the records to use in the ForEach view. This calls a method on one ObservedObject while using return values from two functions on another ObservedObject. I feel like I’m getting away with something here.
@ObservedObject var dataSource = RADDataSource<RTDate>()
@ObservedObject var eventListVM = EventListVM()
...
ForEach(dataSource.loadDataSource(sort: self.eventListVM.getSort(), predicate: self.eventListVM.getPredicate(timeline: self.timeline))) { rtDate in
...
}This is just a simple example, but now that I have the foundation in place I can extend this to work on much more complex user interfaces.
Yesterday I mentioned an issue I can across when sorting date records. Some of my date records could validly have a nil value in the date field (these are the “end” records for ongoing events). The problem was that Core Data was sorting these nil records to the wrong part of the list. When sorting descending, they should be at the top of the list, but they were at the bottom.
There are a ton of ways to tackle a problem like this: custom sort descriptor, sort by a derived value, omit the nil values, fetch the nil records in a different section, etc. I didn’t do any of these.
Instead I cheated. I added a new Boolean field called isOngoing and set it to false for all new records. When a user marks a record as “Ongoing” I toggle this to true. Then I modified my sorting to sort by this field, then the date field. This has an added bonus of letting me easily group these two types (true and false) into discrete sections in list view. I may even add a control to let the user hide the ongoing records and all I have to do is hide the section or drop in a predicate to filter out the true values.
This is a lazy way of solving this, but I’m happy with the results.
I wrote about a sorting issue in Retrospective Timeline a while back. You can read the full post here. At the time I decided to go with Solution A, which involved wrapping my core data objects in a container using map and filter calls. That approach worked at first, but there were some issues when it came to refreshing the SwiftUI views. Basically, since I was moving the data outside of the fetched results controller, the views could no longer receive publisher updates when data was changed. I could work around this but it felt like reinventing the wheel.
Last week I decided to modify the schema instead. I started with this
I added a new table called RTDate and moved the Event date fields here. The entities I have now are
As for the relationship from Event to RTDate, I decided to go with two “To One” relationships rather than a “To Many”. As a database developer this isn’t what I would normally do, but it is important to keep in mind that I really just wanted to relocate some properties in a new table that can drive the UI.
I finished up the schema changes yesterday, ripping out the old version as I went. Both Core Data and CloudKit now have the new schema. I considering doing some sort of migration but decided against it since I’m the only user for now. It’s easier to just re-add my data when I’m ready.
This week I’m going to focus on adapting my views for this new schema. Most of what I have now will be easy to modify, but the list of events (now list of dates) will take some extra work. There are four types of date rows that can show up in this list view.
The “Ongoing” row type will take some extra work. This is a valid RTDate record, but the date property is set to nil because no date is selected. I need to substitute the current date for these records. I think I can use Core Data Derived Attributes for this, but I’m having trouble learning how to use that feature.
A short outtake from episode 14 of Project Update. Listen to the full episode here.
One of the hardest parts of any project seems to be naming things. In Retrospective Timelines this problem surfaces when trying to communicate the purpose of event fields.
An event record consists just a handful of fields
This all seems straightforward to me, but I’m the one who made it so… It seems a bit inelegant.
Then there are the names of the entities themselves.
Naming things is HARD.
This morning I made some change to the way that I get events data from Core Data. I outlined my thinking behind this yesterday. Today I put it into practice in the app.
There are two types of events in Retrospective Timeline
I wanted a way to explode the second type of event into multiple list rows. I added some code at the View Model layer that does the heavy lifting here. The result is three event row types.
For the time being I just updated my list view to show some symbols and label strings depending on the event row type. I’m not happy with the half circle symbols. I wonder how else I could represent this data…
Something I’d like to add is a toggle to show and hide the end date rows. When those rows are hidden the list would just turn into a list of events sorted based on start date.
This is a short follow up article regarding the problems I described in this post.
I spent some time mocking this up in a Swift Playground on my iPad. First I added a new container object called EventContainer. This is an object that I can map my events to, while keeping a reference to the Core Data Event record.
class EventContainer {
enum EventType {
case startEvent
case endEvent
}
var date: Date
var eventType: EventType
var event: Event
init(date: Date, eventType: EventType, event: Event) {
self.date = date
self.eventType = eventType
self.event = event
}
}
I started by mapping the entire list of fetched events to an array of EventContainer
let startDateRows: [EventContainer] = fetchResults.compactMap ( { EventContainer(date: $0.dateStart!, eventType: .startEvent, event: $0 )} )Next I filtered the fetched events to just those with end date data
let endDataData = fetchResults.filter({$0.includeEndDate == true && $0.dateEnd != nil})
let endDateRows: [EventContainer] = endDataData.compactMap( { EventContainer(date: $0.dateEnd!, eventType: .endEvent, event: $0 ) } )Lastly I combined these arrays into one new array and sorted it based on the date property from the EventContainer
let fullList = startDateRows + endDateRows
fullList.sorted(by: {
$0.date.compare($1.date) == .orderedDescending
})Now I have a sorted array of EventContainers that I can use to build my list UI. Each list row can still access the Core Data Event entity to pass on to editing views. I think this is a reasonable approach, but I’m really just guessing. If you know a better way to do this please get in touch using the contact form or contact me on Twitter.
I need a way to sort events in a list view that makes them easy to find.
I’d like to proceed with option three from the list above. Using this approach will place an event in the list twice if it has a start and end date. I can format the rows in the list with some indication of type such as single date, start date range, end date range. I can find some symbols to indicate what type the are. I could also place a toggle switch on the list layout to quickly show and hide the end date rows. I might even be able to make a cool animation for this.
I’m running into problems with how to actually pull this off. I wrote a simplified version of this in a playground but I can’t figure out how to sort the final resulting array, as the elements in the array have different sorting rules depending on rather they are a starting or ending record.
var fetchResults = [Event] // this is populated with an array of events
var endDateRows = fetchResults.filter({$0.includeEndDate == true && $0.dateEnd != nil})
var rows = fetchResults + endDateRows // combine the original array with the new array
// Now what do I sort by???I’m considering some possible solutions but I’m not sure if these are a good way to proceed.
Make a View Model that can fetch all of the events from Core Data, then process them into a new array of a different type. I could make a new containing object like this.
class EventContainer {
var dateToSort: Date
var eventRecord: Event // a reference to the Core Data record
}My View Model could make two arrays of EventContainer, using map and filter calls to write the start and end dates to the dateToSort field, and writing the entire event to the eventRecord field. Then it could combine these two arrays into one and sort by the dateToSort field.
This approach seems reasonable but it puts a lot of processing into the hands of the View Model. Every time I navigate to a list I’ll have to run these processes. For individual Timelines that may not be a problem but when it comes to making list views that show events from all Timelines this could run into performance issues.
Modify the schema. Currently I have a simple Event entity in Core Data. In simplified form it looks like this.
class Event {
var name: String
var dateStart: Date
var includeDateEnd: Bool = false
var dateEnd: Date?
}I could modify this by moving the date fields into a new table and making one to one relationships.
class Event {
var name: String
var dateStart: EventDate // Core Data To One relationship
var includeDateEnd: Bool = false
var dateEnd: EventDate //Core Data To One relationship
}
class EventDate {
var date: Date
}If I set this up correctly I could modify my fetch requests to record a list of EventDate records, then use the relationships to access the rest of the event data. This option would probably perform far better. It’s also a ton of work to update the app as it stands now. This might also complicate some of the calculations involving dates because the will be several database records involved instead of one Event record.
Out of these two options I’m leaning towards the first. This is not really an approach I’ve taken before and I think it could be valuable to try it. Coming from 8 years of FileMaker development, my first thought is to try to solve this like a database normalization problem, but I’ve learned the hard way before that Core Data is not a database. Sure, it uses a data and fills the same role as a database, but it’s an Object Modeling tool. It may be good to force myself to use a new type of thinking to solve this problem. If I run into performance issues then I can also take another crack at the second option. Either way, I need to spend some time thinking about this more before I decide how to proceed. Perhaps this is a good topics for Project Update.
The app I’ve been working on over the last few months is called Retrospective Timelines. I’m still trying to learn how to talk (and write) about the app in a way that makes sense and appeals to customers, but for now I’ll just write a bit about what it is and what it does. This will be a rambling post…
Retrospective Timelines is an app can track lists (Timelines) of personal milestones and important events. The main purpose of the app is to put these milestones and events into context. How long has it been since X Event? How long was I working on Project Y? What was happening in my life when I worked at Company Z?
An event can be a single point in time or a date range with a start date and end date. For example:
I’ve been tracking this data for years in various spreadsheets and apps. I’ve never found one app that can hold all of it in a way that makes sense to me. Some examples of the type of data I want to track
I’m still working on some views that will visualize this data. I’m going to start by making a graphical view for single timelines, but down the road I want to introduce the ability to combine timelines to cross reference data.
I’m using Core Data and CloudKit to build the backend of the app. It’s important to me that this data syncs to all of my iOS devices. The schema is simple, at least for now.
I started this project in UIKit and got pretty far before I decided to switch to SwiftUI instead. While SwiftUI is still new and buggy, there are just some things in UIKit that drive me nuts. I hope I never have to work with auto layout again.
For now the app is mostly using stock iOS controls with some styling added. I have a lot of work to do on each of the screens below, but this should give you an idea of what the app looks like for now.
The top of the navigation stack starts with Timeline List View. You can add, edit, reorder, and delete timelines. The four rows in the first section don’t do anything yet.
I’m not really happy with the way that Events look right now, but I have data entry screens ready and working.
I’d like to replace this view with something more graphic. Perhaps some sort of card generated using the Timeline icon and color. The app calculates the time since a date in a readable format. For events with a date range it also calculates the curation of the range. Below you can see that I owned a MacBook Pro with an awful keyboard for 1 year, 10 months, and 7 days.
