in Getting started by

Dear Tara-Systems

In my first project, I structured the GUI elements and divided them into groups such as:

  • Screens
  • Views
  • Controls
  • Data Model
  • Device Drivers

And I did find that approach pretty handy back then. Now in some newer type of projects it seems to me that you have split your projects from another angle. It seems to me you have split it into functionality/use case. For example (not an existing project, but you will get the point; Also I could be completely wrong about this as well):

  • Position Control
  • Feeder Managing
  • Product Settings

To me this approach makes sense now because I have seen some complications with big EWU files and GIT; especially when working on a project cooperatively.

So I wanted to know: Have you some design guides (plus reasons) that we all can read and adapt before stumbling on the hurdles ourslves?

Also thank you for providing something like the master classes. They help(ed) quite a lot.

1 Answer

0 votes

Hi Treeview :-)

Basically there is no real "wrong" or "right" project structure, it always depends on your needs and especially the project size (feature set, amount of bricks ...).
However, if you have chosen the "best" one for your project, you will be way more efficient.

In a very small project 
it makes sense to put everything into one unit, but nicely separated with annotations (which is always a good idea):

In smaller projects
it is recommended to use a simple structure similar to yours:

In bigger projects
you tend to use one unit where you have used "bigger" annotations previously.
Just because you want to keep the overview. Example:

GUI units:
- Application
- Components (e.g. Widgets)
- Screens (e.g. full-screen components that contains several view/widgets)
- Popups (if you have a lot, otherwise could be part of Screens)
- Menu (especially if you have a bigger one)
Resource units:
- Bitmaps
- Fonts
- Colors
- Constants
Data units:
- Data (non visual components, e.g. linked-list implementation)
- Device (everything that belongs to the device interface, communication with "middleware")
- Global (e.g. could contain global helper functions or temp. data)
- Strings
- StringsInstructions... (further String units, because you want to have different Strings Excel files)
Further units:
- Simulation
- Tests
- ...

In big projects 
in addition you also make use of "generic" units that are sharable between several projects:

Two things are interesting in the image above:
1. Use a directory for an unit, which can be used as an external (own repository): you fix a bug there and it is fixed for all projects
2. Use the Split: it creates not one ewu file, but one ewu folder with ewui files (now collaboration makes fun again!)

Overall the units should be self-explanatory and as soon as you get frustrated (being inefficient) by scrolling all day long up and down or even searching for something, it is recommended to break this unit down into more: Instead of unit "Settings" -> use unit "SettingsSound", "SettingsVideo" ...

In some projects we even create one unit per feature. This looks good and could make it easier to enable/disable entire features. Apart from that this is really nice if you work with several people on the same project where everyone is responsible for another feature/unit.

Many customers also generate ewu files nowadays. So, not only the String.ewu is generated, but also e.g. an Enum.ewu or an unit with all the data points/bindings. Having one source is the main advantage of the generation (e.g. one Excel file generates an ewu file + header file for middleware). Don't activate the Split here of course :-)

However, please don't start with too many units. I would start with something reasonable and then think about a refactoring of some parts every 20% of the project. For example: At beginning you have one unit "Res" with all Fonts and Bitmaps, later on refactore this to two. Thanks to Embedded Wizards refactoring ability, this takes only some less minutes (re-position bricks), but you will feel way better :-)

Hope this helps a bit :-)

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint