I don't know what's the best way to deal with this problem:
I have some draggable buttons in an app that can be moved on top of some targets. If the button is on top of the right target, let's say button1 is on top of target1, the player/user gets a point. I thought the best way to deal with this would be to make a Target class with an "identifier" attribute and a Draggable class with a "targetID" attribute. When the Draggable object is released, I check whether it's on top of the right Target object by comparing their attributes.
It sounds easy but it hasn't been. I tried first to make Draggable a subclass of UIButton. As you might already know, that is not a good idea since UIButton returns an instance of a different class when [UIButton buttonWithType:] is called, eg. UIButtonTypeRoundedRect is returned. I can't use a category, since what I need is to have an extra attribute and as far a as I know categories can't add attributes to a class, only methods. Composition would make everything very complicated since I would have to "listen" for the button actions from the controller of Draggable. I will choose this alternative, though, if I don't come with a smarter option.
I might be overseeing something very obvious or I might don't know something absolutely basic. In that case, sorry! My iOS knowledge IS very basic.
UIButton is a kind of UIView, which has a tag property that you can use to mean anything you want. It's an NSInteger, but that should be useable for what you're trying to do.
Related
I have a simple design question (I know, no code, it's more about the mvvm pattern): my app shows a map, its viewmodel contains upper left and down-right coordinates.
If I want to move the view, I can change these coordinates.
But what if I want to animate this change ? Like in google earth. I know I can do a storyboard, animate the dependency properties and so on at the view level, but how would I say from the viewmodel "hey, start this storyboard with these target values" ?
The easiest solution would be to fire the event by setting a property bound to the view, but it would require a class that would be known from the view and the viewmodel.
Another would be to use a Mediator/Messenger, but I think it's more used to communicate between viewmodels.
I think there must be a cleaner way.
Thanks for any help.
I found a (rather complicated but consistent) answer from Josh Smith blog.
Here it is, for those who might be interested:
https://joshsmithonwpf.wordpress.com/2009/04/25/orchestrating-animated-transitions-between-view-and-viewmodel/
I am developing my first app for OSX. Sorry for asking stupid questions. I have spent a few hours trying to figure this out on my own, with no luck so far.
I want to make an iTunes-like interface. I used NSSplitView, placed NSView for navigation and NSTableView above that. [I am aware that there better alternatives to NSSplitView, yet my goal is to both - develop an app and also to learn Cocoa/OSX in the process.]
Atop NSView panel designated for navigation, I am trying to place NSTableView. However, my table is not being displayed. I therefore have questions...
I understand that for cells to be populated, controller must implement NSTableViewDataSource. I tried that, but was so far unsuccessful - to the point that I don't see the table. Please advise:
Can I have a working NSTableView-derived custom class also implementing NSTableViewDataSource? If this cannot work, please advise why or point me to an explanation.
Am I correct in thinking that all elements can be manipulated programmatically, in the sense that I use IBOutlet in headers to point to the right object, yet do nothing with InterfaceBuilder - have everything controlled from within my Objective-C code? Do I have to use IB?
Thank you.
Yes that will work but it's an unusual approach. Generally the tableview delegate/datasource is something enclosing the tableview. You'd normally only subclass NSTableView if you require some additional functionality not provided by default (for me that has been custom behaviour to input).
Yes you can do it all programmatically, however you will find it much easier to use IB. The IB-loaded views are created programmatically under the hood, using the information contained in the nib file. You will find it long-winded and tedious pretty quickly.
WRT to your issue with not seeing the table, you will need to add logging/breakpoints on the few key delegate/datasource methods to ensure they are being called (start with the daddy of them all numberOfRowsInTableView:). If they are not then you aren't setting the delegate/datasource correctly in the tableview.
I'm trying to set the text of the "Retake" and "Use" buttons on the PLUICameraViewController. I've programmatically navigated through the view hierarchy and found a few UIButtonLabel objects. Logging the text of these shows what I expect: "Retake", "Cancel" etc. However setting the text doesn't work. The buttons just keep their original text. Here's what I've tried:
if (q is a subclass of UIButtonLabel)
if ([q respondsToSelector:#selector(setText:)])
[q performSelector:#selector(setText:) withObject:#"zzz"];
The code runs w/o crashing. Also respondsToSelector is returning YES. How can I make the text on the buttons update?
By the way I'm aware of other approaches involving custom buttons, my own views etc. I'm really curious from an Objective-C/runtime/iOS perspective why the above code doesn't work.
Also note I'm doing this in
navigationController:willShowViewController:viewController:animated:
In this case, I don't think it's an issue of Private APIs, per se. This is just the way UIButton works.
Yes, the title of the button is a UILabel, and in practice, it is probably/currently an instance of the private class UIButtonLabel. But, the way Apple intends for you to change the title text is to use the methods in UIButton itself:
[self.button setTitle: #"newTitle" forState: UIControlStateNormal];
[self.button setTitle: #"newTitle" forState: UIControlStateSelected];
instead of trying to drill down into the button's subview heirarchy, find a button label, and call setText:.
Here's the relevant API documentation
As to why it doesn't work, I suppose that's because Apple wants it that way.
For one, changing a button's title is expected to be a normal use case. So, for convenience, they probably wanted to give you an easy method to call, directly in the UIButton interface. If they forced you do drill down into the view hierarchy, not only would you have to write more code, but it makes it a little harder for Apple to change the underlying implementation of a button. They may want to preserve the ability to change it later, and for that, it's better for them to keep some sort of wrapper APIs at the UIButton level.
Also, if you directly change the text on the button label, you are circumventing their design, where the label text depends on the button state (e.g. normal, highlighted, selected, etc.) Even though most people probably use the same button text for all states, the design allows for state-dependent text, and therefore, hiding the underlying UIButtonLabel helps enforce this design.
That's my guess as to their motivation.
So, to enforce this, it's entirely possible that in their implementation of UIButtonLabel setText:, they decline to update the text after the button has been initialized. After that, you have to use the setTitle:forState: method.
I have a question regarding best practices when adding targets to a UIButton on a custom view. Currently, I create my UIButton in a loadup method of my view, and assign my view as the buttons target. My view is handling logic when the button is pressed, and it occurs to me that this is not good MVC.
So, I'd rather have my controller provide itself as target and an action for the button, however I'm not sure the best way to accomplish this.
The view could be initialized with a reference to the controller, or could get the controller using UIResponder's nextresponder, and set the target with this reference. However, this could result in circular retains, and would require my view to be aware of the methods that exist on my controller, which is more tightly coupled than I'd prefer.
Alternatively, I could create a setter for each uibutton on my view. However, this quickly becomes unwieldy if I have several buttons, or a view that contains a custom subview with buttons. I could also create properties for each button, but that would also be unwieldy and allows the controller access to more than it needs (it just needs to set targets, it doesn't need to be able to get any reference to the button).
Finally, I could create and add targets to all my buttons within the controller, and pass it to the view on initialization, but that seems to violate the roles of MVC as well.
It seems as if this is a common scenario, are any of these practices considered standard, or is there a better solution?
My personal belief is that in Cocoa custom views are allowed to have logic and state needed for them to operate, but that they should fully encapsulate the logic and state. That is, you should expose an interface to subviews, but not the subviews themselves. You should expose any private properties or subviews through a combination of delegates and properties as well as custom actions.
That being said, given that you provided no specifics on the purpose of your custom view, it is difficult to provide specifics on the best approach.
It's proper to target the view that owns the buttons. This way, if you need to do any view manipulation (enable/disable, highlight, popup, etc) you're in the right place. Also, only the view will know what the button is, so that, in your action, if you want to check what is sender, you can do it. But having your controller know about each individual button would seem to be a more egregious violation of MVC.
It's not inappropriate to have an accessor for your buttons. It can be handy to have the reference around at runtime. If you don't use it, it's hard to argue that there's harm in keeping around an extra id. As for hiding them in a private interface, that's fine, but unless you're publishing your API or working with morons, I don't know what harm there is in making the accessors public.
It's proper for your view to have a weak reference to your controller, and the button actions can be as simple as invoking one of your controller's methods. It's no big deal, and if you want to add some logic a little later, there's a spot for it.
Sounds like you're doing fine.
PS This is stupid:
I'm currently learning ObjC and Cocoa programming, coming from the Java world.
To test my current skills and learning progress I'm creating a small calculator app from scratch (OSX not iOS).
My UI has 10 digit buttons 0-9 among others.
My first thought was, since the action receives the senders reference, to make one action
like -(IBAction)captureDigit:(id)sender and then just grab the digit from the button title.
But the interface builder only allows an action to be connected with one sender it seems.
So I ended up creating 10 captureDigit actions in my controller.
My Question:
is the first option possible somehow? I thought of adding the actions programmatically (is this possible?) to the buttons, but then I would have to add all digit buttons as outlets to my controller.
Bonus Question:
can a NSButton hold some kind of non visible value? Could not find this in the documentation.
Maybe this would violate the MVC pattern as the UI would then know of application specific data?
Thanks for any useful and kind answer in advance, I'm still learning
You can connect many senders to one target/action if you Control-drag from senders to the target, so that's not a problem.
WRT your bonus question, any NSView has an integer tag which you can set in Interface Builder. That's a convenient way to differentiate multiple similar views.
You can definitely connect more than more button to a single action. Also, you can use the tag field of any object to give it a "behind the scenes" value.
It's perfectly possible to add as many actions to a single controller. How is Interface Builder preventing you from doing this?
You could have a NSDictionary instance in your controller, in which you could match NSButtons to whatever data you want.
To make it easy, in IB create one button and drag from NSButton to File's owner it then shows all of the methods that we can send to NSButton, then select captureDigit:. Now copy and paste the button change the title, copy and paste in IB keeps the connection and use tag field as costique, nitrex have already said.