I have used Core Data just creating projects with "Use Core Data" checked, using the code that XCode creates by default and, if necessary, adding or modifying just a few things.
Now I have a "main" app and I have created a helper app (status bar item app, LSUIElement = 1 and Login item). The helper app is Build as main app target dependency and copied into the main app "Resources" folder.
When the status bar icon is clicked the helper app shows a window to the user to collect some info to create a new managed object according to the main app Core Data Model.
But, how can I create a new managed object from the helper app for the main app?
By now I´m thinking to:
check if main app is open or not (I don´t know if it´s possible)
if it´s open, let the main app to perfom a selector with a dictionary with the info sent from helper app (I don´t know if it´s possible)
if it´s close then (in the helper app) create a persistent store coordinator, manage object model and manage object context using the model and persistent store files from main app. Create the new managed object. And I don´t know if it´s better to terminate MOC, MOM and PSC each time the user creates a new MO to avoid conflicts when main app opens or it´s not optimal and could affect performance...
It´s a good approach? Any point to start? Thanks in advance
Do you have to create a managed object? If you're just collecting simple data in the helper app it would be much simpler to pass that input to the main app via the userinfo dictionary in a Distributed Notification. Then the main app could create the managed object and you don't have to deal with merging changes between the two contexts.
Otherwise you'd have to pass the helper app a path to your MOM, create a MOC in the helper app, create the object, save the MOC while notifying the main app to merge changes by passing the IDs of the changed objects, reloading your main app's model objects, and so on. I've gotten it to work, but it's a huge headache and prone to errors. I'd avoid that route if possible.
Edit: I just realized you want to be able to write to your main app's store even if it's not running. It sounds like you need to re-think this before writing any code. If the helper app executes on its own, it's not really a helper app. Could you go into more detail about what you're actually trying to accomplish? This kind of hackery is not really a good idea and could lead to data corruption.
Related
I have a Finder Sync Extension that will display a badge on a file based on the state of a local database. It's straightforward enough to query this database in the requestBadgeIdentifierForURL function, but what if I want the badge to change for a Finder item that's already visible if the state of that database has changed (which can be via a notification through any variety of mechanisms). The documentation (https://developer.apple.com/library/content/documentation/General/Conceptual/ExtensibilityPG/Finder.html) would seem to imply this is possible with this statement:
You might also want to track these URLs, in order to update their
badges whenever their state changes.
The only ways I can imagine this would be possible (and most seem wrong) would be:
call setBadgeIdentifier:forURL from another application that is aware of the change
Launch a thread in the init function of my extension which listens for notifications and calls setBadgeIdentifier:forURL when it receives them
Call some OS API that prompts Finder that the extension should be triggered via requestBadgeIdentifierForURL.
Only the last one seems feasible, and could be managed via the extension informing the outside resource what needs refreshing via the beginObservingDirectoryAtURL/endObservingDirectoryAtURL callbacks, but i don't know what mechanism could do this.
I am new to cocoa development.
I just created for the first time a new document type application using core data and notice a few strange things.
AppDelegate is practically empty, there is no code to create the core data store, the managedObjectContext, nothing.
Two files were added: Document.m and Document.h that I understand is the model for dealing with the documents the app will create.
Even with no visible core data initialization code, Xcode created a .xddatamodeld file and this is the strange part: Xcode named the file Document.xcdatamodeld. Normally Xcode would name that with the same name of the project. By naming it Document it is like saying that this model has something to do with Document.m and Document.h.
Is 1 and 3 a bunch of nonsense from Xcode or am I missing something?
Can you guys explain? Thanks.
Short answer to your questions: the behavior you're seeing is caused by you creating a document-based application. If you created a shoebox (non-document-based) application, you would see different behavior.
Regarding Question 1, when you create a new document, NSPersistentDocument creates a Core Data store and a managed object context for the document. Each document has its own Core Data store and managed object context. Creating the store and managed object context in AppDelegate is fine for a shoebox application because a shoebox application has one set of data for the whole application. But creating a store and managed object context in AppDelegate makes no sense for a document-based application because there can be multiple documents open, each with its own store and managed object context.
Regarding Question 3, the data model has the name of the document because a document-based application creates documents. Suppose you're creating a screenwriting application with a document name of Screenplay. When you choose File > New in the application, you're creating a new screenplay, not a new instance of your application. That's why the data model has the name of the document, not the name of the application.
how do you call the app delegate methods in the view controller. i want to save my app data before the application terminates. in another app ive created an instance of the delegate and a variable inside it, so every few seconds it checks the delegate if this is true (it sets it to true when the application will resign active) but this doesn't seem the most efficient way to do it.
if you want to save your app data before the application terminates,hen save your data in applicationWillTerminate method of application life cycle.
there is no need to more one delegate, apple already providing you this facility then why you are creating new one. just write your code in applicationWillTerminate method
just reference your viewController from appdelegate & you can call to method in which you want to processing save data.
The new Open Graph beta is telling me that I cannot use the action 'want' or the object 'item'
I have used them in previous applications, however these have since been deleted and I've created a new application where I cannot use it.
Is this a bug, or am I doing something wrong?
Perhaps the types are not defined in the namespace you're using (or they were restricted to the app that defined them). If the types have not been created within the new application, you probably should use the Get Started tool that's available in the Open Graph section on the app control panel to create you Action and Object types.
I am relatively new to Cocoa/Xcode and am not sure if I am structuring my application in the most "correct" way possible. I have a number of objects which are active the while time that the application is running. Should I be creating these objects manually or with Interface Builder?
The type of objects I am referring to:
"downloader" which is responsible for downloading files to disk
user interface updater which is responsible for updating the user interface to show the results of the downloaded file
Should I create these objects in IB and set up the connections between them with code?
It's really a matter of personal preference.
In my opinion IB only really good at laying out views, so I tend to only use IB for my view and my view controller, and I create everything else in code in the view controller's viewDidLoad or init method.
In your example, connecting the "downloader" object directly to the interface seems like an MVC violation, so I would keep the downloader out of my xib.
The "interface updater" would be connected tightly to the interface, so it could be in the nib, although unless I had a good reason not to I would probably just put that code into my view controller class.
If you are creating things in code, note that viewDidLoad/viewDidUnload can potentially be called a number of times, as the os loads and un-loads your views when they are not visible to save memory. So only put transient objects there... things that must exist for the life of the view controller should be created in the init/dealloc methods. Part of why I like to do most of my object creation in code, is the finer level of control you have over memory.
I typically build as much as I can in IB, and then switch to code when I run into the limitations of IB. It sounds like you should be able to create the UI you described in interface builder.