I created a small test Mac app using the Core Data template (on Lion 10.7 and Xcode 4). I used the example on this site, http://www.swampfoetus.net/chapter-7-fail/, to hook up all the Cocoa Bindings with a tableview, an NSArrayController, a text box and an Add button. The NSArrayController is linked to the managedObjectContext of the App Delegate.
Everything seems to work fine when I launch the app ... I can type in text and press Add, and it gets saved in the tableview. I saved a few rows, and then pressed Save in the file menu (linked to the saveAction IBAction) and quit the app. I can see the data being saved in the xml data file (I renamed it .xml ... the PSC is of type NSXMLStoreType).
The problem is that when I launch the app again, it launches without the data that was saved in the Core Data file in the previous run.
This happens each time ... I can add data and it keeps appending to the data file, but at launch it never seems to read from this data file.
Any ideas what could be wrong here? I haven't messed around with the App Delegate generated code at all, only set up the bindings which seem to work fine. What could I check to make sure it's setup correctly?
If the data shows up in the persistent store, then the only explanation would be a problem with the binding where the UI doesn't display the previous data for some reason. It's hard to say why that is happening but my guess would be a fetch predicate or some other bound qualifier that causes the controller to ignore older objects so that they are not displayed.
I can't say for sure because I don't have access to the book.
This is one of the drawbacks of using bindings. When they work, they're fantastic but when they don't, they're a ##%! to debug.
Related
First of all, I'm not using Core Data, I'm using SQLite only.
I save the data in the table and then query them by opening the app and looking at the data using SQLiteStudio. I even create a LOG to check that the data is saved, and yes, it is saved.
But when I STOP and run the simulator again to consult, there is no more data!
Is Xcode overwriting the database every time? Or is something else happening that is outside my limited knowledge?
Without knowing more about how your application is setup, how you've got your app configured to build, or how it operates on the SQLite DB file in question I'll only be able to offer some pointers in things you can go check out about your code and build configuration that may be the source of your phantom deletions. Of course, if you have other info to provide, I'd be happy to edit my answer!
Case 1: 'Create DB' always running?
One thing that may be tripping your app up is what happens leading up to the decision to create a new SQLite DB file or look/open an existing file. If the code creating an empty DB is always running, then each time your app starts, your old DB file is getting overwritten with a blank DB.
Case 2: Using a 'starter' or 'template' empty database?
Sometimes developers may provide a blank database that contains the initial database schema (the general tables and structure) as well as some default or sample data. If your app does this, perhaps the logic leading up to the decision to apply that default database is accidentally always being triggered? If so, use of NSUserDefaults to record a boolean indicating the DB was successfully created may be an avenue to use to skip past the 'Load my starter DB' code. Alternatively, you could check for the existence of your DB file, or see if the contents of a specific table are different from the template data, etc.
Case 3: Different Behavior between 'Build & Run' vs. 'Run Without Building'
There's a not-so-well-known option in the Product > Perform Action menu labelled 'Run without Building' that will essentially kickoff another Debug session using the version of the application you just finished running in the Simulator or on Device. When you use this option do you see any different behavior with your database or is it still blank?
Case 4: Different Behavior when run directly in Simulator outside of an Xcode debugging session?
Part of the 'Run' operation is a build phase which may trigger the 'Copy Resources' phase even if your app hasn't changed since the last execution (as you suggest is the case in your question). If you are providing a stock 'default' or 'template' DB file and your app is simply opening and editing that 'template' during the first execution of your app, then Xcode may be replacing it with a clean copy on the subsequent 'Run' operations where 'Copy Resources' is happening. A way to test this avenue:
Build and Run your app to the simulator using Xcode like normal.
Perform some operations that would result in the creation or editing of data in your app's database.
Click the stop button in Xcode to return to the Simulator home screen.
Double-click the home button on the simulator (or if there is no home button, press CMD+SHIFT+H twice to bring up the multitasking bar and force-quit out of your application.
Check and see if your DB file has data in it.
If no data, then there is an issue persisting your changes into the database and we need to get that problem solved first. Otherwise:
Relaunch your app directly from iOS Simulator and perform different operations that would result in more or different changes to the database.
Click on the home button to return to the iOS Home Screen.
Force-quit your appellation as was done in Step 4.
Check and see if your DB file data has changed (but still has data) or has blanked out.
Finally, make sure you are following Apple's guidance about where to store user-data, if you are inadvertently storing something in an incorrect file path doesn't typically result in blanking of data, it may be prohibiting writing of data which could be interpreted as your data getting overwritten especially if you are interrogating it while it still is residing in an in-memory process. There's some really useful guidance about file paths in the Table 1-1: (http://developer.apple.com/library/ios/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/FileSystemOverview/FileSystemOverview.html)
Locating your Simulator App on your Mac's Hard Drive
To be thorough (and you may already know about this!), iOS Simulator applications are stored on your Mac's hard drive just like other files on your machine. Their organization mimics that of a physical iOS device. To get to your App and its data:
Open a new Finder window.
Press CMD+SHIFT+G or choose 'Go to Folder' from the 'Go' menu.
Paste the following into the 'Go to Folder' box then click 'Go': ~/Library/Application Support/iPhone Simulator/
Select the folder that matches the iOS version of the simulator you built to.
Click on Appications.
You'll then be presented with zero or more folders, each folder that appears will have a string of digits separated by hyphens. Navigate through this list until you find the one containing your app. You can then browse, and copy data out of this folder to somewhere to be examined by other tools on your Mac.
I've read all the tickets about this issue, but I still don't get it right. I have a non-document OSX app (for OSX Lion and MountainLion). I want this app to export and import custom data, associated with a custom file extension ".iobs". Internally, these files are just data archived with [NSKeyedArchiver archivedDataWithRootObject:], and saved onto the disk with the "iobs" extension.
So, my check list is this:
1) Export mechanism: checked. My app create correctly .iobs files. If I run "file <filename.iobs>" in the Terminal, I get "iObserve_exportedItems.iobs: Apple binary property list"
2) Declaration of an exported UTI, checked. As shown in the image below. I did NOT declared a custom Document type, since it I never use NSDocument inside my app, and there is no point. Anyway, I already tried and failed. I've tried also different combinations of "Conforms To" entries, but with no success.
3) Is there any 3rd point??? Do I need to start my app once to let the system know? I just ran it in Debug from Xcode so far, and this has no effect. So I guess my Info.plist is wrong, but I filled it from within Xcode4 interface, so???
Thanks for any help, hint, question, suggestion.
Ok, so apparently, I do have to declare a document type even if I don't specify a document class. See the attached screenshot. Note that leaving only the Document UTI doesn't work. I do need the two (exported UTI and document type). Note also that if I say it conforms to com.apple.binary-property-list, I don't have the right icon.
And for those who wonder, there is nothing to do to "register" a type (and its subsequent changes) apart from launching the app once.
Background: Up until Xcode 4.2, new projects created using any of the templates would contain a MainWindow.xib and therefore pass nil as the fourth argument of UIApplicationMain(). Starting in Xcode 4.2 all the templates instantiate the application delegate by passing the class string as the fourth argument and do not build the application's window in a xib.
It is trivial to accomplish this setup in 4.2, and of course it works as expected: create xib setting File's Owner to UIApplication and wire up the delegate, specify it in Info.plist, nil fourth argument in main().
Question: Why is Apple encouraging instantiating the application delegate and building the UIWindow in code now instead of the "old way?" What are the benefits?
Considerations: I would expect this new template behavior if you elect to use storyboarding as a way to manage the UI, but if you uncheck "Use Storyboards" I would have expected the old pass-nil-and-use-MainWindow.xib template.
This question was asked in a roundabout way here, but the answers are a little thin on discussion.
You're asking why Apple is doing something? There can be no definitive answer, unless Apple has spoken out explicitly, which they have not done.
Personally I find the new approach considerably more elegant, transparent, and bulletproof. As you rightly say, in the old approach the main nib was loaded automatically by the runtime in response to the Info.plist setting, and everything else that happened was done through the nib, in particular the instantiation of the app delegate and the window and the associated wiring (the app delegate must be made the application delegate, the window must be made the app delegate's window), except that then we come back to the code in the app delegate for final presentation of the interface.
This was hard to understand; it took a great deal of verbiage for me to describe it in my book. It was also easy to break. The nib has to know the name of the app delegate class, so if you didn't like those funny long names that were created by default, you could easily mess everything up when you changed them.
Now, however, the app delegate is simply named App Delegate and is instantiated in code by UIApplicationMain(), as you rightly say; and everything else is also done in code as a direct follow-on: the app delegate is instantiated and didFinishLaunching is called, whereupon we create the window in code, assign it to our property in code, load the nib if there is one in code, set the window's rootViewController in code, and show the interface in code as before.
Thus the bootstrapping is directly exposed to view because it's all code. This makes it easier to understand and to modify without breaking anything. It's almost as if previously the template designer was just showing off as to how much stuff could be made to happen magically and automatically behind the scenes; now everything happens out in the open, explicitly.
I try to implement Versions in application that already written for Snow Leopard. It is an Document based application with SQLite storage. Each document saves as an SQLite db file.
I have implemented appropriate methods in my NSPersistentDocument subclass:
+ (BOOL)autosavesInPlace {return YES;}
+ (BOOL)preservesVersions {return YES;}
Now I have new File menu in application with "Save a Version" etc. I create new document in my app, save it, make some changes, save again.. When I entering version browser I get:
kCGErrorFailure: CGSDisplayID: App trying to enumerate [0 to CGSGetNumberOfDisplays()] instead of using CGSGetDisplayList(). Compensating...
kCGErrorFailure: Set a breakpoint # CGErrorBreakpoint() to catch errors as they are logged.
In right side of version browser in list of versions I see few versions, but they do not displayed in stack of windows. It looks like windows are in stack but completely transparent. When I clicks on any version in list I get log:
CoreData: error: (8) attempt to write a readonly database
Than if I tried to restore one of versions - version browser normally closed, no window appears and program stops responding.
I can't understand what it all can means. Is it problem in saving version or in restoring? I just have no ideas. Will be grateful for any help.
Each Core Data store is already stored on disk when the versions browser is opened. Have you looked at your overrides for creating the document, and for reading them? Are you sure none of them also edit the document? You might also want to check your awakeFromNib methods, to see that you are not writing / saving anything to a new document.
It can be difficult to debug problems when leaving the version browser. To make it easier, you can edit your current scheme, select the 'Options' tab, and check 'Enable debugging in "Browse all versions" mode'.
I want to create a new split view-based iOS project from scratch using the template wizard of Xcode 4.0 (build 4A304a). I ticked the "Use Core Data" checkbox. When I try to save the generated test.xcdatamodeld Core Data model, Xcode says The document "test.xcdatamodel" could not be saved.
How can I save the file? I already checked the file system for the proper permissions, but they seem alright.
Aha - I've been suffering from this problem all day and just found the answer. I ran /Applications/Utilities/Console and tried the save again. This error appeared in the console:
AppKit called rmdir("/Users/kris/.TemporaryItems/folders.501/TemporaryItems/
(A Document Being Saved By Xcode)"), it didn't return 0,
and errno was set to 66.
Though I couldn't see anything obviously wrong with this folder (the permissions & ownership looked normal), removing the whole of ~/.TemporaryItems/ allowed me to save again.