new GWT MVP article (part 2)

[interdev]

Hello everyone,
have you seen the new MVP Architecture article from google ?
http://code.google.com/webtoolkit/articles/mvp-architecture-2.html

they have changed the structure slightly, instead of having a View and
a Presenter which has an inner Interface (Display), aside from the
UiBinder part, they now have a View interface which has an inner
Presenter interface !

1- what do you all think ? are these yet another level of abstraction/
indirection necessary ?

2- when google wants to address problem of Nested/Layered presenters ?
header/body/footer, and body having its own dockpanellayout structure.

3- what do you think of "presenter.go(container)" ? and navigation/
history token inside multiple IF statements ?

i think these are more serious to address than introducing an
additional view interface which has an inner interface !

4- what do you think of DTO solution presented in the article, is it
scalable ? do you follow it or stick with your twig, gilead
framework ?

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[jocke eriksson]

I think it's a very good explanation on MVP. But one thing that comes to mind is that they should explain why they check for nulls all the time. I think the if statements should be followed by else, at lest empty ones! explaining why it is ok to ignore the call.  

ex.

    if (presenter != null) {

      presenter.onDeleteButtonClicked();

    

 

2010/4/22 interdev <jason....@gmail.com>

[Paul Stockley]

I like the model-view-presenter architecture. However I am not at all
sold on mocking out the view and testing just the presenter. The
problems is that you are not testing 3 of the potentially most error
prone parts of the system: 1) The browser and DOM, 2) The GWT widget
library and 3) the GWT java to javascript conversion. So you still
need to test these otherwise you are fooling yourself about the
reliability of your code. I would rather discared the interfaces, unit
test my rpc services using junit and use something like webdriver to
test the front end.

