I'am planning to have a main OSX application, which the user can launch and a background process, which starts on OSX startup and runs prior to the main application
I need a CoreData database, to keep track of some changes... this database should be the same for the background task and foreground app...
What are the options?
Is it possible, that both access the same sqlite (which will be
located in app bundle?)? By setup with the same .sqlite file?
Should they have two identical databases, which they synchronize?
can this synchronisation be automated?
Should there be one database for the background process and the
main application should communicate with the background process?
Using a background process to update the datastore is fighting the frameworks. Also, your background process (and your main process, for that matter) won't be able to update the .sqlite file that lives in your bundle.
Instead of using a background process, use a background queue (via Grand Central Dispatch, and NSManagedObjectContext -performBlock:. Keeping the logic within one application will make your life easier. Your communication happens within the application, instead of having to use XPC.
Don't forget to handle the case of a partial, interrupted, update. The sequence I suggest is:
Application launches.
Background queue launches, pulls updated info from server, creates updated datastore using a temporary name.
If background update succeeds, main queue of application closes the old version of the datastore, then replaces it with the updated datastore. There is API to do this atomically.
Main thread reopens datastore and refreshes UI as needed.
If background update fails, reschedule an update attempt based on failure reasons (bad credentials, server unreachable, partial download, corrupt .sqlite).
If you're absolutely dead set on using two different processes, then you should still assume that the update might fail. So don't write to the live copy until you know you have a complete, valid, replacement.
Apple achieve this in the Notes app using what they call a "cross process change coordinator". This allows the accountsd daemon and the Notes app to access the same CoreData sqlite database. Their class ICNotesCrossProcessChangeCoordinator in the NotesShared framework works by using NSDistributedNotificationCenter to post the notification of changes between the processes and merge them into each others' context. There are many more implementation details of the technique but this should point you in the right direction.
Related
Currently I'm using a viewModelScope to launch a coroutine which in turns retrieves data from a remote server and caches the results in a local ROOM database.
My question is if I should use instead a GlobalScope to launch the coroutine to get such remote data, as the retrieval/caching can be interrupted if the app is sent to the background when using the viewModelScope.
Android discourages to perform continuous running tasks in the background since it uses battery and memory in the main thread. However, if you specifically need code to run in the background, consider using Background Services or Work Manager which is also responsible for starting background tasks.
I was reading about Processes. I wan't to know what really happens. My situation :
"I opened an Application. That creates a process say process1. I have other applications interfaced with this one and all these open up when i click a button inside my running application. I want to know Does my process1 create new processes and IPC happens OR processes for all the linked applications are created at once and then IPC happens?"
Obviously,a running application is a bunch of processes,or maybe a single process which has internally multiple threads acting within these processes.
So,your activity decides the creation and deletion of processes.say,if you are running an application such as media player and you suddenly start searching related info about the album---so here,totally a new process is created which helps interaction through web and after returning the output,it may die,may not,but the process was created on your request.Also,mostly ipc happens within processes,exactly as per your thinking,but shared memory communication is also one of the option,which is complicated and is less common.
One more thing to point out is that there are several 'daemon processes' which are running in the background and don't die before shutdown instruction!So,these processes are also sometimes related to the running application and serves its request.But,mostly,newer processes are created when we switch our task or perform certain action in the application.
I'm syncing a list of table view items via iCloud. When would be best to perform the sync. Here is my understanding of the various options.
didFinishLaunchingWithOptions - this will only get called when the app is launched. As most users send the app to background, rather than quit, it is likely this method won't be called very often.
applicationWillEnterForeground - this will happend every time the app is opened from a background state, if the internet connection is slow, this could cause a pause is the UI displaying?
applicationDidEnterBackground - I believe we only have 5 seconds to perform any actions, so a slow connection might mean we can't sync.
What are your thoughts best time to sync?
Well, besides the fact that a document saves every so odd amount of seconds, the best time to sync with iCloud is very dependent on the circumstance.
For example, if you have created a brand-new object that would be lost if not stored to iCloud, it's probably a good idea to do a sync with iCloud right away.
On the contrary, if you have created a brand-new object that wouldn't be lost if not stored to iCloud due to it being saved within Core Data, then maybe you can combine the save into one elsewhere given that you're concerned about the speed and CPU that the sync will take up.
I use Core Data to maintain a persistent store, and the database can grow quite large. My users with larger databases on iPad 1s don't complete the lightweight migration in time for the process to complete before the app is killed by the iOS for hanging.
What I want to do is every time the server starts up, check to see if the database needs to be migrated (I can't find a method for this on NSPersistentStoreCoordinator), if it does hold the server startup process until the database is upgraded and display a spinner on screen, then move forward with the server startup process once it is. The best way to do this seems to be to add a - (BOOL) upgradeStoreNeedsUpgrade method in the server startup method, but I can't find a way to check. I don't see methods on NSPersistentStoreCoordinator or NSPersistentStore to check the compatibility of a a database at a given URL with a given managed object model.
Is my solution the right way, and if so, how can I check if the managed object model is compatible with the SQLite file at a given URL?
You could try wrapping the core data lightweight migration code in a dispatch block. This should spin it off to a background thread so you can get past the Application Start Watchdog thats probably killing your app. Its either that or you are running the device out of memory.
Is there a way to ensure that only a single instance of the desktop version of a trusted Silverlight 4 Out Of Browser app will run?
Or do I need to manually enforce this through the creation of a crude mutex of some sort?
If I must enforce this myself, I'd look at creating a file in isolated storage as a lock and then deleting it on exit. I'd check this files existence on launch to prevent opening a subsequent instance.
Obviously I'd need a way to handle the app crashing or exiting some other way that prevents the lock file from being deleted. My instinct would be to have a timeout on the file and so ignore it if it's over a certain period of time old. Unfortunately, the app plays movies so it's likely it will run for several hours under normal circumstances. A lock timeout of a few hours isn't likely to be popular with any users in this situation. Are there any better solutions?