I have two questions regarding Apple's +[NSUserDefaults standardUserDefaults]:
1) Does this object represent preferences that are shared across all apps?
2) If not, and it has preferences for the current app only, what is the behavior in case I use it in a library that is embedded into two different apps? Will it be shared across these apps or not?
No, it is an object only used by the running application.
It will return the user defaults for whatever application is linked to the library or framework, and each application will still have their own object.
Although mipadi is absolutely right, I'd like to add some value here.
If you explicitly want to share preferences across apps, there's "App Suites" for you.
NSUserDefaults documentation
Related
I'm thinking about a new mobile/tablet application.
I want to allow the users to develop their own plugins.
Imagine a cash desk application running on a Android tablet. The user could use many alternative when connecting to the credit card reader (Square, Sum'Up, ...).
If my application was an old Win32, I would just publish an API and let Square or Sum'Up developpers create a DLL. This DLL would then be placed somewhere on the computer. At application startup, I just have to look for those DLL and dynamically load them.
In fact, the real question is : Is it possible to create a plugin based application ? I'm thinking about Managed Extensibility Framework here. Many questions come to mind :
How to deploy those plugins ?
Does this work for all the platforms (iOS, Android, UWP) ?
...
I was unable to find any documentation on this.
Many thanks for your thoughts and indications.
Not sure if this answers your question fully.
However, a MEF like architecture could probably work on Android if you put the DLL's somewhere publicly discoverable, such as in /storage/emulated/0. Alternatively, such plugins could be distributed as separate Apps, providing Services, Content Providers and Activities consumable from other Apps.
However, on iOS you would not be able to publish such an App in the App Store though, as Apple does not allow you to use dynamically linked libraries there. You could maybe do it for Apps that don't go on the App Store, such as for Enterprise distribution.
While it might not be the greatest solution. You would always be able to navigate between Apps on iOS through URLs. However, that is not the greatest experience, since this would mean you would be leaving your App every time you wanted to get into a "plugin" App to do something.
The question is primarily applicable to third-party Mac software which contain multiple applications such as helpers or uninstall items. This is aside from one or more individual app files that may or may also not be displayed. Some of the shown do not seem to match the intended use for the Launchpad.app because they should not be visible to the user in that context.
For example, Adobe CC installs and shows a folder named "Adobe Application Manager (Other)" that contains "AAMLauncherUtil.app". The extension is hidden in the Launchpad.app view. The actual location appears to be /Applications/Utilities/Adobe Application Manager/core/.
This does not apply to apps submitted to the Mac App Store. One simple reason I suspect is that the Mac App Store will only allow a single app binary submitted.
I have note been able to find any reference to Launchpad.app or developers preparing their programs specifically for Launchpad visibility in OS X developer documentation. Every other search for this question returns related question for end-users trying to organize and hide their own apps. Some of the answers to these questions are related to desktoppicture.db and modifying it's contents.
Updated 4-9-2013
This is a total repost of my earlier question. As I have learned much more about Launch Services, UTIs and the depreciated creator codes, I feel I can better ask the question from scratch.
Problem Description:
We have an application that was designed for Legacy Mac 9.xx which still runs on Snow Leopard(with Rosetta). The application uses bundled files We developed our new app for Snow Leopard and beyond. The issue is that Launch Services does not properly associate the new app based on the plist configuration we are currently using and I need to know what I am doing wrong.
If I right click on the bundled document and select GetInfo, I can associate the bundled file to either the legacy app or the new app and it will work as I expect it to. I believe that is because snow Leopard still used the Creator Code technology for this type of association. If I tell the file to associate itself with the old legacy app and I press "Change All" , Launch Services will correctly associate all files of that type and it will work as expected. If I tell the file to associate itself to the new App and I select "Change All", The app will open but the files will not. From what I can tell, Launch services is assigning a dynamic UTI to the app and it when the file is clicked on, The OS doesn't know what app to use.
I found a couple of posts out there that seem to suggest Apple might have made some design mistakes in the new UTI methodology. One post here shows how to add an array of string file extensions to the ExportedUTIs dictionary of the new apps pList. This gets the app to function correctly, but that is not going to solve the problem; If we allow our users to name their files anything, we cant predict in an array what their file extension is going to be. We need Launch Services to operate correctly strictly with the UTI code, or some how get the OSType code to work.
Post about UTI's
Once the new app decides it can't open it's related file, I have to open the LanchServices.plist, delete the entry and restart the lsregister database. Then I can once again open a file with the new app(by associating it without pressing "Change All").
I am attaching some images to the app plists , the bundled document plist and the Launch Services entry:
Any help and our guidance is much appreciated.
Mike
Updated : 4/16/2013
The link to the post about UTI's I provided also includes a link to an open source software app called RCDefault app. This app will associate your APP to the given file based on your choice of UTI's , file extensions, OSType codes, and file types. Strangely, this app is able to associate the file to the app based on the UTI's structure that is provided in our plists.
Is it possible this is all just a bug in Launch Services for Snow Leopard for this specific scenario and Apple has chosen to just ignore it at this point(considering they no longer support Snow)?
You're missing your CFBundleTypeExtensions. Create a CFBundleTypeExtensions of type Array, and Item 0 should be your file extension.
You're also missing your CFBundleTypeName, which is the alias type that the file will use. Makes it nice and pretty. :)
Reference (CFBundleDocumentTypes): https://developer.apple.com/library/mac/#documentation/General/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html
Its been awhile since I originally posted this, but just in case this is interesting to anyone else I have made some additional discoveries:
This problem doesn't have much to do with trying to be compatible with a legacy app and an OSX app. The bundled file contains a creator code and an OSType code. As long as these two items exist in the legacy apps plist it will open when ever it is asked to, globally or individually.
The problem appears to be trying to include the ostype code in the newer apps plist as an equivalent type under Exported type UTI's.
The only solution that appears to work is to add the array of file name extensions
as an equivalent type as #Derek mentioned to begin with.
That is the only solution that solves this problem. Ironically this violates apples human interface guidelines which states to some degree that a user should not be forced into file extension restrictions.
It appears that UTI's only work on non bundled documents(files), which is also supported by a few posts out there that basically say apple really screwed this up. What is the point of worrying about UTIs if in the end you need the array of extensions anyway?
All,
I'm writing an extensive iPad application with a Core Data based data model. Because the app requires a lot of user input / typing, I would also want to make the functionality available as a web page, so that users can use standard PCs to key in some of the data.
I'm not particularly worried about the UI for that web app, but I do want to re-use the application logic and Core Data model that I'm using for the iOS app, so my preferred approach would be to expose the functionality as web services on a Mac (using the built-in Apache web server, most likely), using XCode for MacOS.
(1) Are there any existing XCode-based frameworks that simplify the generation of web services?
(2) Am I missing something obvious i.e. is there a better approach to tackle the problem "exposing iOS functionality through a web environment"? Obviously, I could've immediately focused on writing the app in HTML5, but I did want to leverage all the goodies that come with iOS/Cocoa.
(3) Alternatively, I could write a native Mac OS app. That facilitates the re-use of Core Data, etc., but I heard it takes a lot of work to port iOS apps to Mac OS. The question then is what's more work - exposing the functionality as web services or porting it to Mac OS... in both cases, I would need to rewrite the UI.
thanks everyone,
Fabian
If you want iPhone/iPad users to be able to access the App through the PC web browser to send data/files to the App then take a look # this one:
http://blogs.oreilly.com/iphone/2008/09/creating-an-iphone-based-web-s.html
Check this question too:
https://apple.stackexchange.com/questions/9012/has-anyone-ever-tried-to-use-an-iphone-as-web-server
I did some more research and came across the WebAppKit framework. It allows you to easily set up a web server capability and handle requests and responses. It's lightweight, easy to understand - exactly what I wanted.
As someone new to developing for macs I was wondering if I could gather some advice on dealing with network proxies. Currently the software makes use of:
NSURLRequest
NSURLDownload
[NSString initWithContentsOfURL:]
WebKit / WebView
I had a little search on google and found Apple's page on CFProxySupport although I haven't looked too deeply into implementation with the above. I also see that you can configure proxies in Mac OS X's System Preferences - do the above automatically use the values set here?
Also, in terms of user interface, what is usually expected when it comes to proxies? Is it acceptable to simply require the user to set the details in the System Preferences or should I really be providing the ability to set the details separately in my own application?
Thank you.
NSURL, WebKit etc. automatically uses the appropriate proxy set in OS X's System Preferences.
On the other hand it's difficult to set the proxy which is different from that in the System preferences if you use these APIs.
For a normal app, it's expected that you don't set proxies in your app ... E.g. my dad and mom dread internet configurations. They ask me to set up the internet for them for their Mac. I don't think they're willing to set the preference separately for separate apps.
Of course if your app is a download assistant, file uploader, or maybe a completely independent browser as FireFox, you might want to implement a separate proxy setting for your app, to suit the need of the geeks and nerds like me who uses your app!