On Apr 23, 4:47 pm, jocke eriksson <jock...@gmail.com> wrote:
> I think it's a very good explanation on MVP. But one thing that comes to
> mind is that they should explain why they check for nulls all the time. I
> think the if statements should be followed by else, at lest empty ones!
> explaining why it is ok to ignore the call.
>
> ex.
>
>     if (presenter != null) {
>       presenter.onDeleteButtonClicked();
>

> 2010/4/22 interdev <jason.ved...@gmail.com>

>
>
>
>
>
> > Hello everyone,
> > have you seen the new MVP Architecture article from google ?
> >http://code.google.com/webtoolkit/articles/mvp-architecture-2.html
>
> > they have changed the structure slightly, instead of having a View and
> > a Presenter which has an inner Interface (Display), aside from the
> > UiBinder part, they now have a View interface which has an inner
> > Presenter interface !
>
> > 1- what do you all think ? are these yet another level of abstraction/
> > indirection necessary ?
>
> > 2- when google wants to address problem of Nested/Layered presenters ?
> > header/body/footer, and body having its own dockpanellayout structure.
>
> > 3- what do you think of "presenter.go(container)" ? and navigation/
> > history token inside multiple IF statements ?
>
> > i think these are more serious to address than introducing an
> > additional view interface which has an inner interface !
>
> > 4- what do you think of DTO solution presented in the article, is it
> > scalable ? do you follow it or stick with your twig, gilead
> > framework ?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Google Web Toolkit" group.
> > To post to this group, send email to google-we...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
> > .

> > For more options, visit this group at
> >http://groups.google.com/group/google-web-toolkit?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en.

[BryanPoit]

I was a bit disappointing. The example project wasn't even fully re
factored. The edit contacts view and presenter still reflect the old
architecture.

I think that though these tutorials are helpful its been almost a
whole year since part I of the article was posted. Also for trying to
make large application development easier the size of this example
application is quite small. As interdev mentioned there are some more
complex issues like Nested Layered presenters that most developers
have to struggle with.

On Apr 22, 3:27 am, interdev <jason.ved...@gmail.com> wrote:
> Hello everyone,

> have you seen the new MVP Architecture article from google ?http://code.google.com/webtoolkit/articles/mvp-architecture-2.html

[Chris Ramsdale]

@Bryan,

We'll get around to refactoring the EditContact View/Presenter, but the goal was to get the new View/Presenter relationship out there as soon as we could. We think it's a pattern that has worked for internal teams, and we hope that it works for the larger community as well.

Regarding the nested layer presenters, thanks for the feedback and I'll look into our codebase for examples that we can share publicly.

-- Chris

[Thomas Broyer]

On Apr 22, 9:27 am, interdev <jason.ved...@gmail.com> wrote:
> Hello everyone,
> have you seen the new MVP Architecture article from google ?http://code.google.com/webtoolkit/articles/mvp-architecture-2.html

First, I only read it quickly, I didn't download and looked at the
sample project.

> they have changed the structure slightly, instead of having a View and
> a Presenter which has an inner Interface (Display), aside from the
> UiBinder part, they now have a View interface which has an inner
> Presenter interface !
>
> 1- what do you all think ? are these yet another level of abstraction/
> indirection necessary ?

Not strictly necessary but it makes things simpler in the end (from
experience: I initially followed the same approach as Ray Ryan
explained at Google I/O 2009 and switch to a very similar approach to
this Part II a few weeks ago; it really gives you more flexibility and
makes the code, including unit tests, much easier to read).

In my project, the interfaces are all defined within the presenter
class, and the presenter interface (which I call Listener in my code)
is implemented by a private inner class. But the overall approach is
the same.

> 2- when google wants to address problem of Nested/Layered presenters ?
> header/body/footer, and body having its own dockpanellayout structure.

There are many ways of approaching the problem; just like with MVP
(the Display interface exposing HasXxxHandlers as in Part I vs. the
View and Presenter interfaces as in Part II). In our app, in effect,
each "parent presenter" also plays the role of "app controller"; but
because we have the presenter/view dichotomy, the view exposes
setSomeWidget(...) methods that the presenter calls; e.g.
setHeader(...), setBody(...), setFooter(...).

> 3- what do you think of "presenter.go(container)" ?

We do it the other way around: our presenters have a getView() method
and the parent calls container.add((Widget) child.getView()). This is
actually split between the presenter and the view, see above:
view.setHeader(childPresenter.getView()) in the presenter, and
containerWidget.add((Widget) child) in the view.

The only "issue" with presenter.go(container) is that container must
be a "simple" container, which means that when it's meant to be a dock
(layout) panel, tab panel, or some other complex panel (or an absolute
panel and you want to add with coordinates), you actually have to add
a SimplePanel first and pass it as the "container" to the go() method.
Otherwise, I can't see a problem with presenter.go(container).

> and navigation/
> history token inside multiple IF statements ?

I'm using a very similar approach as the one in bikeshed:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/bikeshed/src/com/google/gwt/app/place/

> i think these are more serious to address than introducing an
> additional view interface which has an inner interface !

But they highly depends how your app is organized re. "navigation".
For instance, in Google Wave, there's no "switching of views" in the
"app controller", though there obviously is at lower levels. And given
how the history token is built, there probably isn't "history token
inside multiple IF statements".

> 4- what do you think of DTO solution presented in the article, is it
> scalable ? do you follow it or stick with your twig, gilead
> framework ?

You mean what's explained in the "dumb view" sections? How is it
related to any ORM/persistence layer/framework?

[Thomas Broyer]

On Apr 24, 2:04 am, Paul Stockley <pstockl...@gmail.com> wrote:
> I like the model-view-presenter architecture. However I am not at all
> sold on mocking out the view and testing just the presenter. The
> problems is that you are not testing 3 of the potentially most error
> prone parts of the system: 1) The browser and DOM, 2) The GWT widget
> library and 3) the GWT java to javascript conversion. So you still
> need to test these otherwise you are fooling yourself about the
> reliability of your code. I would rather discared the interfaces, unit
> test my rpc services using junit and use something like webdriver to
> test the front end.

One of the goal of using MVP is to unit test in "pure java", which is
waaay faster than using a GWTTestCase or WebDriver.
But of course it only tests the "presentation logic" (the presenter),
which means you SHOULD do other tests, automated using GWTTestCase or
WebDriver, or manual tests.

[Stephen Haberman]

