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/
Related
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 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 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.
In Apple's developer guide, they state: "A split view controller must always be the root of any interface you create" (see here). I was curious if anyone knew why they decided that. I have a tab navigator-based application and it makes sense for the content in one of the tabs to be presented in a split view. Why would Apple be opposed to that kind of design? Thanks in advance for your answers.
-Max
PS I'm not looking for ways to put a split view controller in a tab navigator controller (that much I can figure out, even if the code does look sloppy). I'm more curious if anyone has any idea why Apple frowns on it.
I don't think that this is necessarily a user experience decision as much as it is a technical restriction. UIKit makes a number of assumptions about how UIViewControllers will be used. Including the idea that only a single UIViewController instance has its view visible in given window at any given time. Now since Apple has access to the implementation they have been able to make exceptions for their own "container view controller" classes (UINavigationController, UITabBarController, and UISplitViewController). We can't tell exactly how much of a special case these controllers are or what they needed to do to support displaying nested sub view controllers correctly but one consequence seems to be that both UITabBarController and UISplitViewController are not intended to be used except as the root view controller of a window. Attempting to nest them within other container view controllers may cause unexpected or unreliable behavior.
I tried to cover these restrictions on the use of view controllers and some possible alternatives here: http://blog.carbonfive.com/2011/03/09/abusing-uiviewcontrollers/ Hopefully that's of some use to you but I'm afraid the only reliable way to get the UI you seem to be looking for it to implement your own split view style display within the view of a single UIViewController.
Please ignore my answer:
Because you can't resize UISplitViewController's subviews with touches?
Apple has always placed high value on consistent use of user interface elements. Having all applications work in the same way helps the user to immediately understand how an app works even if they've never seen it before. Establishing a conceptual hierarchy of view controller containers makes a lot of sense when you're trying to help the user predict behavior.
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.