In iOS, you have a concept of View Containment, is there such things in OSX?
Basically I want to create multiple nsviewcontroller each managing a specific view. I'd have a MasterViewController with a menu on the left (like ITunes), each time the user click on an item on the left, it would load the correct nsviewcontroller to display it's view.
Any tips to achieve what I need is appreciated
Thanks,
As of OSX 10.10 there is, watch Storyboards and Controllers on OS X.
Comment.
NSViewController did basically nothing (other that load NIBs) for years, I'm glad to see that it finally got from attention. Certain people in the Cocoa crowd here have a snotty attitude about the view controller programming style; I've asked questions like this before and had the "are you a iOS newbie coming to Cocoa" response. That's something that I never understood, it's a great model for containment, and reuse.
The main difference between OS X and iOS is that on an iOS device you have only one "window". On OS X there are desktops that can contain many windows that you can view and interact with at the same time.
In general, it sounds like you are trying to create an NSWindow that contains a single-column NSTableView for your list of choices on the left, and some other view that will display the detail of the selection on the right. It's common to place these within a vertical NSSplitView so the user can adjust their relative widths, but they could also stand on their own, as two separate subviews within the window's main view.
You typically use an NSArrayController to manage the list contents and track which particular item is selected. For your detail view on the right, you would use a single NSView with NSControl subviews that display values bound to the array controller's selected object.
If the data structure varies among your objects, swap in or show/hide various subviews as needed for the different types of data the particular selected object represents. You can use the "Conditionally Sets Hidden" binding option to automatically hide controls for which there is no applicable keyed value.
Alternatively, if there's a fixed number of objects in your list and their structures are all quite different from one another, then you may wish to use a tabless NSTabView that has a separate tab with its own custom view for each of your objects. Observe when the selection changes in your list, and select the appropriate tab accordingly.
Related
I have an app which allows users to send messages to each. The process is accomplished by saving the sent messages in a local SQLite database, while actually sending the messages to a database and using push notifications to send the message to the recipient's SQLite database. The set up I have works fine. However, what I am confused about is how to set up the actual interactive UI for the user (I am using XCode). I figured it should be a UITableView with each table cell representing a message. However, with this approach I run into a few requirements:
Variable TextView Sizes
Just as with regular iOS messaging, the TextView's size needs to be variable, adjusting its dimensions to fit all of the text in each message. I do not know how to accomplish this. I have a general understanding of how to generally vary sizes, but no clue how to dynamically have it based on the text within that view.
Variable TextView Positions
Again, just as with regular iOS messaging, the textview needs to be offset to either the right or left side depending on whether the sender was the user or who the are conversing with, respectively. I also do not know how to do this, because it changes the center of the textview.
Non-selectability
Xcode allows cells to be pressed. Handling what happens after this selection can be achieved by the didSelectRowatIndexPath tableView function. I can simply not implement this, but clicking on the cell causes it to turn darker to indicate it has been pressed. I would like to eliminate this while retaining the ability to, say, select some of the text and copy and paste it or whatever (just like messaging works normally on your phone).
Other Approaches?
This is the real meat of the question. I have considered the above approach because that is all that I have been able to come up with based on my limited experience with XCode UI elements. If there is a better approach (perhaps even a pod or framework) for this purpose I would love to hear it. I do not need the messaging UI to look amazing, just clean and crisp.
I suggest the following:
Variable TextView Sizes:
I assume you do use auto layout. If you don’t yet, please consider using it since it make life much easier!
If you use a UITableView, you can adjust the height of its UITableViewCells dynamically, depending on the actual content by using self-sizing cells. You can find a tutorial how to do this here.
Variable TextView Positions:
I assume you have a UITextView within a table view cell. In this case, you have to set auto layout constraints to the borders of the cell’s contentView. If you define a custom subclass of a UITableViewCell, you can define in this class 2 IBOutlet properties that are linked to say the left and the right layout constraints (e.g. var leftLayoutConstraint: NSLayoutConstraint). Then, you can set the constraint’s constant property as required when the cell is laid out, i.e. in the layoutSubviews function of the custom table view cell.
Non-selectability:
I am not sure what you mean by „I can simply not implement this“. Please make sure that you set the delegate property of the UITableView to the view controller where you want to handle cell selection. Selecting a cell changes the cells color by default, but you can change this: In the storyboard, select your table view’s prototype cell, and open Xcode’s utility pane (top rightmost button). Under „Table view cell“ you find „Selection“ that you can set to „None“.
I hope this helps!
Several places in OS X (in this example, the Users & Groups pane in System Preferences) have circular image views that allow the user to either drag in an image, like in an editable NSImageView but also allow them to click to show a popover that allows various other choices of image sources.
I have checked the ImageKit framework, but the only thing I found similar is the image taking sheet.
How can I make use of this feature in my own Cocoa applications? I'd imagine it is implemented in some standard framework—but any pointers on implementing something like this would be quite appreciated.
You will have to go down the custom control root as this is not available as a stand alone control.
However you have all the prerequisites.
The circular image view
There a several ways to implement this. You could try using a standard Cocoa button and customise as needed. Although it might just be easier to build from scratch by subclassing NSView. This was you can avoid all the NSCell stuff. I would do the latter.
The popover
Roll your own master-details type view controller to be displayed as the popover's content. In the left have a NSTableView (the master), the right have a NSCollectionView (the details). Below the collection view add some buttons.
I’ve been reading through several books on Mac development, but cannot find the information I’m looking for.
The books all describe how to make floating windows or panes, but never mention how to make them all in one window. A simplified example of what I’m looking to create is shown below:
Basically, there will be three windows; A selector window with radio buttons to choose which NSDocument is currently being used, a window underneath that with buttons that show different windows to the right that allow viewing and manipulation of certain data.
For a example, each NSDocument may have a color value that can be set in the window shown by clicking view A, and some text strings that can be set in the window shown by clicking view B.
So the questions are:
Is it appropriate to use a single NSDocument sub-class for each Doc #1 and Doc #2?
Which classes should I use to set up the application as shown? NSWindowController? NSWindow? NSPanel?
I’m only looking for guidance on what to read up on, so any pointers are appreciated.
EDIT:
To clarify this further, I want to have a table view where the buttons are (View A & B), and by clicking them they will cause the other window/view to change it's contents.
It's like the split view in the iPad settings application, there is a table view on the left, and when it's pressed the right side changes.
The radio buttons are there only to illustrate that I want more than one Document. I'm guessing I need more than one to handle this? Or perhaps I should place them all in a single NSDocument? Somehow that doesn't seem right.
To achieve what you want you need one window (NSWindow), one window controller and various views each with their own view controller. There are several ways you could set this up, all depending on your requirements:
You'd have at least 3 views (instances of NSView): one for the selection of the document class, one for the view selection and one for the content. Each view is controlled by a view controller (instance of NSViewController). Additionally you can opt to wrap the views in split views (NSSplitView) so your user can resize the real estate available to each view.
You have one window with a window controller. If you choose a Document based app template in Xcode, Xcode will generate a subclass of NSDocument which you can use as your window controller (or choose to use Core Data and Xcode will generate a subclass of NSPersistentDocument with all bells and whistles you need to access Core Data for document persistency).
So to come back to your questions:
1: Yes, but depending on your requirements. If Doc #1 is a completely different thing than Doc #2 than you might need to re-evaluate. For example Doc #1 might have completely different persistent requirements than #2.
2: There's no single scenario here, but one that worked for me: Take the project template for a document based app (with or without Core Data). Use the generated subclass of NSDocument (or NSPersistentDocument) as your window controller. Use NSView to implement the views in your window where each view is managed by its own controller, which is an instance of NSViewController.
I know this is an old question, but a way to do it how you want would be to use: ContainerViews and set their embed segue to be the view controllers you want.
I've a window that will have an unknown amount of text fields, determined by the content of a remote server.
In high level terms, how should I go about this? Create a custom view or create an empty window with a backing NSWindowController and then add stuff to it when the window is opened?
I've seen the examples on the O'Reilly Cocoa book and those effectively create a custom NSView. Is this the right way to do it, 8 year later?
You probably want an NSMatrix. A NSMatrix allows you to create an arbitrarily large grid of cells.
Tables, outlines, browser etc are also options depending on your specific needs.
I am learning Cocoa and trying to create an application for Mac that displays a simple book list. Each book is an NSView with its cover image, title and author. I want to present this list as a NSTableView with a single column and a book view in each cell. However i can't yet figure out how to display a custom view inside a table cell in interface builder or programmatically. Any tips would be very appreciated :)
Inso.
If all of your "book views" are the same size, why not use NSCollectionView / NSCollectionViewItem? It's a much cleaner solution (provided they're all sized the same).
Assuming a collection view wouldn't be a better solution, what you need to do is to write a custom cell. The column owns exactly one such cell, which the table view will use to draw the column's value for each row.
(If you came from the iPhone, yes, this is completely different from UITableView. Each NSTableColumn has exactly one cell, which it uses for every row.)
If you're using your NSView class somewhere else, then you could make it into a subclass of NSControl and have it use another instance of the same cell class. Like most controls, all the real work would be done by the cell, which enables you to reuse that behavior in multiple controls (your single control and your table view).
See Control and Cell Programming Topics for more info.
Apple added view-based table views in Lion, so you should be able do this natively with NSTableView, now.
(You still can't put an NSView in an NSCell—that wouldn't make sense. But you can have views instead of cells in a table view.)