I have a Mac "Shoebox" app that internally uses NSDocument objects, but does not expose the concept of individual documents to the user. (I rely on NSDocument to make syncing via iCloud easier.)
My problem is that when a version conflict arises, my app shows the default NSDocument conflict resolution alert (see below) letting the user pick one or two winners.
In the concept of my app this doesn't make sense. Is there a way to intercept/prevent that alert and handle the conflict programmatically?
I know that I can detect version conflicts with the code below. However, I still need to prevent the alert sheet.
[NSFileVersion unresolvedConflictVersionsOfItemAtURL:document.fileURL];
Example conflict resolution alert:
This is the built in behavior of NSDocument when it discovers there are unresolved version conflicts. If you do not wish to use it you'll have to drop support for NSDocument and use a lower level abstraction like NSFileManager + NSFileVersion.
You can override + (BOOL)usesUbiquitousStorage and return NO.
This will no longer show the ubiquity conflict panel.
See the doc Resolving Document Version Conflicts
Strategies for Resolving Document Version Conflicts
Your application can follow one of three strategies for resolving document-version conflicts:
Merge the changes from the conflicting versions.
Choose one of the
document versions based on some pertinent factor, such as the version
with the latest modification date.
Enable the user to view
conflicting versions of a document and select the one to use.
Which strategy is best to use depends a lot upon your document data. If you can merge the contents of different document versions without introducing contradictory elements, then follow that strategy. Or choose the document version with the latest modification date if your application doesn’t suffer any loss of data as a result.
Generally, you should try to resolve the conflict without involving the user, but for some applications that might not be possible. If an application takes the user-centered approach, it should discreetly inform the user about the version conflict and expose a button or other control that initiates the resolution procedure. An Example: Letting the User Pick the Version examines the code of an application that lets the user select the document version to use.
Related
I knew that modifying core-data previous version breaks the light-weight migration.
But I have inverse relationship warnings on old versions of data model.
I tried removing old versions that are used before launching first version of our app. I followed this SO question, "How to delete an old/unused Data Model Version in xCode 4"
It removes warning(Of course it should)
But I cannot run our app anymore
I think I should keep every versions even though it is not related to light-weight migration
I saw this SO question, "How to disable no inverse relationship warning for CoreData in Xcode 4.2?". And I tried setting the MOMC_NO_INVERSE_RELATIONSHIP_WARNINGS to YES.
It doesn't removes warning
And I don't want my future mistake, missing inverse setting, also be ignored.
I think this option is not for my case
I don't want to see compiler warning for old version of data model(.xcdatamodel).
Because these models are not used so that warnings are not significant.
But I want to see future inverse relationship warning on newer version of data model.
What option can I take?
I'm developing a site for my company and I also need to modify the native component "mailto" to fit our needs.
I'm working with a joomla 2.5
I was wondering if future updates occur, what will happen to the lines I've added, for example, in "\components\com_mailto\controller.php"...
I haven't find answers on the net.
Also, for the same reason, I've modified the default layout of an article. Should I rename it? and if yes, how, because I couldn't do it (when I've tried the article did not display).
Thanks for your help
Before starting to edit core Joomla components, should should always have a look at the options you have. I don't believe in editing core file as it simply causes problems for updates when released, therefore in my opinion, you have 2 options:
I always make a note of all my requirements and start looking for a 3rd party extension that caters for my requirements.
If I cannot find a 3rd party extension and don't particularly want to start digging into it's code, I would go with developing a plugin. Plugins are used to manipulate the behavior or something and therefore come in extremely handy for when you would require core editing.
Editing the layout of an extension view is completely fine, but it's strongly recommended you make a Template Override so that if the extension does ever get updated, your changes won't get overridden.
So to answer you initial question, any line you have added to the controller.php file will get overridden when you decide to update the extension.
Hope this helps
While the answer from Lodder is totally valid, as a last resource you can also consider forking the com_mailto as a separate component.
This has some disadvantages:
you need to rename all the files involved (controllers, models, views)
you need to maintain it and keep in in sync with future updates (consider than you are now on 2.5.x and in a year you might want to upgrade to 3.x).
I am going to upload my first mac app to Apple Store
And fixed all validation bugs of icon,category...
But after then I passed validation with warning :
The resulting API analysis file is too large. We were unable to validate your API usage prior to delivery. This is just an informational message.
And my upload be rejected with the reason : "Invalid binary"
Is there anyone has experience of this case ?
UPDATE : this warning is not the reason of rejecting, it maybe the app archiving problem. I successfully released my app to store.
So, we can safely ignore that.
Apple forbids using private or undocumented APIs in iOS apps. Any calls you make to methods that have the same name as private or undocumented API methods will be flagged as a private API use, even if the method being called is something you have defined yourself.
App Loader does an initial scan, checking for method names, instance variable access, and even #selector usage with private method names. App Loader doesn't always do a great job, and the more source files you have the more likely it is to give you the warning that the API analysis file it has generated is "too large".
Fortunately, you can still submit your application, despite of the warning. Apple will check it internally, and if something gets kicked back because of overlapping names, you'll have to wade through the review process again.
Erika Sadun tried to make an app called API Kit that would do the scanning for you, but she appears to have abandoned her work and removed any trace of the application from her website.
Chimp Studios created App Scanner to do the same thing, but it hasn't been updated since 2011. Unfortunately, for large projects -- and this includes projects with a lot of extra pods from CocoaPods -- there is no current (2014) good way of solving this problem other than proactively naming things such that they won't conflict with private API method and instance names.
You can proactively learn about Apple's Cocoa Naming Conventions and try to anticipate. That will reduce future headaches. Until Apple introduces something like namespaces, however, we may continue to run into this problem from time to time.
The "invalid binary" error can come from a number of causes, but it is entirely unrelated to the API analysis document created by App Loader.
You should know that even with the scanning, there are still ways to get around the prohibition on using private/undocumented APIs. :)
After hitting this issue for the first time on my first Swift project, it looks like the most common answer to this question is now:
If you use Swift 2.x and XCode 7, you'll get this error. Just ignore it.
[UPDATE: XCode 7.3 & iOS 9.3 rollout seems to have fixed this issue!]
Here is an easy way to get around them... store the selector name in reverse, like "dlroWolleH", then reverse the string before you call the method.
If Apple gets wise to that then you can encrypt them.
I am making a QuickLook plugin that will be included with my application. It will be used to preview a file type that other applications also have QuickLook plugins for. Every time I attempt to test with my plugin (I put it into ~/Library/QuickLook/) it previews with another app's plugin. I am using qlmanage to preview. Is there a way to force it to use mine, at least for testing?
Generators embedded in applications are always preferred to plug-ins in ~/Library/QuickLook (which are preferred to the ones in /Library/QuickLook, which are preferred to the ones in /System/Library/QuickLook).
There is no way to change this priority. Also if 2 generators at the same level claims the same type of file, Quick Look will prefer one over the other, whichever you can't control.
At least for your test, you can force qlmanage to use the plug-in you want by using the -g option (but you will also have to specify the content-type with -c).
Try qlmanage -h to get all the options for your tests.
While the order of precedence described by #julien is accurate, it is still possible to override a particular application's QL provider. Simply edit the Info.plist file in the .qlgenerator of the offending application. For example, I like the way a certain QL provider handles markdown, but one of the text editors I have installed includes (imho) less than stellar markdown support. My preferred bundle loses... until I edit:
/Applications/BadMarkdown.app/Contents/Library/QuickLook/BadMarkdownQL.qlgenerator/Contents/Info.plist
and remove
<string>net.daringfireball.markdown</string>
And in newer versions of OS X, you don't even need to restart the QL daemon. The preferred QL tool just takes over. =D
I built two separate Firefox extensions which are fundamentally incompatible with each other. The incompatibility is by design, as it would be totally unlogical for a user to install both. While I can stress out in the doc that both shouldn't be used at the same time, I don't trust the user to read the doc, and I'm looking for a way that one extension could detect the presence of the other and either disable itself or the other one (ideally while popping an error message).
Is there a way for an extension to be aware of the presence of another extension? I know it's possible for an extension to specify it depends on another one, but what I need is the exact opposite, a way for an extension to specify it conflicts with another one.
Firefox Addon Development : Detecting non-compatible addons?