What is a good practice for the below scenarios?

This is my first time building an app, so I am worried about the stability of my application and want it to be as lite and simple as possible, I understand the simplicity of the app is in my utilization of the blocks and proper logical coding, I would like to know if its ok to use objects(?!) like Firebase / notifiers / clocks multiple times in one screen For ex:

Like shown above, just for the convinience or should i use multiple if-else and fewer (or just 1) blocks in each screen to handle different scenarios/needs.

I hope its not such a noob qs! (even if so an an answer would be nice :grin: )

Thanks in advance!

See, this thing completely depends on how you are comfortable. Your code is your choice. Everyone has different comforts and it just depends.

Some people like to use multiple if-else and some like to do it in a single go but only you know what suits you the best so go with your gut feeling.
And BTW best of luck on your journey. :wink:

Thanks.

I subscribe to the notion that no man should work for two bosses.

Likewise, no component should serve more than one purpose.
I say this because I need simplicity in what I code, to make life simple for me when I revisit my code.

Naming my components fully is important to avoid confusion, like btnConfirmLaunchWorldWarIII vs btnOkay.

When I use database components for specific purposes and in specific contexts (like Get today’s schedule for Update), I get the benefit of having my completion event know just what it has to do, without an if/then/else tree and the worry of having to keep yet another global variable to tie my app up in knots. (https://docs.google.com/document/d/1ccG7Nv_uRfRzGADaz17Jez9NjV0yBKqFTsuOo4iAixY/edit?usp=sharing)

Clock components are another matter, though. There is only one axis of time, and on that axis of time we can keep tables of deadlines to check for various actions. A single Clock1.Timer event can call a sequence of deadline checker procedures, each with its own deadline global variable. It can also service a queue of things to manage. (Changing Sprite in Blocks)

Notifiers are tempting to use, but they require name discipline to make clear how to respond to button choices, and to tie them to the Designer dialog and blocks that trigger them, otherwise they hang around as spinster orphans. Nested sub-Arrangements can make good notifiers, with the advantage of grouping confirmation buttons under the parent Arrangement umbrella of their initiators.

1 Like

@ABG Thanks for sharing some additional info as well :+1: