My GWT app will have 4 - 5 different views but each one will have 2 similar buttons on the bottom of the view. The function of these buttons will vary between each view but their appeararnce/position will remain the same. Is there any design strategy that I could apply in this case? Could I go down the road of having a base panel class that adds the buttons and each extending class then implements the different functionality or is there a better way to do it?
Create a composite widget BottomToolbar consisting of a panel with two buttons. Add two methods to this widget: setLeftButtonHandler(ClickHandler handler) and setRightButtonHandler(ClickHandler handler).
When you add this widget to the view, your Controller/Activity/Presenter (whatever you use) only needs to set these handlers.
The best to do is to create one view that takes a controller which is different for your 4 or 5 views.
This is a basic MVC pattern : your view can be instanced several times but user can interact differently depending on the controller you give to the view.
Then, you can also extends your main view to provide more ui differences.
Related
I wanted to know if I have to create a new ViewController for each view I have. Let's say I have 3 views do I need 3 viewControllers or does 1 ViewController can manage all 3 views?
Edit: Views are Objects that I create with .xib file so following the description given me by Xcode 4.3.3: represents a rectangular region in which it draws and receive events.
My situation : What I want is the main View showing 3 buttons, each button leads to a new View. That's about it each of the 3 views will have about the same thing, a tableView to display data parsed from an XML.
Thanks again!
EndEdit
Thanks
Both are possible, depends on your needs. View controllers can easily manage more than one (sub)view (e.g. every UI control subclasses UIView and you can have many in a single view controller). Sometimes it's more convenient to put views in different view controllers, sometimes it's not.
Depends on your situation and what you want to present to the user. If those 3 view controllers have very similar functions and only minor differences, then you could use the same class and have an instance variable to indicate which mode you're in. For instance if you have a list of Songs, Playlists or Videos, those could be the same class, with an enum variable to differentiate between the 3 modes. If your views are significantly different however (like a Song list and a Video player) then you should usually have separate classes for them.
For iOS, general best practice has been for a single view controller to manage a single "screen (or "window", but of course there is only one of these on an iOS device). This view controller may support a variable number of view objects (certainly not a ratio of 1:1 views/view controller).
As of iOS 5, nesting multiple view controllers managing multiple views in single window is now technically supported, but I still consider it a practice best avoided.
One window = one view controller = multiple views.
In one view controller you can manage any number of views.
It is preferable to use a viewcontroller per view. the advantages of the approch is as follows:
Any time you can convert the Template of the application. (eg. from table view to tabview or split view can make quick change)
with each view controller you follow the MVC architecture.
if you have n controller than try to manage n MVC model so that you can shift any model any where easily.
Memory management will be easy (Push and Pop manage memory automatically.)
if we have sigle view controller and n number of view than it will be quite difficult to manage memory.
Also we need to keep the screen ID for each view and need to mantain also their switching.
there are N number of advantages if you use N numbers of viewcontroller over N number of views.
I would like to use a single WizardViewController with different inputView subviews. The WizardViewController would share a searchCriteria and pass it along to each new step, with each step adding to the criteria depending on the input for that particular inputView.
The problem I am facing is how to structure my objects/views so that I can reuse WizardViewController accepting different types of input/controls. For example, I've thought of using a WizardViewModel that had members like enum wizardViewModelType (for each type of view), UIView *inputView that corresponds to each type of WizardViewModelType, and creating custom UIView subclasses that correspond to the different possible inputViews that would be needed, connecting outlets as necessary in Interface Builder. The problem is that I believe that going down this road will lead to a lot of inter-class dependencies and basically defeat the purpose of separating the inputView logic from the WizardViewController. Furthermore some of the inputView will require me to grab possible values from a web service, which is something that the ViewModel will have to handle, further breaking the logic. Perhaps I need separate ViewController for each type of input view? Or am I thinking about this in entirely the wrong way?
Normally, the right way to do it is by having a ViewController for each UIView. The logic of your application should not be on the view, but on the viewController, and you can share data by using segues (if on ios 5), and I'm sure that there are other methods for ios 4 or below.
If I wanted to share codes between the UIViewControllers, the way I would do to make a wizard is to embedded it in a navigation controller and push the next viewController on the navigation controller stack.
If you want to share code between view controllers, I don't think you should do it on the view controller class. Basically, I would think of two options to do that:
1) write a base class: the base class should extend the UIViewController and your UIViewControllers could extend this base class.
2) extract the common code into another class (better, if applicable): You create another class that share the common code, and inject it into your view controllers.
I have a User Filter section of my iPad app. There is a segmented bar with 5 buttons for 5 types of filters.
Clicking each of the buttons will load up the respective view..
My question is.. would the best way to handle the UI of each filter to have several views in this nib and load/unload accordingly.. or would best practice be to create the information in a scrollable view?
below is the setup..
http://imgur.com/iuufU.png
Thanks in advance...
Generally, go with separate views. The Scrollable view is an approximation of what you're trying to achieve (by the looks of things), whereas the separate-views more closely reflect your aims.
Some typical dvantages:
if you change your UI design, e.g. if one of those filters has to go in a different page, but 4 stay here ... then it's easy to move the whole View without changing the eixsting ones.
you can put each view in a separate NIB file (if they're different), or loaded from a separate ViewController instance (if they're the same), and you get some of the advantages of Apple's automatica memory management of VC's / NIBs.
Usually, people start with the same view for each filter, using a single VC class (instantiated multiple times, once per tab).
Then, as the app evolves, they find that one tab needs a different layout, so they add another VC class, and only need to update the alloc/init line for that one tab.
Think an iPhone-based email client. You have three 'states' with the same UI: New Message, Reply and Forward (ignoring any others).
I'd like to have one view and have different View Controllers interfacing with the view. Given that the view is built in Interface Builder (with quite a few IBOutlets and IBActions), what is the best way to do this?
I suggest what you are saying doesn't really make sense.
The same view controller (ie, "your application" essentially) would just change between the three needs.
Also - it seems unlikely the three views would be exactly the same, hence make three different views/controllers.
(It's completely normal that you have many "similar" views -- which are indeed just separate views, but they happen to be graphically similar.)
Also - it's very likely you could have one overall view(/controller), and simply sitting inside it would be the specific writing/reading/whatever view(/controller).
I hope it helps!
One way to do it might be to create one view controller which contains all the Interface Builder connections, and then subclass that view controller multiple times. In code, you could instantiate the subclasses all using the same nib with -initWithNibName:bundle:.
Alternatively, your view controller could have kind of "mode" value, which determines its behavior based on the state it should be in. The view controller presenting it would then be responsible for setting it up appropriately.
what is difference between view based and navigation based system in iphone . which one better to use and when?
if you have hierarchy of views, use navigation based else use view controller based.
You're talking about default templates that Xcode offers you to start your project with. It's not like they're different "systems" per se, they're just different starting points.
A view template is good if your app is one screen, or maybe a couple screens. Movement between those screens is up to you (and there are some pretty easy and good tools for animation screen changes, but you have to hook into those yourself).
A navigation template is good if you're going to be navigating a hierarchy of data, possibly with lists, sublists, detail screens, etc. Shifting between views is done with a call to UINavigationController, that handles all the transitioning business for you.
navigation based system is used if you want to use something like moving from main view to its inner view
like parent to child then subchild and so on...
While if you have no such hierarchy then you can use view based..
Navigation Based gives you a flexibility to reverse back to the view controller which you have already visited. like say for example you move 1->2->3->4->5 now if you want to go to 2 you can go easily. Navigation adds a top bar while view based is used if you dont want any kind of hierarchy..
hAPPY cODING...