🚀 go-pugleaf

John, thank yo for these extremely handy comments. I would just like to 
share my experience since posting this with others:

I went for option (a) in the app in the end. Only thing is as the 
screens are very rich in graphics and other presentational layout 
components, after 12 screens we very quickly ran out of memory on app 
startup. So we needed to go to (d).

Johm, how would you recommend implementing a "lazy load of panels" as 
you put it? I take it that you mean some sort of async load, but can you 
clarify or expand on this?

Thanks,

Brad

John McGrath [TeamB] wrote:
> On 2/2/2004 at 7:59:49 PM, Bradley Kieser wrote:
> 
> 
>>Card layout (a): For large apps that have many screens, using
>>cardlayout to change from screen to screen causes memory overflows
>>and the app chews large amounts of memory and is slow to load.
> 
> 
> This solution does take more memory, but it is generally faster than
> the most reasonable alternative.  There is no reason that it has to be
> slow to load if you lazily load the different panels.
> 
> 
>>Layers (b): This requires null or XY layout and is decidedly
>>non-resizable! It has all sorts of problems not least of which is
>>that you quickly confuse JBuilder and lose nearly all the visual
>>design and layout ability.
> 
> 
> There is nothing that would make this non-resizeable, nor should it
> confuse JBuilder.  However, this is really pretty much the same as (a),
> except that you have to write the code to show and hide the individual
> panels.  That is what the CardLayout does, so why not use it?
> 
> 
>>Creating new frames (c): This is a terrible solution because you are
>>essentially restarting the app every time and reloading loads of
>>things (such as menus) that shouldn't have to be reloaded.
> 
> 
> Yes, this is a bad solution, but it is really not the same as
> restarting the application.  But it would involve destroying and then
> immediately re-creating several components such as the frame and the
> menu, which is not good.  This could also cause the window to flash,
> annoying the user.
> 
> 
>>Creating/dropping objects (d): This seems the best of the bad choices
>>but means that you quickly lose JBuilder's visual designing because
>>it cannot understand the code. Also requires a lot of coding for what
>>is really a fairly straight forward and dare I say probably well
>>established and solved problem.
> 
> 
> This saves on memory, but it takes longer to re-create the panels each
> time you need to show them.
> 
> 
> I think you are better off with either solution (a) or (d).  This is
> the classic speed / size trade-off, so which you choose will depend on
> the application and the target audience.  I have generally opted for
> faster (a) over smaller (d), since memory is very cheap these days, but
> your situation may be different than mine.
> 
>