The NSTabViewController was only introduced in OS X v10.10, so NSTabView already provides everything you need for creating a tab view. When would you use a NSTabViewController, and is it only there to be subclassed?
I would use NSTabViewController to get rid of a lot of code I used to have to write to have a tab view and transition between those views (most often done in Preference windows in Mac apps).
You'd obviously have to be 10.10 only, but these days that's a safe bet.
As for subclassing it, judging by the api I'd start without sub-classing it. You can set the style, the transition options (a nice benefit of using it!), and then call addTabViewItem: and let it do it's stuff.
If you compare iOS & OS X, you will feel OS X is bit deviated from MVC. OS X default 'new project' opens with AppDelegate as compared to iOS with 'ViewController'!
Now, it seems, Apple decided to make it by adding Controller as well. So that the view NSTabView is controlled by NSTabViewController.
And yes if you design to subclass it and use that should reduce your job. Same thing is mentioned even in Apple Documentation.
Related
I have a simple image view. Which I don't want to be read by the accessibility clients. I tried the solution given here. However this solution didnt work. Also I have one limitation. I want to support OSX 10.9 Hence I cant use accessibilityElement Property provided by AppKit since its only available from 10.10
Please let me know a simple way to make certain elements inaccessible for voiceover clients.
Also I would to know the 10.9 equivalent of accessiblityElement.
Most methods in the NSAccessibility informal protocol were deprecated in 10.10 in favor of property-based accessibility configuration. Prior to 10.10, you would mark elements as accessible (or not) by overriding accessibilityIsIgnored().
In modern versions of macOS, you can use accessibilityElement for this. When seeking to hide an NSControl, though, it's important to use the control's cell to hide the element from all flavors of accessibility. (VoiceOver, Switch Control, Hover Text, etc.) So in the case of an NSImageView you would use:
myImageView.cell?.setAccessibilityElement(false)
Since iOS 5.1 was released, the default for showing the Master view controller in split views is a slide in type of thing. In order to present a popover it seems like you have to enable it using a UIPopover controller instead. Does this mean that the popover is going to going out of style?
When it comes to Apple's API's, deprecated means that Apple has specifically stated that something is in the process of going away. It's usually accompanied by advice regarding a new way to accomplish the same thing. So, if Apple ever deprecates UIPopoverController, you'll know it just from reading the documentation.
That said, it's also a good idea to read the release notes for each new version of iOS that comes along. In the iOS 5.1 release notes you'll find a note that explains what you're seeing:
In 5.1 the UISplitViewController class adopts the sliding presentation
style when presenting the left view (previously only seen in Mail).
This style is used when presentation is initiated either by the
existing bar button item provided by the delegate methods or by a
swipe gesture within the right view. No additional API adoption is
required to obtain this behavior, and all existing API, including that
of the UIPopoverController instance provided by the delegate, will
continue to work as before.
I have a general question for Xcode programming and the usage of the Xcode tools.
I am quite new (4 months) in iOS development and I almost never used the Interface Builder for my purposes. I always created instances programatically. My question is basically if you think i should get used to work with IB or should/can i proceed like i do now?
If you are fine with defining your UI programmatically, then I do not see any issues with that.
Interface Builder allows you to "graphically" define your interface, and this can be an invaluable tool for playing with your UI prototypes, but apart from that there is nothing that you can do in IB that you cannot do programmatically.
In my case, I see that it depends on the kind of UI that I design. When I need a pretty basic UI, the IB is unbeatable for me. On the other hand, when my UI tries to be a bit custom, then I prefer doing everything programmatically.
An interesting point is that you could use IB to design your UI, deciding on sizes and positions of your elements, and the create it programmatically.
Yes you should use IB, basically xcode having IB for ease of development, no need to setting controlls by using coordinates and each time see their visibility by running the app.
just drag and drop and at the time of making the views, you can see hows your screen going to look.
Also using IB is not a typical task so,start development using IB.
I cannot understand how to design an application in optimal way for a single window application to work in Mac OS X. I would prefer a single document - single window application (I'm not coding a utility application), but it is not clear where should I initialize a window content.
On iOS I should use -[UIViewController viewDidLoad] or -[UIViewController viewWillAppear:] method of a root view controller for that purpose.
Could you please advice me any tutorial or explain how to deal with NSDocument - NSDocumentController - NSWindowController - NSViewController classes?
Thanks for your answers. :-)
You could put your window logic into your AppDelegate, but I discourage it. I recommend doing your own separate NSWindowController subclass to control the window, even for a single-window app. It's a very nice separation.
I don't see why one would want to use NSDocumentController for a single-window app. NSViewController is meant to control your custom views. It's usually not used in the average simple Mac app, unless you have some custom views you want to control specially.
So, in your AppDelegate's, say, applicationDidFinishLaunching:, you would allocate and initialize the window controller and show the window.
There is a good chapter in "Cocoa Programming for Mac OS X" by Hillegass on how to work with window controllers. Apple's docs also have some material on it, of course.
I have been trying to make my Mac application enter fullscreen now for a while but can't get it to work. According to the Apple developer center, I should use enterFullScreenMode:withOptions: which gives me, method enterFullScreenMode not found.
Everywhere I google there seems to be people having issues with making their app fullscreen, so what is the way to make it work?
Edit:
Of course enterFullScreenMode is for the NSView and I used it on a NSWindow; it's not the view I want to have fullscreen, but the window. I can't find any function for the NSWindow though.
Lion has some new APIs for full screen.
To do it with NSWindow, do this
[window setCollectionBehavior:
NSWindowCollectionBehaviorFullScreenPrimary];
To do this with NSApplication do this
[[NSApplication sharedApplication]
setPresentationOptions:NSFullScreenWindowMask];
A bit more about it here.
Modern day Mac Os X developers (who use storyboard) need only to click on their main.storyboard, select the NSWindow (not the NSWindowController), Use the right panel to find the attributes panel (the one that to the left of the ruler, it looks like a drag-bar thing) look for "Full Screen" and select "Primary Window" rather than its default value of "Unsupported". You can also set up Auxiliary windows if that's what you want.
Don't fight the change, use storyboard. One of us... one of us...
As mentioned in the link Jonathan provided in the comments, enterFullScreen:withOptions: has a number of drawbacks that can make you want to tear your hair out. The best way to do fullscreen is still the older CGDirectDisplay API. Cocoa Dev Central has an article on fullscreen apps that covers pretty much everything you need to know.
You'll notice the article is pretty ancient and the dev tools have changed a lot since then (Project Builder! Ah, the good old days), but the code itself will still work.
[self.view setFrame:[[NSScreen mainScreen] visibleFrame]];