> I like the model-view-presenter architecture. However I am not at all
> sold on mocking out the view and testing just the presenter. The
> problems is that you are not testing 3 of the potentially most error
> prone parts of the system: 1) The browser and DOM, 2) The GWT widget
> library and 3) the GWT java to javascript conversion.

True, you need to test these integration tests. But I also agree with
Thomas, having extremely quick presenter-only tests is worthwhile.

You have to grow in to it though; at first I did not trust any of GWT,
nor my usage of GWT, because I was new to it and it'll all fairly
magical. So I had no idea, presenter-only tests or not, what
presenters were actually going to do when the real view was hooked up.

But after I'd worked with the app/GWT/etc. for awhile, I realized that
its very unlikely that GWT would suddenly stop working while I tweaked
some presenter business logic. At which point I started having faith
in presenter-only tests.

Not blind faith, of course, because I still have some browser-based
integration tests, but enough faith to use presenter-only tests for my
primary red/green TDD cycle.

- Stephen

[Chris Ramsdale]

On Thu, Apr 22, 2010 at 3:27 AM, interdev <jason....@gmail.com> wrote:

Hello everyone,
have you seen the new MVP Architecture article from google ?
http://code.google.com/webtoolkit/articles/mvp-architecture-2.html

they have changed the structure slightly, instead of having a View and
a Presenter which has an inner Interface (Display), aside from the
UiBinder part, they now have a View interface which has an inner
Presenter interface !

1- what do you all think ? are these yet another level of abstraction/
indirection necessary ?

It's not necessary, but it's something we've learned from the Wave team, and internally find more flexible and easy to test. There are many ways to wire up your views and presenters, and the technique that you use is largely driven by the application that you are developing. For example, while Ad Words and Wave extensively use the MVP pattern, the Ad Words architecture is more inline with the techniques discussed in part I, and Wave with part II. That said, the one characteristic that they both share is the need to test as much as they possible can with vanilla JRE tests. Nothing against GwtTestCase, but we all know it's slow.

2- when google wants to address problem of Nested/Layered presenters ?
header/body/footer, and body having its own dockpanellayout structure.

We use the technique described in part II. Composite views are responsible for instantiating their own children, and making them available for the parallel composite presenters.

 

3- what do you think of "presenter.go(container)" ? and navigation/
history token inside multiple IF statements ?

i think these are more serious to address than introducing an
additional view interface which has an inner interface ! 

4- what do you think of DTO solution presented in the article, is it
scalable ? do you follow it or stick with your twig, gilead
framework ?

If you're referring to the ColumnDefinitions, we know they'll scale. One, it requires minimal widget overhead and is fast. No more embedding hundreds of widgets within a table. Two, it's extensible, and testable. As your model grows, your ColumnDefinitions grow, not your views.  ColumnDefinitions are quite trivial, the bulk of the code dedicated to generating HTML, and don't require a GwtTestCase.

 

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[interdev]

Thank you everyone for sharing.

>@Chris Ramsdale,

>"We use the technique described in part II. Composite views are responsible
>for instantiating their own children, and making them available for the
>parallel composite presenters. "

>"Regarding the nested layer presenters, thanks for the feedback and I'll look
>into our codebase for examples that we can share publicly. "

Chris, I was wondering if you can share any code samples, or if
possible ask google team
to write a tutorial on more complex layouts and navigation. (parent/
child, composite views).

I've visited many forums, and this has been an area where many are
struggling. The MVP tutorial is great for introducing the concepts,
but
for real world applications with complex layout, i think more examples/
resources are definitely helpful for those who want to follow best
practices.

almost all GWT books are written prior to 2009, mainly dealing with
widgets, and very little on architecture, especially MVP.

Thank You

[dmen]

I've read it and IMHO it suffers from extreme over-compexity. Problem
is people will take this article as a reference for their designs.

[david....@gmail.com]

Hi,

originally the MVP pattern was design for separating the view from its
logic and the model it is displaying (as the MVC). Since the arriving
of UIBinder I found the word View misused. Actually, strictly speaking
the View is contained in the ui.xml file and the "Controller" is the
corresponding java file which is implementing the corresponding logic
and instanciation. This file merely represents a kind of Controller.
The Presenter used in this tutorial is (for me) nothing more than a
ControllerProvider which enable the ability to provide differents
implementations of the view logic.

