Since I've learned Objective C I've only used the SpriteKit project template. I've had a tiny bit of exposure to iOS development and I'm looking to use AppKit elements (buttons, etc) in an OS X SpriteKit project for menu creation, overlays or having more flexibility in terms of placing items on the screen. Is this possible and if so, how? Would it be something along the lines of layering views (NSView overtop of an SKView) or something like that?
It's basically the same as iOS. You can use NSWindowController and NSViewController to hold an SKView and place elements above the view.
In my case I actually just ended up using Sprite Kit for all of the UI because I didn't want to have to mange two separate interfaces.
I recommend that you don't use the Sprite Kit template but instead use the default Cocoa App Template because it uses newer interface technologies that will make designing your interface easier and more similar to iOS.
Related
I'm building an NSView that is a kind of collection view, but instead of a table or a grid it will be a graph editor (similar to quartz composer).
The problem I'm facing now is that I would like to load prototype views (for the nodes) from a xib file. Much like how UITableView and UICollectionView lets you design prototype cells in Interface Builder. But how are these objects then instantiated in multiple copies?
How does UITableViewController et. al. achieve this?
Solutions I have thought about:
Copy the view, but NSView does not support NSCopying "out of the box". This seems like the most logical so far. It also seems like the only option if you want to keep the NSView in a storyboard rather than a xib.
Load a nib and then send [nib instantiateNibWithOwner:self topLevelObjects:nil] multiple times.
NSView does support NSCoding but using that feels more like a hack.
Any more ideas?
I'm developing an Mac OS X app, not an iOS app.
You are correct, implementing NSCopying via NSCoding does feel like a hack, but it's prob'ly the quickest and most reliable way to code it.
Copy NSView in cocoa / objective-c "related copy/code answer"
You can put your view in the storyboard as a top level object of any given scene. Make sure you have an outlet to it from the controller/loader of that scene. You could likely pack it into an NSData and just hold on to that for each "copy" you want made/unarchived.
What's the best method to implement swiping between views in OS X? These views are initialized from nibs with their view controllers and they're the same class type. To give some background, each view displays relevant data for the current date.
I'd like to create a function that loads the data for the next (or previous) date. I could simply load the data into the current view, but can I do that with an animation that's similar to swiping between spaces in OS X? I imagine I'd have to initialize a new view, load the data there, and then initiate the swiping transition to the new view.
I'm worried that the performance of creating all these new views would be pretty bad. Here are some options I've considered to address this:
Create a dictionary of NSDate to MYViewController. Load and store each view from this hashmap, but this could take a lot of memory.
Create a doubly-linked list of MYViewController and load/store sequentially dated views. This could potentially take a lot of memory also and if the user jumps to a date, the caching would just be erased.
Any thoughts? If there's some way to load the data in the current view, I feel like that'd be the best option.
Thanks!
Have you considered just simply using UIScrollView and having a single UIViewController to manage all the views? Here's a good tutorial from Ray Wenderlich's site on UIScrollView :
http://www.raywenderlich.com/10518/how-to-use-uiscrollview-to-scroll-and-zoom-content
Alternatively, have you considered possibly using horizontal table view? Here's a third party implementation, which I've seen recommended on other SO posts:
https://github.com/TheVole/HorizontalTable
Edit
Sorry, I quickly read your question and assumed it was for iOS...
I think you might be looking for something like NSCollectionView perhaps (not sure if this would support offscreen views in a horizontal manner well or not...?)
Here's the docs on it:
https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/NSCollectionView_Class/Introduction/Introduction.html
Here's a tutorial on it:
http://andrehoffmann.wordpress.com/2009/08/29/nscollectionview-tutorial-for-dummies-xcode-3-1-3/
(Honestly haven't done much OSX development, so a bit out of my area of expertise here... I wish you luck though!)
Cocoa view transition animation is not an easy thing. This is much more complicated coding than view controller management.
You need to decide how to achieve the desired effects. Take a look this document and other references: Animation Programming Guide for Cocoa
I did similar work a few months ago. My final resolution was using single view and show animation effects only with graphics APIs (image drawing) because it was more simpler than Core Animation.
I am coming from iOS background and starting to learn Cocoa. On iOS unless we have multiple targets for iPad and iPhone we usually have one Window and manage the screen using UIViewControllers. Where every new screen will most of the time will map to a UIViewController.
However on cocoa this seems to be the otherway around where a new screen/window is manage by NSWindow and it's subcomponents are managed by NSViewController. So if I have multiple window app I should have separate NSWindowController for each window.
Is this approach correct or am I having a misunderstanding ?
With iPhone SDK and Leopard SDK, they introduced view controllers, or NSViewController and UIViewController. As their names suggest what they do is to manage views
The view controllers are for managing views. Current trend in UI design is Single Window, Multiple View. What it means is that there is one Window and inside of it, different group of views designed for different purpose can be swapped in and out. So, the View Controllers handles these for programmers for well-established pattern.
Currently view controllers are very important for iPhone and iPod touch programming, because the platform is based on Single-Window and Multiple View model. However, it doesn’t seem to me that using view controller is very popular for Mac.
how about the window controller like NSWindowController? Its counterpart, UIWindowController doesn’t exist for the iPhone and iPod touch environment, because there is only one window for those environment.
Unlike view controllers, the NSWindowController is for document based programs. Well, document based program can use multiple window. So, it is reasonable to think that NSWindowController is for document based programs as Apple’s document says.
I also come from iOS and started coding Mac apps a while ago, learning mostly from Apple's documentation.
My impression is that on the desktop, you almost never need NSViewControllers (one big exception would be a window with tabs and multiple views, like the GarageBand welcome screen).
Most of the time you have one NSWindowController per window. Learn first the relation between NSWindow and NSWindowController (and NSDocument, if you are making a document-based app).
Once you got that right, start experimenting with NSViewController.
UPDATE: It seems that since the introduction of storyboards for mac apps too, Apple expects that most of the view presentation logic should be migrated from the older NSWindowController to the newer NSViewController, more in line with how an iOS app is structured. I am not very knowledgeable on exactly where to draw the line, or what kind of code should remain in the window controller (or whether it still needs to be subclassed at all).
A Window Controller creates a traditional window and has all the traditional APIs.
A View Controller can also be shown outside of another view. It then gets a window frame but does not support the full traditional Window Controller API.
In addition to custom, modal, and show, a View Controller can also be presented in the modes sheet and popover.
So, View Controller has more presentation options and a more streamlined API but probably a few limitations in cases that are covered by the traditional Window Controller.
When I am programming a universal app, lets say I have an IBAction like so:
(IBAction)magicCode:(id)sender {
textField1.text = "TEST";
}
Do I need to create a new IBAction for each view (iPad and iPhone). I can't have textField1 twice in header file, so I am just wondering how everyone else does this. Do I need to put a textfield in the iPhone app with a different name than the one in the iPad app? Or is there some other way everyone else is doing this?
Do I need to create a new IBAction for each view (iPad and iPhone).
First, actions are typically included in view controllers, not views. I think that's probably what you meant, but I point out the difference because I've seen a lot of people get confused on this point.
When you're creating a universal app, i.e. a single app that adapts its UI to the device (iPad or iPhone/iPod Touch) on which it's running, a common strategy is to provide different view layouts that make the best use of the available screen size, but to use the same view controllers. So, for example, say you have an app with a master/detail interface. On small devices, you'd present the master part of the interface first, and when the user chooses something you'd display the detail part of the interface. On an iPad, with it's larger screen, you'd display both master and detail interfaces simultaneously in a split view. Comparing the two, the views are likely to be different, and the way the view controllers are presented is different, but the view controllers themselves should stay the same. This is a good thing, since much of the work of creating an app goes into creating the view controllers.
If your app is similar to what I've described (or if you can make it similar), then no, you don't need separate actions for iPad and iPhone because you'll be using the same view controllers in both cases. There may be times, though, when the behavior of the app on the two different devices is different enough that it makes sense to have iPad-specific and iPhone-specific view controllers. You might still be able to use the same actions by deriving each of those from a common parent class that contains the actions. If not, you'll need to have each class implement its own actions.
No, you can have the same IBAction and IBOutlet in a UIViewController dealing with textfields in two different Nibs (one for iPhone and one for iPad). That's the whole point of separation between View Controller and Views in MVC architecture.
Just use the same UIViewController as File's Owner in both the Nibs and make all the appropriate IBOutlet and IBAction connections and everything will work.
Does anybody know of any XCode extensions or ways to create the Split View based application seen in Cocoa Touch in Cocoa for use in a Mac application?
Examples I've seen are "Reeder for mac" and the latest Twitter Application in the App Store.
Any help is greatly appreciated, thanks
Cocoa has an NSSplitView class which can be used in Interface Builder, and you can always create custom split views or use open source ones such as RBSplitView or the one available in BWToolkit.
What additional functionality are you looking for that isn't provided by the already-available NSSplitView?
Reeder for Mac seems to use a simple NSSplitView with 3 subviews. (To create a split view with 3 views, drag the usual NSSplitView into a window or view in InterfaceBuilder, then drag an additional NSView into the NSSplitView in the "Outline Mode" of your IB document's window.)