Managing many widgets in GWT

2
votes

Suppose we've the following structure of widgets / panels in a GWT application -

  • A Tree menu in the left of the DockLayoutPanel which is used for navigation to different applications.
  • A panel in the center of the DockLayoutPanel and different content widgets getting loaded in this panel (this is controlled by the navigation tree menu.
  • These content widgets are composites containing one or more widgets.

One way to deal with such application is to keep singletons for all widgets / panels, which means composites will hold singletons to all of their child widgets. But I feel this is excess usage of singleton. The other alternative is to construct new Widget object every time one is needed, but this must be expensive.

What are the best practices around this? Are there any standard patterns which take care of this problem?

1
gwt

1 Answers

4
votes

The other alternative is to construct new Widget object every time one is needed, but this must be expensive.

You'd be surprised. While Widget creation isn't free, in most cases, it is pretty cheap, even in DevMode. There are several widgets that are expensive to create in DevMode (specifically, the FlexTable/Grid), but those speed up drastically once you compile the application.

There doesn't seem to be any pattern specifically for this, nor can I point to any one guru giving a best practice, but in our application we had previously treated all of our top level widgets as singletons and it caused a load of issues for us. (Managing state between different screens, handling event bus events, stale data on the screen when not cleared)

We just refactored most of the code to be created on demand more (and subsequently destroyed when no longer needed) and we gained simpler code and a faster startup time.

In the end, if you do create widgets on demand, there may be a few cases where you need to increase performance by making those widgets singletons, but I think you'll find that only a few would warrant that effort.

All in all, don't assume something will be slow if you haven't tried it, and don't preemptively optimize your code.