GWT Activities - performance implications of using SimplePanel vs DeckPanel (card panel)

In most of the Activities and Places examples I've seen, people use a SimplePanel as the display for an ActivityManager.

I was wondering if there's a benefit to using a DeckPanel/DeckLayoutPanel instead of SimplePanel. It's fairly trivial to create a wrapper around a Deck panel that implements AcceptsOnWidget.

I haven't seen this topic discussed anywhere. Prior to MVP+Activities being commonly used in GWT, people generally used Tab panels (which internally uses deck type panels) and Deck panels to control switching between panels within a given view.

The difference between the two is SimplePanel.setWidget(..) will remove the previous child from the DOM and append the new widget wher开发者_开发问答eas a deck type panel will use CSS to control visibility of the current panel (i.e. "display: none" to hide inactive panels).

1. If using a deck panel, it generally means you will have much more Elements in the DOM. I would imagine this uses more memory and makes the application "sluggish", even if those nodes are not visible ("display: none"). Is this true?

2. If this is true, why did Google use a deck panel style impl for TabPanel/TabLayoutPanel instead of internally using a SimplePanel?

3. Is one approach more favorable over the other?

---

Performance wise there is no difference. It all depends how you use it. In the DeckLayoutPanel all children are kept in memory. But if you would implement the same thing with a SimplePanel you need to keep a pointer to those same children yourself, so the memory footprint would be about the same. Unless with a SimplePanel you create and render a child each time it's shown and throw it away when hidden, which would possible be memory efficient (if the garbage collector does it's work), but it would be a hit on usability since rendering is expensive.

Second if you use a DeckLayoutPanel all it's children are created at once, while only one is shown. For performance this might not be optimal. So for this reason you could add a LazyPanel between the child and the DeckLayoutPanel, so it's only created when shown. But that might take some extra coding to make it work (because it's lazy you need to lazy initialze it which can cause some difficulties) However, still for the comparison between DeckLayoutPanel and SimplePanel it's only a matter of when you would create the children for the SimplePanel (all up front == same issue as with DeckLayoutPanel) and not something specific to the difference between DeckLayoutPanel and SimplePanel.

In general if you have a defined ordered set of children use a DeckLayoutPanel (like with a TabPanel) and if you have a undefined set SimplePanel is the better choice (like in MVP to show the current view).

---

DeckLayoutPanel internally holds collection of all your views (actually views that you've registered or displayed) in order to be able to determine sliding animation direction (depending if you go back or forward). Apart from this, I didn't notice that application become sluggish when switched from SimplePanel do DeckLayoutPanel. It's especially safe, when all your views are singletons. But please aware that in such case, when switching between the same view instance (for example main categories list -> subcategories list), DeckLayoutPanel may have some problems rendering sliding animation.

In my opinion there is no favorable solution - if you don't need "sliding" panels, I would not use DeckLayoutPanel (since all additional components increases complexity).