What I'm founding strange is the fact that their are using the same
acronym (MVP) for two differents approaches :
- first one was Presenter centered as the abstraction was done on
Display and aggregation were done against the presenter
- second one was Display AND Presenter centered as the abstraction is
done on Presenter and Display the both referencing each other.

But this approach is mainly due to the fact that UIBinder is removing
a lot of boiler plate code from event handling (and first MVP tutorial
was not using it), but in the same way UIBinder tends people to adapt
the original MVP pattern to be able to use all its power !
That why there is so much reflexion to mix UIBinder and MVP together.

cheers

On Apr 22, 9:27 am, interdev <jason.ved...@gmail.com> wrote:

> Hello everyone,
> have you seen the new MVP Architecture article from google ?http://code.google.com/webtoolkit/articles/mvp-architecture-2.html

[Brian Reilly]

I agree that it would be very helpful to see some examples of building
a more complex composite UI.

I've been trying to find a good way to handle this while keeping a
clean separation between view and presenter. It gets worse when trying
to use GIN along with UiBinder. Both help with construction of object
graphs, but I'm struggling to find a way to use them to construct
parallel, linked presenter/view hierarchies. The best I've come up
with so far is to inject the presenter into the view, mark any
injected views as @UiField(provided=true), and not worry about trying
to put the presenters into a hierarchy... just let them dangle off of
the view instances. However, that presents other problems when it
comes to configuring different instances of the view/presenter pairs
(the view is starting to be not-so-dumb).

As for the complexity of the example code, it looks to me like there
isn't any "Contact" specific code in the most complex parts of
ContactsViewImpl. This could probably be moved into framework classes
(which could be thoroughly tested with GwtTestCase) where application
developers wouldn't have to look at it every day or worry about the
complexity.

-Brian

[Mike]

I'd like to chime in as well...

