The best opportunity for this was to work on the migration of ScreenFloat 1’s dual-plist-file-based library.
#SCREENFLOAT CODE#
I figured, the best way to get Core Data set up, working, and to see if my implementation works correctly, is to code it on-the-fly, adapting and changing it as needed. Migrating ScreenFloat v1’s database to v2 Now I have a background queue context – used only for saving to disk -, on top of that the main queue context – used for updating the UI -, on top of that another background queue context – used for actually retrieving and editing stuff -, and on top of that an optional background queue context for work I might want not to persist/save, so it’s easy to discard. It was nice dreaming and wondering about this, but in the end, the more traditional approach to Core Data is still the best in my case. But I want to have the same way of handling Core Data on all platforms ScreenFloat will support (I don’t want to have to do basically the same work twice), so it’s another no-go. IOS does not offer XPC services to 3rd party developers. That would mean to have to have this XPC service available to it as well, which in turn would mean having the XPC service inside the app twice – unnecessary bloat. ScreenFloat 2 will not only consist of the main app, but also a Share extension, at least.
#SCREENFLOAT UPDATE#
Anytime I wish to update a property, I would not only have to update the Core Data model and its entities, but also these custom “translator” classes.Īnd what about relationships in the Core Data model? Those would be a pain to handle this way. That would result in more work and maintenance. To communicate with the XPC service, I’d have to create what I call “translator” classes that I send back and forth from and to the XPC service – classes that ScreenFloat understands (because it wouldn’t know about Core Data entities/objects), and the XPC service understands (so it can “translate” changes back to the Core Data store). Sounds too good to be true? That’s because it is. The XPC service is its own process, so doing things there on the main queue context wouldn’t block the UI of ScreenFloat at all. What if the ScreenFloat app wasn’t aware about its Core Data nature at all? I could do all the Core Data stuff in a separate XPC service, and ScreenFloat would communicate with it to retrieve and update objects. Ian Malcolm: “No, you’re… making all new ones.” Jurassic Park 2: The Lost World John Hammond: “I’m not making the same mistakes again!” So when I began working on migrating to Core Data, I thought, what if I could have the best of both worlds, with only one main queue context? Wouldn’t that solve all my potential problems? It has to be – for the lack of a better word – “converted” to a main queue object so that it can be used there. This can make things tricky, because an object obtained on a background context should not and can not be used on the main queue to update the UI (and vice-versa). It’s been more or less established that, at the very least, you should have two managed object contexts when working with Core Data: One on the main queue for UI work, and another one on a background queue, for fetching and other “work”, so it doesn’t block the UI of the app. This week, I’ve been busy with getting ScreenFloat 2’s migration to Core Data going and working, the first task being to decide on how I want to handle Core Data in the first place. I thought it would be fun to chronicle my progress, struggles, successes, failures, struggles, failures, break-throughs, failures, and random stuff while developing ScreenFloat 2.
#SCREENFLOAT UPGRADE#
But I am resolved on its upgrade path: existing customers of ScreenFloat 1 will receive ScreenFloat 2 for free. Regarding pricing, I don’t know what ScreenFloat 2 will cost yet. And while that may be a serious lack of managerial skill: I accept that flaw and ignore it 🤷♂️. I’m a solo developer, I have multiple apps that need maintenance and updates, there are just too many moving parts for me to be able to estimate basically anything. Disclaimer: Estimated Time of Arrival, Pricing
#SCREENFLOAT WINDOWS#
ScreenFloat lets you keep visual references to anything you see on your screen floating above other windows using screenshots. Me, in an attempt to begin this entry with something witty Core Data is like conversation: Take things out of context, and eventually, it will all come crashing down on you.
0 kommentar(er)
