views:

60

answers:

4

I was wondering if, whenever I have a situation in which I have to hide some UI element temporarily, it is sufficient to hide it (many frameworks give this option) or I should delete the object in memory and recreate it later when needed again (with the same parameters).

What are the pros and cons of each solution? I was thinking that maybe by hiding the element you save state informations that may be important, and you also save the allocation time, so maybe it is the better way for elements that must be hidden for a short period of time. But what if the time becomes bigger? I would then have a non-needed object in memory for the whole time.

One example, to give a clear picture of what I am talking about, would be a toolbar that changes buttons based on some context change. That is, normally there are some buttons attached to the toolbar, but when the user select one action in some other part of the interface, those buttons must be replaced by new ones (one of which is the "Done" button). Similarly, when the user selects the "Done" button in the toolbar, it goes back to the initial state.

I don't know if this is a stupid question and maybe it could be that I'm doing something like premature optimization... but I will be thankful for all your answers.

+3  A: 

I think that the general rule of the thumb is that elements that you plan to reshow, should be hidden; otherwise destroyed (some exceptions obviously apply). When/if this becomes infeasible, you could consider further optimizations.

Daniel Vassallo
elements or sections who i want to use in future, but i have developed and i can't release his functionality in this update/version i hidding and never showing to user and i think this is a exception of this rule of thumb because i dont must hide in other files/projects code who i want use in this place later. Or if you developing big projects, some part of forms etc, you can deploy and in few version later you must block this functionality, then you can simple hide this form in project and maybe use this later in other update in a full or part piece
Svisstack
A: 

There is no general answer to this question. It depends on the system type, CPU and RAM restrictions, the number of UI elements in question, how frequently the UI is going to be shown / recreated, etc. Perhaps if you could give an example we might be able to give you more concise feedback.

Adrian Grigore
I edited the question by adding an example!
Eugenio Depalo
A: 

Javascript objects are not like Windows (GDI) objects: they usually don't have a will to send/receive messages - almost passive. It takes less code to hide, right? Perhaps it depends on total amount of interactive objects per user session.

mhambra
+1  A: 

It's a very good question. Here's what occurs to me:

  • Suppose (just for the sake of argument) you have lots of different forms that could be displayed in the same space. Then if you create/destroy controls, you are only paying at any one time for the controls that the user can see. On the other hand, if you hide/show controls, you are paying all the time for the large number of controls the user isn't looking at (and may never look at). So I always create/destroy. (Actually I keep previously used controls in pools so I'm not actually re-creating them.)

  • Many people store user state in the controls of the UI, but personally I hate that and I never do it. I think if some information is worth remembering it belongs in application data structure. This means of course, that the controls of the current visible form have to be "bound" or kept current with the application data structure. I just make sure I can do that no matter what.

I've had to be inventive to accomplish these in a way that simplifies application code, and as a result the method I use is not well known, which exacts another kind of price.

Mike Dunlavey