Posts for Tag: core data

UK Covid Local Data App

[Edit December 18th: Swift Playground version - Should work on iPad with the latest Swift Playgrounds app: UKCovidData.swiftpm.zip

Note that because of the lag in local level figures by age which the app focuses on it isn't especially useful for tracking the current situation right now because the Omicron growth is so fast that week old data may be four doublings behind - maybe a factor of 16 off. It is still potentially useful for looking at the historic data and will catch up with the picture as Omicron levels off - as it must because the whole population will have had it pretty soon if current growth rates continue.]

[Edit November 10th: App link updated to fix a crash. Source code not currently updated because I can't currently participate in open source. macOS 12 is no longer in beta so it should be available to most people that way.]

A small app providing some data about case rates at the most local level available in England for particular age groups.

This app didn’t really started as planned for release (and it ended up that I couldn’t release on iOS) at least. The intention was partly to play with Swift’s structured concurrency in a real context and partly to get the UK cases data into a form where I could handle it and update it more easily than I was managing with a spreadsheet.

If you want to try the app you either need to have a Mac with macOS Monterey (12.0) which is currently only in Beta release (download app here) or to have Xcode to build and install and install it from source code on your iPhone or iPad (Github project).

Using the App

SwiftUI, Core Data and Combine - Early Days

Update: This was all about Xcode 12 beta 1. There is probably nothing still relevant in beta 5 which includes better built in Core dat support including ways to directly bind on objects and even fetch requests so NSFetchedResultsControllers should become unnecessary. Will try to post again when I have explored further.

This might be a bit of a ramble, it certainly isn’t a carefully designed tutorial but will be a mixture of a few general early thoughts and a few minor gotchas I’ve already hit in my experimentation. I’m still in the stumbling and exploring phase and certainly haven’t mastered SwiftUI or Combine to any great degree yet. This may mean it will be helpful to few people, it is probably too heavy on the jargon if you haven’t already had a good look at SwiftUI and is too light on detail and probably inaccurate if you have gone deeply in. Certainly the shelf life of this post feels short. Feel free to let me know anywhere that I am wrong, or have missed the best documentation or give any feedback either by Twitter or in the comments.

I’m less comfortable with SwiftUI than I was with Swift itself at the similar stage 5 years ago. I believe this is going to be great but there is a mental shift required which I haven’t yet achieved.

I’m in the early stages of rewriting my first ever app (Fast Lists) to create a new version with all the toys from WWDC 2019. Including but not limited to Cloudkit Core Data syncing, SwiftUI interface, support for Mac and Watch (not just iOS as before). Multi window support. I’m also hoping to add some drag and drop support later but I haven’t even started looking at that yet. Because I’m trying everything at once my progress is a bit stop start and random at the moment but it does mean that there is normally another piece to work on if I get stuck.

This is all based on experience with Version 11.0 beta (11M336w) (the first beta) so many of these issues may be resolved very soon. In a few places I note the feedback numbers that I have raised around things that are either bugs or potential areas for improvement.

Core Data seems a conceptual match for SwiftUI

Generating Core Data Swift

The Xcode generated NSManagedObject subclasses are annoying me. While they generate as a pair of files where you can add things to the main class and the @NSManaged variables are generated in an extension in a separate file so that they can be be overwritten and replaced as the model is updated without affecting the file where you make your changes unfortunately there is a big deficiency from my point of view in that the model type information does not get fully carried through to the Swift objects.

Insufficiently Typed

There are two generation options, with "Use scalar properties for primitive data types" you get usefully typed integers, floats, doubles and bools but lose the expression to express optionals/nil values. This is presumably due to the limitations of the Objective-C based API. It also expresses date types as NSTimeIntervals (Doubles) rather than NSDates.  The other option will generate with objects so you will get NSDates but for number values and Booleans you will get NSNumbers which lose information about whether it is a floating point type, integer or boolean.

Other Issues