MVP Question

49 views
Skip to first unread message

Jambi

unread,
Sep 6, 2010, 4:10:11 PM9/6/10
to Google Web Toolkit
Hey guys,

I have some problems with my MVP architecture. Do I have to "destroy"
my old presenter instances when I´m creating a new one? For example:

I´m on page A and switch to page B. After that I go back to page A and
create another instance of pageApresenter with my history management.
But it feels, that the old instance of my presenter runs in the
background and is also affecting my actions. When I´m now fireing an
event to the eventBus the event is called twice or more often if I
switch another time to page B and then back to page A.

My routine to create those presenters looks like this:

...

Presenter contentPresenter = null;

if (token.equals("adminMembersShowMembers")) {
contentPresenter = new MemberListPresenter(rpcService, eventBus,
new MemberListView(eventBus));
} else if ...

contentPresenter.go(display.getContentContainer());

...

I would appreciate your help ;)

thanks, Michael

Jeff Chimene

unread,
Sep 6, 2010, 5:29:04 PM9/6/10
to google-we...@googlegroups.com
A couple of observations:

o Consider presenters as singletons
o Consider Gin

I'm sure others will provide additional observations.


On 09/06/2010 01:10 PM, Jambi wrote:
> Hey guys,
>
> I have some problems with my MVP architecture. Do I have to "destroy"
> my old presenter instances when I�m creating a new one? For example:
>
> I�m on page A and switch to page B. After that I go back to page A and
> create another instance of pageApresenter with my history management.

I don't use history management (yet), but you shouldn't need to create a
new presenter just to go to a place.

> But it feels, that the old instance of my presenter runs in the
> background and is also affecting my actions. When I�m now fireing an
> event to the eventBus the event is called twice or more often if I
> switch another time to page B and then back to page A.

That's what we call a "clue" :)

You probably want to deregister your handlers before switching to Page
B, and reregister upon returning to page A.

Jambi

unread,
Sep 6, 2010, 5:43:08 PM9/6/10
to Google Web Toolkit
> o Consider presenters as singletons
> o Consider Gin

I haven´t tried Gin till now because I try to learn step by step how
MVP etc. works. I´m pretty new to programming and GWT so it´s really
hard for me to try all the opportunites you have now in gwt (MVP, gin,
guice, eventbus, etc). Right now, I don´t even know what even
dependency injection is. But as I said, I´m trying to learn it step by
step.
So you would recommend Gin to solve such problems?

> I don't use history management (yet), but you shouldn't need to create a
> new presenter just to go to a place.

So what would be the best practices to recall my presenter singleton?

> You probably want to deregister your handlers before switching to Page
> B, and reregister upon returning to page A.

Same question here, what would be the best practice for that? I haven
´t seen something like that in the gwt mvp tutorial.

Thomas Broyer

unread,
Sep 6, 2010, 7:01:49 PM9/6/10
to Google Web Toolkit


On 6 sep, 23:29, Jeff Chimene <jchim...@gmail.com> wrote:
> A couple of observations:
>
> o Consider presenters as singletons
> o Consider Gin
>
> I'm sure others will provide additional observations.

"presenters as singletons" means you have to make sure you cleanup
state between uses; "throwable" presenters are easier to code (and
test) because they don't need this kind of clean-up. Not to mention
that singletons eat up memory even when you no longer need them.
See "a note on performance" in http://tbroyer.posterous.com/gwt-21-activities
(and look at GWT 2.1's com.google.gwt.app.place.AbstractProxy*Activity
–in milestones up to and including M3, they're called
AbstractRecord*Activity–; Ray Ryan recently said this design was
inspired by Wave where it was quite succesful).

Jambi: Gin won't help you solve this particular problem, but I advise
you to look at it soon, as it'll make your life so much easier!
(BTW, dependency injection is a very good pattern to follow, be it
managed manually or with tools such as Gin; the rule of thumb is: do
not "new" objects –such as your presenters and views–, have them, or
factories of them, passed to your constructor)

> On 09/06/2010 01:10 PM, Jambi wrote:
>
> > Hey guys,
>
> > I have some problems with my MVP architecture. Do I have to "destroy"
> > my old presenter instances when I m creating a new one? For example:
>
> > I m on page A and switch to page B. After that I go back to page A and
> > create another instance of pageApresenter with my history management.
>
> I don't use history management (yet), but you shouldn't need to create a
> new presenter just to go to a place.
>
> > But it feels, that the old instance of my presenter runs in the
> > background and is also affecting my actions. When I m now fireing an
> > event to the eventBus the event is called twice or more often if I
> > switch another time to page B and then back to page A.
>
> That's what we call a "clue" :)
>
> You probably want to deregister your handlers before switching to Page
> B, and reregister upon returning to page A.

+1
So to answer Jambi's question, yes you have to "destroy" your
presenter (in GWT 2.1, stopping the activity) to tell it to deregister
itself from whereever it registered references to itself (which
prevent it from being garbage collected).
This is done by keeping handles to the HandlerRegistration returned by
the addHandler calls to the event bus to be able to removeHandler()
(you could also just call removeHandler on the event bus with the
exact same arguments as your previous addHandler calls; note that in
GWT 2.1 activities, this would be automatic, handled by the
StopperedEventBus you're passed in your activity's start())
http://google-web-toolkit.googlecode.com/svn/javadoc/2.0/com/google/gwt/event/shared/HandlerRegistration.html
Reply all
Reply to author
Forward
0 new messages