B4J Question Structure of a program

[Coldrestart]

Hello everybody.

I am working on a bigger project where I have several classes.
The application will read data from a textfile, buffer it locally, and send it to an mqtt broker.
It has also a GUI to configure settings and check if it is working ok.

When the "read csv" class fails to read the file, the gui must be updated to inform the user that something is wrong.
What is the best way to pass this to the main or gui class?

To make the program as modular as possible, I have made a drawing where I have three approches.

Approach 1: This is the best to prevent randomly call multiple classes, it is more in a parent/child way.
The disadvantage is that i will have a lot of call's in my core class, which can become "messy".

Approach 2: Use a dataclass, more mixing of classes. Quite "simple" to do.
Not a real event driven way ...

Approach 3: Simple event driven, still the main class wil get big. When to program grows, this can get also a mess.

What is the best way to handle these events between classes?
How do you add structure to your programs?
Any advice?

Thanks in advance,
Coldrestart.

 

[William Lancee]

Others will have more comprehensive answers, but I would just add a polling routine to GUI or Main.
This routine will not interfere with normal execution - put it in a sub and let it run.

Edit: It is not really different from a well placed call back.

Do While ReadCVS.isOK        'where ReadCVS is class instance and isOK is Public
    Sleep(200)
Loop
'action if not OK

 

[BlueVision]

It's difficult to give advice, as it always depends on the programme itself and its purpose.
Personally, I would prefer variant 3. Old and proven programme style. In other words, the main load remains with the main programme as master. Regardless of this, the additional modules work, but only have intelligence for the job they are supposed to do. I would also not allow the additional modules to communicate with each other (apart from a few necessary exceptions perhaps). The main programme then polls the additional modules and retrieves the new data, updates the user interface, saves the data in a database, etc.
This may be a bit ‘oldschool’, but it makes troubleshooting and adding new add-on modules much easier later on. You remain more flexible in the long term.
Once the programme reaches a certain size, the whole construct may become confusing at some point, but this cannot be avoided. Good documentation in the source code is therefore really important.
In this way, I have created a programme that has grown more and more over the years and now contains 14 additional modules. In this case, however, they do not run simultaneously, but are switched on and off as required via the programme logic in the main.
In the course of developing the programme, however, I also reached the limits of the system. This concerns the layout, for example. If it is foreseeable that there will be many very different user interface views, then don't try to pack the code for this into a single designer script. Stay modular by programming a pane into which you then load the layout you need. Designer scripts are limited to a size of 64 kByte.

In the end, you are on your own. Don't take my tips as instructions or manuals, every programmer has it's own style of programming. That's why it's difficult to help you in making a decision.

 

[Coldrestart]

Thanks to all for your time and the advice.
I was wondering if I could make the program more flexible by the use of parent/child classes, but I need to admit that, when there are also a lot of events, instead of being more simple or structured, it's getting more complicated.

 

[BlueVision]

instead of being more simple or structured, it's getting more complicated

The nature of complex applications...
This is normal. You have an idea in your head and naturally want to realise it quickly. It's good that you think about the architecture of the programme first, that's the right approach. Don't be afraid to put flowcharts or something similar on paper. It helps immensely.
Let the programme grow slowly step by step, pay particular attention to the interfaces for the parameter transfers and document everything in the corresponding line of code. Nothing is worse than wondering later on what the idiot programmer was actually thinking and you no longer understand your own code.
Then your project will be a success. Don't let yourself be driven by temporary problems that occur again and again. Don't try to solve them quickly with ‘dirty’ workarounds. Patience is really required here. And if you get stuck, don't be afraid to ask for help here in the forum. There are plenty of members here who will get to grips with your problem and support you. In this case, describe the problem as precisely as possible, it must be comprehensible. You know all this yourself. Try to fix all warnings in the IDE right from the start and pay attention to exact variable declarations.

My project ‘SHARK’ (a collection of tips, data and media, structured for the requirements of a technician who repairs machines at the customer's site) has now more than 12000 lines of programme code). With a fast SQL database, links to the web and much more. It's not an egg-laying wool-milk sow (a German expression, I hope the meaning comes across in the translation), but every day I get grateful emails and tips from technicians. And that's the next problem: they want more and more and it's becoming increasingly difficult to keep the data up to date...

 

[Coldrestart]

I cannot agree more that a drawing/flowchart says so much more then a lot of text.

Thanks for your advice, I will give it a try.

 

[MicroDrie]

Something you could also look into to follow Erel's advice by developing your program with B4XPages. A B4XPage is basically a class that allows you to implement specific functionality. It is possible to use a variable and public subroutine from a B4XPage without opening this page. This way you can easily add and maintain functionality.