1

I know there are similar questions to my question. But there are a couple I would like to ask specifically since we are planning to re-design our GUI by hand. The system we are designing will be an enrollment system which will be used by the school.

While we are designing it and have added many many components to the class, we encountered a low memory compile error that made me think that continuing to design it through GUI Builder may cause problems in the long run.

I'll really need opinion and suggestions from experts since we are just students.

So here's the screenshot of our current GUI Design with screenshot of it's classes.

enter image description here

This was actually a mistake to put all the panels and other components in class Enrollment_System.java which I suspect to have exceeded the limit of Xms of VM Options of project.

I thought maybe we could separate frames and panels to different folders/packages to avoid exceeding the limit of memory per class. Would that be the best thing to do? How many frames should we use if components will be put in separate folders like the screenshot below.

enter image description here

I guess my main questions is, how to properly manage the panels and components in such a way that it will be easy for us to instantiate objects and perform system tasks in the enrollment system.

I'd appreciate any suggestion or help.

heisenberg
  • 1,784
  • 4
  • 33
  • 62
  • Regarding the low memory compile error, here are the exact details in case you are not familiar of the low memory I'm talking about. http://stackoverflow.com/questions/34320675/java-compile-error-code-too-large – heisenberg Dec 22 '15 at 15:00

3 Answers3

3

For me this question is similar to whether one should drive a stick (manual) car or an automatic (with automatic gear change). Well if you are looking for comfort, quickly getting it done and you do not require extreme control over your GUI, i.e. where you put what then take the automatic. If you are particular about things especially if it is large project do it by hand.

As far as managing goes, before such a project you need to make a plan and put it on paper. Decide how many menus/frames/panels/buttons you want, what should be inside them and you need to outline a general idea about what you would need to implement these things. Then plan for how many classes you need as well, it is very important that you put related variables/methods in a class. It might sound tedious and a lot of work but trust me for big projects it always pays off. It will make your life easier.

In case you also plan to upgrade/change your program I would recommend good documentation or at least a lot of comments and good variable naming technique. Hope that helps.

ITguy
  • 847
  • 2
  • 10
  • 25
3

Some guidelines:

  • Use nested layouts to encapsulate view components.

  • For ease in prototyping, use nested classes, which can be easily promoted to separate classes having package-private access.

  • As outlined here, limit the scope and number of managed containers to the (relatively) few that will genuinely benefit from using the GUI editor.

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045
3

The choice between using a form editor and coding the UI by hand can be very opinion based.

When I first started with Swing, the form editors were, well, crap. So I learnt to code my UI's by hand, it also helped that on the first project I was working used a dynamic loading mechanism which meant we couldn't use top level containers, like JFrame, within our code, so everything had to start off as with a JPanel.

I thought maybe we could separate frames and panels to different folders/packages to avoid exceeding the limit of memory per class. Would that be the best thing to do? How many frames should we use if components will be put in separate folders like the screenshot below.

This is a good start, you should also limit the number of frames/windows you throw at your users, they have enough distractions in there lives to deal with, without you throwing more at them. Instead, manage your views in a way which uses as few windows as possible, like using JTabbedPanes or CardLayout (and dialogs where appropriate)

By separating your UI into "compartments", you reduce the coupling as well increase the re-useability, for example, if you have one component which displays the patient details, you could keep re-using it where ever you need to display there details.

I guess my main questions is, how to properly manage the panels and components in such a way that it will be easy for us to instantiate objects and perform system tasks in the enrollment system.

Separate the areas of responsibility, allowing each view to manage just one aspect of your requirements, then build these up (adding views into a common container) to generate more complex functionality.

For example, you could have a simple "patient details" view, displaying basic information about the user, you could then have a "select patient" view which simply displays the names of patients in a JList, you could then combine these into a more complex view, so that when the user selects a patient from the JList, you can display the patient details.

You could then have a "patent history" view, combining the "patient details" view, showing basic details about the patient, with a list of the patient's treatment history.

Recommendations

Form designers don't encourage you to use good design practices, as you've found. Rather then thinking about your UI as a single entity, you need to focus on the individual (smallest units) of responsibility and build the complexity up.

Start by ditching the form designer and building your UI's by hand. This will help teach you ways of generating complex UI's through the use of different classes as well as layout tricks that the form designers really don't encourage.

Once you can do this reasonably well, you could start to use UI designers to speed up the process, allowing you to quickly generate the layouts and combine them (remember, you can add any component which is within your projects classpath to your form, not just those which are in the palette)

Community
  • 1
  • 1
MadProgrammer
  • 343,457
  • 22
  • 230
  • 366
  • thanks for your advice. We are now writing the system by hand so to practice good design and learn it further. Your answer is lengthy but very informative for students like us. Thanks again. – heisenberg Jan 14 '16 at 04:52