🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: borland.public.jbuilder.java.swing
5 messages
5 total messages Started by Bradley Kieser Tue, 03 Feb 2004 00:59
Multi-screen apps - changing from screen to screen
#1187
Author: Bradley Kieser
Date: Tue, 03 Feb 2004 00:59
42 lines
3032 bytes
This is a question about a proper application development. I.e a 
multi-screen, menu and button driven app that changes the contents of 
the window that the user sees based on actions and context.

A normal app seems to me to have a frame and then areas that are 
refreshed with various jpanels depending on what the "screen" is. For 
example going from a login screen to a data display screen.

There seems to be several ways to achieve this:
   a) Use cardlayout and change visibility to bring the required card 
"screen" to the foreground.
   b) Layer panels on top of each other and change their visibility.
   c) Invoke new frames and exit old ones.
   d) create and drop jpanel objects and position these on the screen.

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.

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.

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.

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.


I keep thinking that I am missing a trick with JBuilder X but I have 
looked and looked in the manual and cannot find anything that solves 
this problem. This is at start as far as any app dev is concerned and 
given how mature JB is now, should have been solved in JB ages ago.

So what am I missing? What is the best solution to this problem? Anyone 
have any tips or ideas for me?
Re: Multi-screen apps - changing from screen to screen
#1195
Author: John McGrath [TeamB]
Date: Thu, 05 Feb 2004 21:11
55 lines
3310 bytes
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.


-- 
Regards,

John McGrath [TeamB]

---------------------------------------------------
Before sending me e-mail, please read:
    http://www.JPMcGrath.net/newsgroups/e-mail.html
Re: Multi-screen apps - changing from screen to screen
#1200
Author: Bradley Kieser
Date: Sat, 07 Feb 2004 23:53
72 lines
4057 bytes
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.
> 
> 
Re: Multi-screen apps - changing from screen to screen
#1205
Author: John McGrath [TeamB]
Date: Thu, 12 Feb 2004 00:00
20 lines
1738 bytes
On 2/7/2004 at 6:53:06 PM, Bradley Kieser wrote:

> 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?

By creating the panel just when it is needed.  In your solution (a), 
you would need to add code to the method that switches which panel is
visible.  Instead of assuming that a particular panel already exists
and has been added to the parent (CardLayout) panel, you would first
test whether you have created it yet and if not, create it.

-- 
Regards,

John McGrath [TeamB]

---------------------------------------------------
Before sending me e-mail, please read:
    http://www.JPMcGrath.net/newsgroups/e-mail.html
Re: Multi-screen apps - changing from screen to screen
#1207
Author: Bradley Kieser
Date: Thu, 12 Feb 2004 13:48
22 lines
1883 bytes
For others reading this thread, John's ideas here rock. I have tried 
them and can vouch for them.

;-)

Thx John!

John McGrath [TeamB] wrote:
> On 2/7/2004 at 6:53:06 PM, Bradley Kieser wrote:
> 
> 
>>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?
> 
> 
> By creating the panel just when it is needed.  In your solution (a), 
> you would need to add code to the method that switches which panel is
> visible.  Instead of assuming that a particular panel already exists
> and has been added to the parent (CardLayout) panel, you would first
> test whether you have created it yet and if not, create it.
> 
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads