Application with more than one screen

Nov 12, 2008 at 9:32 PM
Hi, I'm studing CAL for quite some time.
I can see that a lot of thinking has been put into this project and I try to learn as much as possible from it.

One area which I do not understand it how to create an application with more than one screen.
I know there are several ways to go about it, but it seem you don't offer any advice about it.
So my first question is "What is your best practice for transition between screens?" (Something like SDI but with more than one screen).

I have an application which has a single screen that host all the possible "sub-screens" of the application. It remind me the way iPhone UI is built, each time you work with a single screen, if you need details the current screen is "pushed" to the stack of screens and the next window is now display.
So, as a great fan of Mac softwares (don't be sad, they don't have WPF equivilent yet) I've stady the iPhone SDK. Apple has very clear seperation for MVC. The thing is that in the iPhone SDK the controller has a single view which is bound to it. That means that have a reference to view and reference to controller is the same (you can get to the view from the controller).
My second question is "Should I have a property in my presenter which is the view connected to it?"

Thank you,
Ido.
Nov 13, 2008 at 4:04 AM
#1... Take a look at CompositeWPFContrib which now has a WindowRegionAdapter.  I haven't used it, but I like what I've read (here).

#2... That is what I do.  I have my Presenter constructor demand an instance of IMyView which is then applied to a public IMyView property called View.  It is this View property that is Added to regions.  Take a look at the UIComposition QuickStart which comes with CAL.  The Quickstarts are invaluable.
Nov 13, 2008 at 7:09 AM
Hi, Thanks, I will have a look at WindowRegionAdapter.

What about the second question?
I've notice there is no base interface from which all Views, Presenters or Model implement.
This means they have nothing in common, which can be a good thing, but it makes creating a generic system around them very hard.
I'll think how to put the problem in a form of question.

Thank you,
Ido.
Nov 13, 2008 at 2:14 PM
It looks like #2 has a few parts so I'll break them down.

For the "window stack" concept you are referring, you can do this in a number of ways.  Depending on the pattern you choose, you could have a Controller per View and have a managing Presenter Add and subsiquently Activate each view "on to the stack".  Unfortunately, Region.Remove will not Reactivate the previously active View; it doesn't presume to know which view should be activated, if any, after removing a previous view.  It would, IMO, seem logical for the "View Stack" logic to be kept in the Presenter.  Some may argue that is better kept in a "Supervising Controller", but its semantics at that point.

As for the IView to rule them all, I'm curious as to the common View logic you feel would be important for creating a generic system that is missing from CAL today.  I would definitely see a place for a common IView interface among individual implementations of CAL, but each will have their own way of dealing with Views (Model property w/DataContext backer, SetModel method, etc).  That said, a View doesn't have to be something that implements an Interface, nor does it need to be a WPF Control.  It could simply be a Model or ViewModel instance with DataTemplates deciding how things will be rendered.  I believe the CompositeWPFContrib has an example of this. 
Nov 13, 2008 at 3:36 PM
Hi,
Thank you very much for the answer.

I agree with you that my need for common view comes from perspective of single application. Another reason for me to think about common interfaces for view,controller and model is to stream-line the build process of them.
I'm not sure what is the best way to composite model-view-controller pieces. For screen that display a single object or collection of objects is pretty strait forward. The case I'm dealing with right now is creating a screen which combine single model and two sets of view-controller (actually since I'm developing WPF application I'm using view/view-model combinations).
Suddenly the process of composing this screen from several different blocks is not that easy.

I've learned a lot from studying iPhone SDK in side call icodeblog.com, take a look there, you might just like it.

I've implement the "View Stack" by placing TransitionControl from Bag-O-Trick of Kevin and set the Content of that control each time a content is pushed or pop from the stack.
I know about WPF content model so my content is just an Object. If you push model object which happens to have a DataTemplate everything works just fine. And the bonus is that I get nice animated transition between screens (I use the 3D cube, but there are plenty more).

Thank again,
Ido.

On Thu, Nov 13, 2008 at 4:14 PM, cromwellryan <notifications@codeplex.com> wrote:

From: cromwellryan

It looks like #2 has a few parts so I'll break them down.

For the "window stack" concept you are referring, you can do this in a number of ways. Depending on the pattern you choose, you could have a Controller per View and have a managing Presenter Add and subsiquently Activate each view "on to the stack". Unfortunately, Region.Remove will not Reactivate the previously active View; it doesn't presume to know which view should be activated, if any, after removing a previous view. It would, IMO, seem logical for the "View Stack" logic to be kept in the Presenter. Some may argue that is better kept in a "Supervising Controller", but its semantics at that point.

As for the IView to rule them all, I'm curious as to the common View logic you feel would be important for creating a generic system that is missing from CAL today. I would definitely see a place for a common IView interface among individual implementations of CAL, but each will have their own way of dealing with Views (Model property w/DataContext backer, SetModel method, etc). That said, a View doesn't have to be something that implements an Interface, nor does it need to be a WPF Control. It could simply be a Model or ViewModel instance with DataTemplates deciding how things will be rendered. I believe the CompositeWPFContrib has an example of this.

Read the full discussion online.

To add a post to this discussion, reply to this email (CompositeWPF@discussions.codeplex.com)

To start a new discussion for this project, email CompositeWPF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com