I'm new programming with Objective-C (my strongest skills is .Net), on .Net there's a configuration file that the user can modified and the app gets this modified values.
My question is: There's something similar on Objective- C (my app is for Mac OS X)?
Thank you
If you're talking about preferences, that's handled by the NSUserDefaults class. The standard location for preferences to be written is ~/Library/Preferences/bundleidentifier.plist (where bundleidentifier is your bundle's identifier — e.g., com.apple.preview for Apple's Preview app). You can technically write plists anywhere, but it's bad form to go scribbling outside the standard locations without the user's say-so.
Related
I am developing an Applescript application using X-Code and I'm having the hardest time finding answers to questions. It's tough because I'm struggling to understand how the UI elements work, etc., and most answers to those questions are written in Objective C. I have learned a little bit about how to convert Objective C code into Applescript, but in most cases I'm still not sure.
For example, this answer shows some ObjC code, but I don't know how to make use of it in my Applescript application.
Is there a resource or guide that can help me to a) understand how to use Objective C code in my Applescript app, and/or b) how to rewrite Objective C code in Applescript?
In general, Applescript can be used to automate tasks (especially repetitive ones) for any MacOS application that exposes an Applescript dictionary.
One can compile and execute Applescript from within MacOS applications written in Objective-C (via the NSApplescript class, but the other way around, one would use Applescript to call into an already existing app (or one that you created yourself) that was written in Objective-C.
It sounds like you should write the lowest level stuff natively in Objective-C and see if you can automate that from within Obj-C, or expose an Applescript dictionary (via an sdef file that gets included in the Xcode project) and then you can use Applescript to do things via your native app.
Makes sense?
just curious if anyone knows a good tutorial or some info on how to create a custom file type for an application. By default, XCode uses binary for saves (and it's fully functional) but obviously it's better to have a custom file type for an application, rather than a binary file. Is this easier said than done?
After some false starts in earlier releases, Mac OS X 10.3 introduced the concept of Uniform Type Identifiers (UTI) to describe how files are associated with applications. UTIs try to incorporate all the previous mechanisms, including file extensions, legacy Mac OS file types, MIME types, etc. Applications can declare UTI information in the app bundle Info.plist. There is an overview in the Apple Developer documentation here. By the way, not everyone is convinced that UTIs are the best solution.
I have some basic familiarity with Objective-C, but prefer Ruby, so I'm thinking of playing around with MacRuby. Is it possible to use MacRuby to develop applications for the Mac App Store, or do I have to use Objective-C? (Note that I don't care so much about iOS/the iPhone and iPad store right now, just the Mac OS X app store.)
And to answer the actual question, yes, see http://lists.macosforge.org/pipermail/macruby-devel/2010-November/006475.html.
Short answer: Yes, you can, technically, build such an app. You need to revisit the store guidelines to know what requirements must be met to submit to the various stores.
This comes up sporadically; beyond the guidelines that #NSResponder mentioned, the reality is that you'll just be spending a lot of extra & unnecessary time if you decide to use MacRuby unless you plan on using some large chunk of already written Ruby code in your app.
Learning Objective-C is about 2% of the overall learning needed to be an effective Cocoa developer. The other 98% is everything from memory management model to standard idioms like KVC/KVO/delegation to NIB files to the myriad of classes & APIs throughout the system.
All of those things are written in Objective-C (or C) with documentation targeting Objective-C and examples written in Objective-C.
As well, the entire tool chain is focused on validating, compiling, indexing, debugging, and manipulating Objective-C.
If you want to use MacRuby to build a real Cocoa app, you are going to have to know Objective-C through and through anyway. And you are going to have to deal with whatever bugs and impedance mismatch is in the bridge layer, too.
Yes. As the Mac developer forums says:
My Mac app is not written in
Objective-C. Is this allowed on the
MacApp Store?
Yes, provided it also adheres to the
Mac App Store Review Guidelines at
http://developer.apple.com/appstore/mac/resources/approval/guidelines.htmland
the Mac Developer Program License
Agreement at
http://developer.apple.com/programs/terms/mac/mac_program_agreement_20101020.pdf
(via alloy)
Read the submission guidelines here: https://developer.apple.com/appstore/mac/resources/approval/guidelines.html
I was wondering if and in how many way an app can access specific funcions of another app.
for example
open an url in safari/firefox/chrome
run a javascript in current browser-tab
play/pause itunes
rename selected files in Finder
I am aware of the existence of applescript but i was wondering if that's the only way i have to interact with those apps and others
thanks
There are three main ways an app exposes its function to the outside world.
One is by supporting an URL protocol. To open an URL, just use NSWorkspace. There are many methods; if an app registers a specific protocol like x-my-app://some-work, you can just do
[[NSWorkspace sharedWorkspace] openURL:[NSURL URLWithString:#"x-my-app://some-work"] ];
If you want to open an URL whose protocol (say http) is supported by many apps and if you want to specify which app to use, use openURLs:withAppBundleIdentifier:options:additionalEventParamDescriptor:launchIdentifiers:
.
Another is the System Services. With this, an app can add entries in the Service menu and in the context menu of other apps; you can also call it programmatically.
Otherwise, it's via Apple events. Applescript is one way to deal with them, but not the only one. It's just a language to issue Apple events. There are many ways to deal with Apple events from Cocoa, see this detailed document by Apple.
Basically, an app can export its internal as an object-oriented manner (which is not just its Objective-C hierarchy; you can control how much of its internal objects and methods you expose, etc.) by an sdef file. Then, another app can use this object-oriented system via Apple events.
To send and receive Apple events, you can of course construct them by hand, but you can use higher-level objects like
Applescript via NSAppleScript
Scripting Bridge
or AppScript.
To learn what kind of aspects an app exposes, just open the AppleScript Editor and choose the menu File → Open Dictionary, and choose an app.
Now, it's rather hard to use features of an app which the app does not expose via any of these methods. You still have a few workaround.
UI Scripting. This is done by sending Apple Events to a headless app called System Events which is one of the core program in OS X. This way, you can programmatically emulate clicking a button, choosing a menu, etc. of another app. So, almost whatever you can do using GUI with another app can be done programmatically from another app. To see the hierarchy of UI objects accessible from UI scripting, use a utility which comes with XCode tools, at
/Developer/Applications/Utilites/Accessibility Tools/Accessibility Inspector.app
This is very rudimentary but does the job; if you regularly use UI scripting, consider obtaining UI browser, as Zygmunt suggests.
Finally, if you want to use a non-GUI non-exposed feature of another app, you can inject a code into another app.
Just expanding on Yuji's answer. If you were forced to go the UI scripting path, there's a nice application to analyze the interface - hxxp://pfiddlesoft.com/uibrowser/. However, the examples you mentioned should expose some APIs.
I might also recommend using Sikuli hxxp://groups.csail.mit.edu/uid/sikuli/ as an IDE to script around user interface robustly.
For some applications usually coming from GNU/Linux there is D-BUS hxxp://en.wikipedia.org/wiki/D-Bus - although I haven't used it on a Mac on my own yet. And let me also quote Wikipedia about Cocoa "It is one of five major APIs available for Mac OS X; the others are Carbon, POSIX (for the BSD environment), X11 and Java." hxxp://en.wikipedia.org/wiki/Cocoa_%28API%29 That's just a loose tip for further exploration as Yuji has already explained Apple events that are key to your question.
I have been researching around trying to find the best way to begin developing an application which aims to analyse user's writing styles based on outgoing SMS messages. I have installed Symbian's SDK and Carbide and purchased a book on their specific style of C++ to get started. However, I was told to check out Open C for Symbian as I have some previous C experience. I have installed the plugin from http://www.forum.nokia.com/Resources_and_Information/Explore/Runtime_Platforms/Open_C_and_C++/ and tested a simple Hello, World! application with success.
Although, the initial success would lead me to believe Open C would be a better option for me, I am worried about limitations of using Open C. For example, I need to be able to access native functions of the Symbian OS to capture keystrokes while in the SMS composer. I also need to be able to run my application in the background and have it load on system startup as not to interfere with user's normal activities.
Can someone clarify if Open C can access such functions and fulfil my needs in terms of developing this specific application? Also, what are the limitations to using Oepn C in comparison to the standard Symbian C++?
I'm by no means a Symbian guru but we've used the Open C/C++ plugin for Symbian here. My understanding is that the plugin is simply an extension -- it gives you the standard libraries and lets you deal with familiar functions (in our case, just the simple cstring.h, and stdio.h libraries were what we were looking for).
You can still mix and match the Symbian calls and likely will have to deal with some painful conversions to get your char* into the proper "descriptor". However, you should only have to do these at the interfaces at which you're touching existing Symbian libraries (as they're going to expect descriptors, not char*s).
In our code, we have some places where we're using a remove call to delete files and in the same class, creating the detailed Symbian RFs abd RFile objects.
So yes, while we use C/C++ libraries to do some low-level stuff and a lot of string manipulation, we're also using the Web Browser Control, key input monitoring and all that.
...And yes, we need to clean up our code. :-)
Open C provides a set of standard C libraries for Symbian OS programs i.e. it is a library.
This means you can call Open C code and Symbian native code freely in the same program, just as with any other library, provided you respect the preconditions and assumptions that the libraries require.
This is where the complexity comes in, because the standard Symbian APIs often require things like descriptors and a working active scheduler, whereas the Open C libraries don't. But provided you're careful you can do what you want.