I have an UIViewController subclass and an IBOutlet named map to an MKMapView instance.
So far, so great, but sometimes the app crashes without a reason when the view controller triggers the viewDidLoad method. This is absolutely randomly, but only happens when I created around three instances and then create a new one and push it into a navigation controller (however, I have only one of these view controllers at the same time in the navigation controller stack!).
Here is the code of the viewDidLoad method:
- (void)viewDidLoad
{
[super viewDidLoad];
[map setDelegate:self];
[map setMapType:MKMapTypeStandard];
[map setShowsUserLocation:YES];
if(area)
self.area = area;
}
The stacktrace shows that it crashes when I call [map setShowsUserLocation:YES]; but only on this line (when I comment it out, it never crashes). Here is the stacktrace:
(Sorry for the picture, but I was too lazy to type it all).
Does anyone knows what happens there an why it crashes?
Try setting [map setShowsUserLocation:NO]; in your viewDidUnload. I have a similar situation, but I recreate the MKMapView programmatically every time the view reloads, and haven't seen this problem.
Related
I've got plenty of experience with iOS, but Cocoa has me a bit confused. I read through several Apple docs on Cocoa but there are still details that I could not find anywhere. It seems the documentation was written before the NSDocument-based Xcode template was updated to use NSViewController, so I am not clear on how exactly I should organize my application. The template creates a storyboard with an NSWindow, NSViewController.
My understanding is that I should probably subclass NSWindowController or NSWindow to have a reference to my model object, and set that in makeWindowControllers(). But if I'd like to make use of the NSViewController instead of just putting everything in the window, I would also need to access my model there somehow too. I notice there is something called a representedObject in my view controller which seems like it's meant to hold some model object (to then be cast), but it's always nil. How does this get set?
I'm finding it hard to properly formulate this question, but I guess what I'm asking is:how do I properly use NSViewController in my document-based application?
PS: I understand that NSWindowController is generally meant to managing multiple windows that act on one document, so presumably if I only need one window then I don't need an NSWindowController. However, requirements might change and having using NSWindowController may be better in the long run, right?
I haven't dived into storyboards but here is how it works:
If your app has to support 10.9 and lower create custom of subclass NSWindowController
Put code like this into NSDocument subclass
- (void)makeWindowControllers
{
CustomWindowController *controller = [[CustomWindowController alloc] init];
[self addWindowController:controller];
}
If your app has multiple windows than add them here or somewhere else (loaded on demand) but do not forget to add it to array of document windowscontroller (addWindowController:)
If you create them but you don't want to show all the windows then override
- (void)showWindows
{
[controller showWindow:nil]
}
You can anytime access you model in your window controller
- (CustomDocument *)document
{
return [self document];
}
Use bindings in your window controller (windowcontroller subclass + document in the keypath which is a property of window controller)
[self.textView bind:#"editable"
toObject:self withKeyPath:#"document.readOnly"
options:#{NSValueTransformerNameBindingOption : NSNegateBooleanTransformerName}];
In contrast to iOS most of the views are on screen so you have to rely on patterns: Delegation, Notification, Events (responder chain) and of course MVC.
10.10 Yosemite Changes:
NSViewController starting from 10.10 is automatically added to responder chain (generally target of the action is unknown | NSApp sendAction:to:from:)
and all the delegates such as viewDidLoad... familiar from iOS are finally implemented. This means that I don't see big benefit of subclassing NSWindowCotroller anymore.
NSDocument subclass is mandatory and NSViewController is sufficient.
You can anytime access you data in your view controller
- (CustomDocument *)document
{
return (CustomDocument *)[[NSDocumentController sharedDocumentController] documentForWindow:[[self view] window]];
//doesn't work if you do template approach
//NSWindowController *controller = [[[self view] window] windowController];
//CustomDocument *document = [controller document];
}
If you do like this (conforming to KVC/KVO) you can do binding as written above.
Tips:
Correctly implement UNDO for your model objects in Document e.g. or shamefully call updateChangeCount:
[[self.undoManager prepareWithInvocationTarget:self] deleteRowsAtIndexes:insertedIndexes];
Do not put code related to views/windows into your Document
Split your app into multiple NSViewControllers e.g.
- (void)prepareForSegue:(NSStoryboardSegue *)segue sender:(id)sender {
if ([segue.identifier isEqualToString:AAPLListWindowControllerShowAddItemViewControllerSegueIdentifier]) {
AAPLListViewController *listViewController = (AAPLListViewController *)self.window.contentViewController;
AAPLAddItemViewController *addItemViewController = segue.destinationController;
addItemViewController.delegate = listViewController;
}
}
Previous code is called on windowcontroller with viewcontroller as delegate (again possible only after 10.10)
I always prefer to use multiple XIBs rather than one giant storyboard/XIB. Use following subclass of NSViewController and always inherit from it:
#import <Cocoa/Cocoa.h>
#interface MyViewController : NSViewController
#property(strong) IBOutlet NSView *viewToSubstitute;
#end
#import "MyViewController.h"
#interface MyViewController ()
#end
#implementation MyViewController
- (void)awakeFromNib
{
NSView *view = [self viewToSubstitute];
if (view) {
[self setViewToSubstitute:nil];
[[self view] setFrame:[view frame]];
[[self view] setAutoresizingMask:[view autoresizingMask]];
[[view superview] replaceSubview:view with:[self view]];
}
}
#end
Add a subclass of MyViewController to the project with XIB. Rename the XIB
Add NSViewController Object to the XIB and change its subclass name
Change the loading XIB name to name from step 1
Link view to substitute to the view you want to replace
Check example project Example Multi XIB project
Inspire yourself by shapeart or lister or TextEdit
And a real guide is to use Hopper and see how other apps are done.
PS: You can add your views/viewcontroller into responder chain manually.
PS2: If you are beginner don't over-architect. Be happy with the fact that your app works.
I'm relatively new to this myself but hopefully I can add a little insight.
You can use the view controllers much as you would in ios. You can set outlets and targets and such. For NSDocument-based apps you can use a view controller or the window controller but I think for most applications you'll end up using both with most of the logic being in the view controller. Put the logic wherever it makes the most sense. For example, if your nsdocument can have multiple window types then use the view controller for logic specific to each type and the window controller for logic that applies to all the types.
The representedObject property is primarily associated with Cocoa bindings. While I am beginning to become familiar with bindings I don't have enough background to go into detail here. But a search through the bindings programming guide might be helpful. In general bindings can take the place of a lot of data source code you would need to write on ios. When it works it's magical. When it doesn't work it's like debugging magic. It can be a challenge to see where things went wrong.
Let me add a simple copy-pastable sample for the short answer category;
In your NSDocument subclass, send self to the represented object of your view controller when you are called to makeWindowControllers:
- (void) makeWindowControllers
{
NSStoryboard* storyboard = [NSStoryboard storyboardWithName: #"My Story Board" bundle: nil];
NSWindowController* windowController = [storyboard instantiateControllerWithIdentifier: #"My Document Window Controller"];
MyViewController* myController = (id) windowController.contentViewController;
[self addWindowController: windowController];
myController.representedObject = self;
}
In you MyViewController subclass of NSViewController, overwrite setRepresentedObject to trap it's value, send it to super and then make a call to refresh your view:
- (void) setRepresentedObject: (id) representedObject
{
super.representedObject = representedObject;
[self myUpdateWindowUIFromContent];
}
Merci, bonsoir, you're done.
I'm missing something fundamental about NSView. I have a Cocoa Application with an Objective C class named DataSource that is just a regular class, it's not in the nib. The data source has a single instance variable, an NSColor *, and it has a getter and setter.
The view class instantiates the DataSource in awakeFromNib:
- (void)awakeFromNib{
NSLog(#"awakeFromNib");
ds = [[DataSource alloc] init];
}
and then queries the DataSource for the color to use in drawRect. It works fine. I also implement
- (void)mouseDown:(NSEvent *) anEvent;
in the view class, change the color of the DataSource, and then call
[self setNeedsDisplay:YES];
and it also works as I expect when I click in the custom view.
But if I hook up a button in the nib, wired to this IBAction in the view class:
- (IBAction)buttonPushed:(id) sender {
NSLog(#"buttonPushed");
[ds setData:[NSColor cyanColor]];
[self setNeedsDisplay:YES];
}
the data source updates, but drawRect is never called, despite setNeedsDisplay. In my more complicated version, if I click in the view (in a way that doesn't change the color), I will then get the update (caused by the button). Something is delaying drawing. How can I fix this?
Update: There is no controller and there are no outlets. The NSView subclass contains buttonPushed. The data source updates immediately upon button push, but drawing is delayed, despite calling setNeedsDisplay:YES from the view class. Drawing is delayed indefinitely, unless something else happens to trigger it.
Where is the IBAction located? Are you using some view controller? Is the NSView an outlet in that controller?
I am having a really weird issue when testing on my 1st gen. iPad (running iOS 5).
I have a UIView that I use as a property (with retain). I nil the property in the parent view's dealloc method. Pretty basic stuff. It works perfect on my iPad 3 running iOS 6, but doesn't get released on my 1st gen.
Any ideas what might be going on?
I'm not using ARC.
If you're retaining it, you have to release it. You can't just nil the instance variable.
So if you're property looks like this:
#property (nonatomic, retain) UIView *myView;
You're dealloc would either look like this:
- (void)dealloc
{
[myView release], myView = nil;
[super dealloc];
}
Or this:
- (void)dealloc
{
[self setMyView:nil];
[super dealloc];
}
Or this:
- (void)dealloc
{
self.myView = nil;
[super dealloc];
}
And your property will properly get released--unless something else is retaining it.
So I figured this out. It seems to be a bug in the iOS 6 SDK or maybe I just don't understand it. I have a UIViewController that presents another vc via presentViewController:animated:completion: —If I dismiss the presented vc then it releases and subsequently all subviews are removed and all is well.
However, if while the presented vc is showing, I remove/destroy the parent vc, the presented vc is deallocated but, its subviews are not told to removeFromSuperview; This doesn't show up as a leak in instruments, BUT it does prevent the subviews from deallocating.
This does not happen on iOS 6, thus I suspect this is a bug in iOS 5. Everything releases/deallocates as one would expect on iOS 6.
If someone has an explanation, or a better understanding of this, I would love to reward the answer to them instead of myself.
A view controller isn't responsible for removing its view from the superview when the view controller is dealloc'ed. The view controller is just responsible for releasing its own reference to it.
For example: you can create a view controller, ask for its view, then add that view to another view and throw away the view controller. In that case, you're just using the view controller as a view builder.
I'm not sure why the behavior is different in iOS 6, but would love to know.
I'm using an NSViewController class with a single view in it to display a progress indicator bar and some text fields. I'm trying to use progressIndicator setMaxValue:and theTextField setStringValue: but neither of these are doing anything.
I've done this before and I've checked and rechecked, it's fairly straightforward, the fact that it's not working makes me think that it has to do with the fact that the class is NSViewController. Which is why I tried
Timers *aTimer = [[Timers alloc] init];
[aTimer.timerNameLabel setStringValue:#"name"];
[aTimer.progressIndicator setMaxValue:x];
in the app delegate which is an NSObject class, but that didn't work either.
I've tried looking around the NSViewController documentation but I can't find anything that says it can't set those values so I don't know what's happening. What am I doing wrong?
You probably want to use -initWithNibName:bundle: instead of a regular init to initialize your custom nib.
EDIT: It seemed the problem was due to the view not being queried before getting other objects. By calling [myController view] you actually load the nib, which isn't done automatically when you initialize the view controller. So before you can use any element of the view, you need to call [myController view]
I'm writing a Cocoa app. One dialog has 3 tabs, some of the tabs needs more loading time, so I want to load them lazily. Since each Tab is a NSTabViewItem class, so I'm trying to derive from it and overriding its view property. In the view getter method, I use a ViewController to load a view and returns out. In Debugging, I found NSTabViewItem -view method is get called correctly, but after that NSTabView tries to set Initial FirstResponder and crashed with message:
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'In -[NSTabViewItem setInitialFirstResponder:], the first responder must descend from the tab view item's view. (Item: Invalid responder: )'
I tried to override the -initialFirstResponder method to return a sub-view of my loaded view, but it still crashes the same place.
does anyone know how to get it work correctly? Also is it correct way to do this by deriving the NSTabViewItem?
thanks!
-Jonny
OK, I understand the exception now. The NSTabViewItem has its view, so I should use its view and add my new view as a subview, like:
-(NSView*)view {
NSView* view = [super view];
NSVIew* myView = //load view from nib
[view addSubView:myView];
return view;
}