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.
Related
I'm trying to create a view hierarchy similar to what you'd expect in a media playback viewer like the QuickTime Player:
+ Host View
+ Video Controls (NSView layer-backed)
+ Video View (NSView layer-hosted)
+ AVPlayerLayer
Since layer-hosted views cannot contain subviews, the video controls view is a sibling of the video view and simply ordered-front so that it's on top of the video view.
This current view hierarchy appears to be working fine for me, but I remain a bit confused over whether it's officially "supported" because of the overlapping, sibling views (the video controls view always overlaps the video view).
This Stack Overflow question: Is there a proper way to handle overlapping NSView siblings? offers conflicting information regarding overlapping sibling views.
I would assume the more 'correct' way to handle this is for the video controls to be a subview of the video view, which is only possible of I change the video view from being a layer-hosted view to a layer-backed view.
By default a layer-backed view uses a basic CALayer as its backing store, but NSView exposes makeBackingLayer to allow you to return a custom layer such as an AVPlayerLayer.
By doing that, and moving the controls view to be a subview of this layer-backed video view, things also appear to work properly but now there's an AVPlayer object that is directly modifying the contents of the AVPlayerLayer. That seems to be contrary to the requirement that in a layer-backed view, you should never modify the contents of the layer without going through the NSView using something like drawRect or updateLayer.
This seems to leave me with two choices, neither of which appears 'correct' based on my interpretation of the document:
Option 1:
Layer-hosted view for the AVPlayerLayer
Overlapping sibling view for the controls view.
Option 2:
Layer-back view with an AVPlayerLayer via makeBackingLayer
AVPlayer that directly modifies the contents of the AVPlayerLayer
Controls view as a subview of the video view
I'm inclined to think that option #2 is the more correct way and that in this scenario, it's OK for the AVPlayer to directly modify the contents of the AVPlayerLayer even though it's in a layer-backed view, but I'm not certain and would be curious if others have any thoughts or experiences with a setup like this.
Apple has some old (ancient in computer terms, 2007!) code that doesn't even compile in Xcode 6 without some tweaks. It shows some controls that are overlaying a QuickTime movie layer. Download it here: https://developer.apple.com/library/mac/samplecode/CoreAnimationQuickTimeLayer/Introduction/Intro.html .
It's hard to say that just because they provided source code that it's considered a best practice, but I would suggest you just build it the way you think is best. This is not one of those areas so heavily developed on that a best practice is likely to exist. For me personally it makes the most sense to use overlapping sibling views as to ensure that you don't mess with the video rendering. Whether that's the right way or not is probably somewhat subjective. You can maybe access one of the old quicktime developers mailing lists or even ask on the Apple developer forums. At the end of the day though you should probably just stick with the method that makes the most sense to you since you're likely to be the one to maintain or build upon it in the future.
I'm just getting into desktop Cocoa development (I have experience with iOS development). If this question seems basic, forgive me.
That being said, I'm dealing with a large program with lots of calculations and functionality to deal with. There are almost a dozen views, organized with an NSTabView. Rather than dumping everything into one monstrosity of a class and creating a XIB file that brings my system to its knees (Xcode apparently isn't that efficient…who knew? :P). I'd like for each tab to be its own NSViewController with accompanying XIB; as such, I'd like to load each tab's view from the corresponding XIB.
I'm thinking of this in terms of UITabBarController, but this doesn't seem to work (there isn't an NSTabViewController as far as I could find). I'm not sure how to do this (or even if it's possible—but I can't be the only one with this issue?), and I'd appreciate any assistance. Thanks!
Update: I tried assigning the controller's view to the tab's view, but quickly realized that wouldn't get me anywhere. Is it worth creating an NSTabViewController from scratch, or is there a solution out there?
Cocoa development on the desktop has some major differences compared to iOS development. One of them is the use of view controllers - they aren't strictly necessary - and when you use them you can just stick to a generic NSViewController regardless of what kind of view it contains. All of the methods you need to control the tab view are in the NSTabView class - not the controller.
Having said that, putting 12 views in to a tabview sounds like a painful way to interact with a program. Have you thought about a source-detail type setup (think itunes or mail with their sidebars - each entry in the sidebar corresponds to a different view)?
I've ditched the tab bar, and as per sosborn's suggestion, I have used a split view—or rather I've put a table view on the side, and a custom view taking up most of the screen. Then, in my AppDelegate, I have individual controllers as ivars (I need individual controllers because there are a lot of calculations involved, and I don't want to have a monster class handling them all). They'll be lazily loaded, and the view will be assigned to the current controller's view as necessary.
Summary
From a conceptual point of view, should one be working with UIViewController subclasses and their Nibs, even if you're not using the UINavigationController?
Scenario
The application I'm trying to develop has no UINavigationController. I'm mostly looking at elements in one particular UIScrollView implementation, and if there's at all a 'next level of navigation', it merely alters the appearance of a small element to show more details. The detail views of the elements (different elements spawn different views) are laid out in Interface Builder, for which I opted to create new UIViewController subclasses with corresponding XIB files.
Doubt
While exploring the different ways I could have these instances animate into view, I come across a lot of solutions using the UINavigationController. The UIViewController itself already seems to be geared towards the synergy. There's a self.navigationController, and lot's of examples online of how to push and pop with and without animation.
Question
So what I'm wondering right now is "did I do the right thing?" Googling an answer to that question only brought me to more specific implementation examples, so I decided to post this.
Should I have restrained myself in using XCode's "new file" template for UIViewController subclasses with XIB? Or should I have implemented a UINavigationController in my app, even if there's no screenfulls of navigation going on?
I'd be much obliged for enlightenment.
Cheers,
Eric-Paul.
UIViewController is a useful tool. It offers memory management things, anchor points for interface rotation and lots more. If needed, they can be pushed to a navigation controller (if not now, maybe later), could be a page of a tab bar controller, or behave well in popovers on iPad.
They come cheap and I don't see a reason not to use them. And your code needs to go somewhere anyway. Don't flood the application delegate or the view.
I'm trying to create an iPhone app with a welcome screen that leads to two or three pretty disparate UIs; once you've drilled into one you're not going to have much use for the others, and each one is itself fairly complicated.
The designers are all web types and it looks like the "navigation" paradigm is the closest to what they want, but the breadcrumb-style navigation bar isn't.
If I set up a UINavigationController, can I then drive it with arbitrary buttons in the views?
And in general, is it possible to swap out the contents of a view programmatically?
And if so, what do I need to watch out for? (E.g., in Java if you change the contents of a JPanel you need to make sure it gets revalidated and repainted.)
Total iOS newbie here, coming from the Java world, super-explicit advice much appreciated. Using Monotouch, but happy to take Obj-C help and translate. :)
It's hard to tell you how to design your app with only that information, so I'll assume you want to do a drill-down thing like a UINavigation controller.
1- Yes, you can drive the UINavigationController from other ViewControllers, using methods like PushViewController() and PopViewController(). You can also hide the toolbar or some of the toolbar buttons if you want. You can find some great examples here.
2- Yes, you can change contents of a view. Views contains other views and you can add and remove them as you want.
3- The main thing to be careful about is to make sure that calls that update the view are done inside a InvokeOnMainThread(()=>{}) call. More info here.
I'm looking for some kind of a basic, straightforward example of how to work with a pair of NSScrollers in an NSScrollView with a custom NSView.
There are sporadic examples out there, largely consisting of contrived examples using programatically created interfaces, or based on the assumption that the developer is working with a typical ImageView or TextView. Even the Sketch example is based on an NSView that uses the Page Setup in the Print dialog for the bounds, and everything is managed by Cocoa. So there's no real discussion or examples anywhere of how make it all work using a custom Model (though that may be part of the problem, because what does one base the Model on?). Even Apple's own documentation is dodgy here.
Essentially, I have a sub-classed NSView enbedded in an NSScrollView (per the Scoll View Guide), that a user can click in the view to create, edit and delete objects, much like an illustration program. The Model is those objects that are just data wrappers that simply record their position for drawRect: to use. The height and width are based on custom values that are being translated into pixels as needed.
My problem is that all of the examples I have found are based on either a text editor, an image viewer, or uses the standard document sizes in the Page Setup dialog. Because these are common document types, Cocoa basically manages for the developer, so the interaction code is more or less hidden (or I'm just not seeing it for what it is). My project doesn't fit any of those needs, and I have no need for printing. Thrusting my Model into the documentView property wouldn't work.
I'm just looking for a simple example on how to initialize the NSScrollers with a custom, object-oriented Model (the documentView), and handle scrolling and updating based on user action, such as when the user drags a smattering of objects off to the left or down or the window gets resized. I think I'm close to getting it all together, but I'm missing the jumping off point that ties the controls to document.
(Not that it matters in a Cocoa question, but when I did this in REALbasic, I would simply calculate and apply the MaxX, MaxY to a ScrollBar's Maximum value based on user actions, watch the position in the ScrollBar when the user clicks, and draw as needed. NSScrollers in the NSScrollView context aren't nearly as obvious to me, it seems.)
I appreciate the time taken by everyone, but I'm updating with more information in the hopes of getting an answer I can use. I'm sorry, but none of this is making sense, Apple's documents are obtuse, but perhaps I'm missing something painfully obvious here...
I have an array of objects sitting in a subclassed NSDocument which are data holders that tell drawRect what and where to draw. This is straight from the Sketch example. The Sketch example uses the document sizes in the Page Setup dialog for the size, so there's nothing to show here. I'm cool with Cocoa handling the state of the scroll bars, but how do I link up the ScrollView to see the initial editor's state held in the NSDocument and updates to those objects and the editor? Do I calculate my own NSRect and pass that to the NSScrollView? Where and how? Am I doing this in my custom NSView which has been embedded in the NSScrollView or my NSDocument in init? The NSScrollView isn't created programmatically (there's no easy way of doing that), so it's all sitting in Interface Builder waiting to be hooked up. I'm missing the hook up bit.
Perhaps I'm wearing my "I don't get it" cap this week, but this can't be this difficult. Illustration apps, MIDI Editors, and countless other similar custom apps do this all the time.
SOLVED (mostly):
I think I have this sorted out now, though it's probably not the best implementation.
My document class now has a NSRect DocumentRect property that looks at all of its objects and gives back a new NSRect based on their location. I call it in my subclassed NSView's mouse events with
[self setFrame:[[self EditorDocument] DocumentRect]];
This updates the size of the View based on user interaction, and the window now handles the scrolling where it didn't before. At this point I'm figuring out how to get the frame to expand while dragging, but at least I now have the fundamental concept I was missing.
The answer given pointed me in the direction I needed to go here (documentView requiring a view, which translated to looking at the NSView class), so Peter gets the credit. Thanks so much for help.
The document view isn't a model, it's a view. That's why it's called the document view.
The reason there are so few examples on working with NSScrollers directly is because you normally don't. You work with NSScrollView and let it handle the scrollers for you.
All you need to do is make a view big enough to show the entire model, then set that as the document view of the scroll view. From there, it should Just Work. You don't need to manage any of the scrolling-related numbers yourself; Cocoa handles them for you.
For details, see the Scroll View Programming Guide.