I have an iOS app that implements a custom subclass of UIDocument that encapsulates a file wrapper on a package of data, archived objects and images. I initially converted the implementation to UIDocument for iCloud support but it has been too unreliable and so I am pulling out the iCloud portion and just using a UIDocument with local storage.
When the user modifies the data I send updateChangeCount: to the UIDocument instance and it periodically autosaves in the background. I only close the document when the application goes to the background. I've discovered that after an autosave which calls my contentsForType method of UIDocument a loadFromContents is also called. I don't understand this logically and it is also causing problems with my interface.
I thought loadFromContents would only be called when opening the document or if an iCloud document was modified on another device. So when my document autosaves in the background it also re-loads which causes an update of the UI which can sometimes discard new work in progress that hasn't been saved. I could ignore the re-loading in the UI but I'd still have some problems with my model data being different than the UI objects.
So what am I doing wrong to cause this behavior? I would like to have a save not initiate a loadFromContents or understand how to handle that behavior.
Thanks!
I discovered that this behavior was somehow due to some #synchronized calls I had wrapped contentsForType and the writeContents: methods with on initial implementation to prevent crashes when closing the document with unsaved changes. I was getting two near simultaneous calls to contentsForType that caused bad access errors.
I found a cleaner way to prevent these crashes by setting updateChangeCount:UIDocumentChangeCleared before closing the document.
Related
From what I understand, the UIDocument class can track unsaved changes to a file and even locks the file so it cannot be checked out by more than one person. But what happens if the user force quits the app without saving or the app crashes? How would I go about recovering the unsaved changes to a UIDocument so that when the app re-launches it reopens the UIDocument with the most recent unsaved changes? Do I need to make duplicate copies of each file before it is changed and alter the temporary duplicate until the user saves the changes? Or does Apple provide a simpler implementation? I have also considered encoding and storing the Data file contents and the undoManager of each UIDocument instance periodically as a cache. Would that work?
The UIDocument and UIManagedDocument do automagic change tracking (calling a function where you can return true if the document has changed) and saving the changes to disk by respecting other system constraints (for example: if another process is trying to read the file).
The way Apple does saving is in a very safe way, if you don't override the base class methods. When the save operation is triggered, Apple saves to a temp file and if the save is successfully a quick rename and delete of the original file is done (IIRC the rename/delete is atomic, or near atomic). You can assume that the save operation doesn't leave a corrupt file in the file system for 99.99% of all cases.
Apple triggers save operations in the background at specific points (like: time based, app switched to background, before other process tries to accesses the file, ...), but I couldn't find any clear statement what happens when the application is force quit.
That said, logic and common sense tells me, that if you force quit an application, the current document state can't be saved. Even implementing a "quick save" manually for a force-quit may not be technically feasible. A periodic background save operation (like UIDocument already does) may be the best strategy.
About saving the state of the undo manager: This would be the same technical problem as with saving the UIDocument. There is no event or anything else that tells the application it's about to be force-quit.
You should read the Apple Documentation. It's very long but it explains the process in more detail. My advice to you would be, to implement the strategy that Apple imposes. These strategies are sound, and work for many, many applications in the Apple ecosystem and for their users. On top of that, you have a reduced implementation cost and automagic improvements (when Apple updates their implementation).
We are building a React-Native iOS app that needs to access our realms natively as well as via RN.
We have writing working correctly from our UI and can load the data in our background Swift service, but after the write, The changes_available method in js_realm.cpp is firing which contains assert(0) which is causing the app to crash/hang in debug. What do we need to be doing to prevent that method from firing?
Update: A release was just made (0.11.1) which should prevent this crash from occurring. Note that notifications across bindings have not yet been tested and may not work.
This method gets called when changes are made externally to a Realm from another process or thread. In your case it sounds like writes made from the swift apis are causing this method to get called. The ReactNative binding was written with the assumption that everything would be done from a single thread without considering the use of other language bindings being used simultaneously.
As is the only thing you can to do prevent this is to not make a write in Swift while a Realm is open in JS. One way to do this would be to call Realm.close after every use, although this may perform poorly.
In the near term we can also do a point release to remove the assert(0) - this will prevent the crash/hang, but notifications for changes made in Swift wont work without additional changes. Can't give an estimate of when we can get cross language notifications working properly.
Recently, I'm working with a timetable app in iOS, and i get trouble with Core Data.
My app has a main user interface kind of like the original calendar app created by Apple, and i save all my events data in the Core Data database.
I create a UIManagedDocument in order to fetch data from database by using its NSManagedObjectContext, and everything works just fine.
However, i need to use the NSManagedObjectContext to fetch data several times in several different view controllers during the runtime. And every time i do this, i need to reopen the UIManagedDocument, but open the document take too much time(it may take 2 seconds or even more, i have to display a spinner in view).
So here are my questions:
What's the right way to open a managedDocument?(I mean like open it during the lunch image time?)
Is there a way to only open the managedDocument once and keep it open during runtime?(So i can use its context all the time)
Does data store in the managedDocument i create?(I found that if i delete the document, data was gone)
Thanks.
You will get lots of different opinions on how to do this but basically you should only have to open the document once. This is done by some object that does the work and stores it so it can return it again when asked by a different view controller.
Many people create singleton's for this or put it in the App Delegate. I have implemented a protocol that lets me put it where ever it is convenient for a particular application without my other code having to know anything about the object that returns the information. As long as it responds to the protocol it can be the App Delegate, a singleton class, or any other object type.
See importing AppDelegate
The protocol that I put in the above example just returns information about where the database is. In my actual implementation I have an openDatabase method with a call back to let me know when it is done plus automatic initialization and updating methods.
You can also improve your performance by having the open operation happen off the main thread. This keeps your UI responsive but does not show the data any faster and you have to be carefull about managed object contexts and the threads they are in.
Good luck...
I'd like to use NSUndoManager in an iPhone application on CoreData (NSManagedObject) objects such that I can save (and later restore) the state of the NSUndoManager if the application exits prematurely (say, due to a phone call coming in). I.e. as opposed to automatically discarding or saving the changes accumulated in the NSUndoManager, I would like to restore them so that the user has the option to explicitly discard or save them when they restart the app.
Has anyone had any experience with this? Can anyone recommend this (or an alternative) approach to managing pending changes in a NSManagedObjectContext when the application is interrupted?
The NSUndoManager does not actually store state, it stores a stack of actions that will restore the state. For example, if you have an object XXX and it has a property name which is a string and you change that name from "Steve" to "Joe", what the NSUndoManager stores is a target, selector and object. The target would be the instance of XXX, the selector would be #selector(setName:) and the object would be #"Steve".
By storing that information, if the undo stack is popped it will call -setName: on the instance of object XXX with the value of #"Steve" and thus restoring its state. There is some additional work done around KVO, etc. but that is the basics.
At first I theorized that you could write out the NSManagedObjectID, the selector (using NSStringFromSelector) and the object to disk and restore them by calling -registerUndoWithTarget: selector: object:. However upon further review of the documentation, there is no way to access the stack to be able to iterate over it.
Note that one possible work-around exists by using separate NSManagedObjectContexts such that some are saved on shutdown whereas others have their changes rolled back. It's not perfect, but I found a suitable solution to my problem with this alternative.
I have an application that allows you to edit some percentages, however it will only let you commit those changes if the percentages add up to 100. However because the Core Data template includes the save code in the application will terminate. If the user changed something and then exited the application, the item would be of course saved even though it did not add to a 100%.
Therefore I simply decided to comment out the save in the application will terminate. I know the other option would be to use another context for the edit and then merge the changes or setting my context values until the actual save point. However I do not see any harm in commenting out this line, since I save whatever I want in my application when the user clicks the save button, so my question is: is the save on the application will terminate mandatory? what possible consequences could this have?. It is important to note that the application continues to work just fine after commenting this lines (which is what I expected).
Thank you in advance.
-Oscar
You can save whenever you like.
However, you will never know when the app will terminate. Unlike applications on more conventional platforms e.g desktops, the iPhoneOS will terminate your app (from the apps perspective) at random. The only warning you will get will be the applicationWillTerminate message sent to the app delegate. If you don't handle saves there then it is highly likely that at some point, your users will lose data.
I think you should reconsider your design. It sounds like you're putting calculation into the managedobjects that could (1) be handled elsewhere in code or (2) be handled by transient properties. You shouldn't have a condition in which the managedobject can't be saved at the drop of hat. Doing so makes your datamodel utterly dependent on external code for its internal integrity. This causes problem with maintenance, portability and upgrading.
Its not mandatory to save on application will terminate. You can save when ever you feel appropriate for the context of the app.