Since the project posted with the update hasn't been totally
refactored, its very confusing for those new to GAE, GWT, MVP, etc
(and it shouldn't be). This seems akin to turning in your homework
half-done or half-eaten by the dog...

I would like to encourage Google to complete the refactoring, and in
doing so -- present the ideas in a more concise and clear manner. The
presentation seems to add confusion rather than clarity.

I've found the following article to be extremely helpful in the
comprehension of MVP: http://www.atomicobject.com/files/PresenterFirstAgile2006.pdf
Article suggests T(est)D(riven)D(esign) beginning with the Presenter
layer.

The article also suggests a possible Adapter layer for use in getting/
setting data between the Presenter and View layers (which, I quite
liked and made my own attempts at MVP much simpler and clearer).

In my own experience, and reading other comments, seems that the
largest struggle people have is in understanding what code should live
in which layer, and how best to achieve that. I'd personally prefer
to see some additional instruction/suggestions assisting with these
issues. Also, I'd like to see the article updated to provide a better
overview of what is going to end up where (and why), and a better walk-
through of putting the proper bits into the proper places to achieve
that.

[Andrew Hughes]

There is quite a serious collision between the MVP pattern and the (super cool) UiBinder.

Presenters don't know what their concrete view is, all they know is the view interface has a asWidget() method. This seems like a logical separation. MVP says "presenters shouldn't know HOW they are visually displayed".

Since this is the real world, you will probably want to have a childView added to your parentView - this get's messy with UiBinder....

Presenters can only obtain either the childView's interface... childPresenter.getView(); //return's only interface type, not a widget!

Or, it can get a plain old widget via asWidget().... childPresenter.getView().asWidget();//return's just the type "Widget".

Thus, the parentView can only be provided with a "Widget" via childPresenter.getView().asWidget(). Inturn, that's all you can specify in the  ParentViewui.xml, i.e. <g:Widget uiField="childView">, the ParentView.ui.xml would look like:

<g:SomePanel>

  <g:Widget uiField="childView"/> <!-- Can't specify a concrete Widget type here!!!! -->

</g:SomePanel>

You also need this in the ParentView.java

@UiField(provided=true)

Widget childView; //Can't specify a concrete Widget type here!!!!

Because Gin has it's limit's and there's very limited runtime options with UiBinder, you end up writing a lot of BoilerPlate code "providing" the child widgets, plus you have to work with just "Widget" type's everywhere. Both of which are BAD and really do make development difficult.... and don't forget you can't call uiBinder.createAndBind until all widget's have been provided.

Thanks for reading.

--AH

[Fabio Kaminski]

Its funny when a solution creates more problems than solve issues they promissed to address..

this look to me like a politician, telling you they will solve the world hunger.. and in the and you are paying more tributes to make his cows fat..

i have go back to the whiteboard, and come back to javascript.. since at least.. gwt purposes steel better than all those rails-clone frameworks.. 

too bad its working on plaster java.. :s

[Manuel Carrasco Moñino]

Hello there,

IMHO, one of the issues of MVP and Gwt is the lack of good examples
showing how to use all the layers (including command pattern,
injection and event bus), how to test all the code, and how to
integrate the set of libraries available.

Taking the project Hupa as reference, I have re-factored the Contacts
project in order to integrate gwt-presenter, gwt-dispatch, gin and
guice; I have coded JRE tests covering all the presenters, and GWT
tests to demonstrate how to make functional tests able to check the
view and rpcs; finally I have put everything in a project handled with
maven and eclipse.

You can download the project and play with it:
svn checkout http://gwt-workshop.googlecode.com/svn/trunk/GwtWsMvpContacts
GwtWsMvpContacts
mvn clean test gwt:run package

Hope it helps to you

Cheers
-Manolo

[Mike]

> You can download the project and play with it:

> svn checkouthttp://gwt-workshop.googlecode.com/svn/trunk/GwtWsMvpContacts

> GwtWsMvpContacts
> mvn clean test gwt:run package

Looks very interesting. I've downloaded the project and imported to
Eclipse (don't have Maven yet).

First question:

The version of gwt-presenter that I downloaded from the Google Code
site doesn't appear to include this package:
net.customware.gwt.presenter.client.widget

Any ideas?

Cheers
Mike

[Manuel Carrasco Moñino]

I'm using the latest code of gwt-presenter from svn, so if you don't
use maven you should either compile gwt-presenter, or download the
library from:
http://gwt-workshop.googlecode.com/svn/trunk/mavenrepo/net/customware/gwt/presenter/gwt-presenter/1.1.1-replace-SNAPSHOT/gwt-presenter-1.1.1-replace-SNAPSHOT.jar

-Manolo

[Mike]

Manolo,

I may be mistaken, but I wasn't able to "replicate" what you'd done.
Taking either the released .jar files for gwt-dispatch and gwt-
presenter, or having gotten the latest code from the repository --
either way, there were differences between what you'd coded and what
the library was providing (the concepts were all very clear, but the
details didn't match the libraries). If the code matched all of the
libraries at a known state, I think it would be more useful.

Cheers
Mike

On May 4, 1:09 am, Manuel Carrasco Moñino <man...@apache.org> wrote:
> I'm using the latest code of gwt-presenter from svn, so if you don't
> use maven you should either compile gwt-presenter, or download the

> library from:http://gwt-workshop.googlecode.com/svn/trunk/mavenrepo/net/customware...

>
> -Manolo
>
>
>
>
>
> On Tue, May 4, 2010 at 7:48 AM, Mike <m...@sheridan-net.us> wrote:
> >> You can download the project and play with it:
> >> svn checkouthttp://gwt-workshop.googlecode.com/svn/trunk/GwtWsMvpContacts
> >> GwtWsMvpContacts
> >> mvn clean test gwt:run package
>
> > Looks very interesting.  I've downloaded the project and imported to
> > Eclipse (don't have Maven yet).
>
> > First question:
>
> > The version of gwt-presenter that I downloaded from the Google Code
> > site doesn't appear to include this package:
> > net.customware.gwt.presenter.client.widget
>
> > Any ideas?
>
> > Cheers
> > Mike
>
> > --
> > You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> > To post to this group, send email to google-we...@googlegroups.com.
> > To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

> > For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en.

>
> --
> You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
> To post to this group, send email to google-we...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

> For more options, visit this group athttp://groups.google.com/group/google-web-toolkit?hl=en.

[Manuel Carrasco Moñino]

Sorry Mike, but I don't understand what you mean.
Could you point me to the concrete lines of code which are not clear,
or send code to use the libraries in a better way?

Thanks
-Manolo

[dayre]

I could comprehend part I after watching Ray's presentation and
reading it a few times... it gave me a much better idea on how to
structure my application, but part II things started to fall apart for
me. It was very difficult to keep track of the additional layers of
abstraction introduced and the reasons for them + introducing UIBinder
and it's details, and shifting interfaces around from where they were
in part 1 made me dizzy. The author says it was a lot to cover at
one point and it was definitely "lost in translation" for me.

[Brian Reilly]

The increased complexity is definitely an issue. I don't like the idea
of yet more interfaces to have to worry about. It's a shame that part
2 of the MVP article doesn't address testing beyond simply mentioning
that these practices improve testability. It would be much clearer to
see before-and-after code highlighting the code that we want to be
testable in both cases. Without that, it's hard to convince someone
that the extra complexity is worthwhile.

I'm currently working on a small application using UiBinder (and
hopefully GIN) without MVP. It's giving me a refreshing perspective on
how fluent GWT can be, and I think the people I work with will
appreciate that. However, it's not going to be any more testable than
any other web technology we've used.

From there, I'm going to go about refactoring the code to make it more
testable. This will probably involve applying MVP-like patterns, but
I'm going to try to apply patterns that make sense and not be too
biased by existing examples. I may end up with something much like
what the GWT team is suggesting, or I may find some middle ground, but
I should at least have a good feel for what I'm getting in return for
the increased complexity.

-Brian

[fmod]

I'm trying to figure out how to make this parallel composite views /
presenter hierarchies.
And in my opinion it just break the MVP pattern.

One of the goals you pursuit with MVP is to decouple the View object
from the logic
it contains (the presenter). Making the Presenter unaware of how the
view is actually
rendered. And also implicitly by using the EventBus decoupling the
presenters from the others.

In the moment you have a 'parent' presenter, everything screw up:

1. The parent presenter has a knowledge of the children presenters.
You may be attempt to
move the logic relating the children (before in the event bus) to
the parent presenter.
Coupling them unnecessarily.

2. Worst. The parent presenter has good knowledge of the view he
manages. The view needs to provide
hook for the children. So the presenter can attach the views of it
child presenters to it.

Of course, it may be cases where having a 'Parent presenter' is a good
idea. But I think of
this cases where actually you make the separation for no conceptual
issues (be able to reuse code,
like you could do in a table, separating the rows as views).

Maybe I misunderstood something here. But I think the 'guy'
responsible for the layout can be
the AppController. As in the first first part of the article states.
'The AppController is responsible
to handle logic that is not specific to any presenter.'

But I don't like to much the idea. It makes the AppController aware of
the view and layout. But on the
other hand it may make sense, he is already aware of the History
tokens. And probably if you are also
deploying for mobile devices you will end up you need to rewrite the
AppController.

Other idea I kind of like more. Is using this new concept of Activity
(Google IO 2010, Architecture GWT)
So each activity will be a "page" in the application. The
AppController is listening the EventBus for
events requesting a new Activity. Then the AppController load the new
Activity and tells it to display
the page. So basically splitting the AppController into Activities.

What do you think about this? Are this parent presenters a good idea.
Better to move them to other 'entities'
like AppController or Activity?

Thank you
-Fran

On Apr 25, 12:54 pm, interdev <jason.ved...@gmail.com> wrote:
> Thank you everyone for sharing.
>
> >@Chris Ramsdale,
> >"We use the technique described in part II. Composite views are responsible
> >for instantiating their own children, and making them available for the
> >parallel composite presenters. "
> >"Regarding the nested layer presenters, thanks for the feedback and I'll look
> >into our codebase for examples that we can share publicly. "
>
> Chris, I was wondering if you can share any code samples, or if
> possible ask google team
> to write a tutorial on more complex layouts and navigation. (parent/
> child, composite views).
>
> I've visited many forums, and this has been an area where many are

> struggling. TheMVPtutorial is great for introducing the concepts,