UI Actor Functionality In Message Handler or Helper Loop?

[PsyenceFact]

I'm using an actor as a UI which performs various FP actions depending on its state ("Idle", "Arm", "Acquire", and so on).  Some of the state changes are triggered externally by sending a message from the parent, some are purely internal based on user actions.  At the moment I deal with these by sending self-enqueued messages.  The UI state is stored in the actor private data.

For some user actions, I need to check the UI state before proceeding.  This is done in the appropriate message handling VI, i.e. by a VI in the actor class, not in any part of the message class.  This results in a fair amount of UI manipulation code in the message handling VI.  I have a vague feeling that this should be done in the helper loop of actor core rather than through a message since it is purely an internal affair, but this means I need access to the current UI state in the private data.  I could always keep track of the state in a helper loop shift register but then it doesn't get updated from the externally called messages...

Is my vague feeling wrong?  Is putting much of the code for "internal" functionality in message handling VIs good practice?  If the corresponding message classes are private to the UI actor library it at least prevents them being called externally.

I suspect that my vague feeling may be down to being relatively new to the AF and still trying to adapt to the architecture, but any advice gratefully received.

Andy

[Oli_Wachno]

Hi Andy,

sorry, for not being able to return a simple answer....

1.) How to handle states with AF

You can perform state handling within the MHL, in simpler cases maybe even in the Helper Loop. The problem --> this approach is not really scalable.

I'd highly reccommend the State Pattern Actor. Yet be aware, it takes some time to get into this.

2.) Decoupling View and controller

For a simple UI, it is convenient to have Actor Core.vi also implement the UI functionality. WIth increasing complexity and better scalability, you might want to use two Actors: one as a Controller taking care of the business logic and  "stupid" View Actor just executing messages sent by the Controller Actor. (Remark: I left out the Model here)

The two points above provide a guidance how to create a "clean" application. YAGNI - you ain't gonna need it. Especially not if you are still a newbie to AF. Yet you should keep an eye on this.

If the application was small and I decided on having an Actor "doing everything" , I'd probably go for state handling in the MHL, but having things that need some more time to execute handled by (an additional) Helper loop (--> dynamic user events)

Does this make sense?

Cheers

Oli

[Taggart]

---

@PsyenceFact wrote:

I could always keep track of the state in a helper loop shift register but then it doesn't get updated from the externally called messages...

---

Whatever you do, I recommend avoiding this at all costs.  It will only cause trouble.

[PsyenceFact]

Thanks for the replies.

@Taggart: I really didn't think this was a good idea and could only see it causing problems.

@Oli: I think my problem is more that I'm shifting existing code in to AF and some of the decisions that I originally made about structure and methodolgy are now less valid.  Different mindset required.  I already have the View and Controller decoupled to a certain extent and most of my TCOB logic is in the actor that launches this UI actor.  Thinking about it further, the state would be better handled in the caller and (as you suggest) the UI becomes more dumb.

Maybe my question should have been "To what extent might having a lot of code in a message handling VI compromise the actor message handling speed?"

Andy

[Taggart]

You could do the logic in the caller, but you could also do the logic in the parent, and have a child that adds a UI.

[auspex]

It sounds to me like you need to create some user events. The air cooler demo has examples of a user-created stop event. Tom McQuillan's videos do a good job of explaining.

In my opinion, the UI state should be in the UI. It should be in the shift register of the while loop around the event handling structure you add to the Actor Core.

The actor state should be in the class data.

Changing the actor state could change the UI state by generating user events.

Changing the UI state could change the actor state by sending messages to the self enqueuer.

If the actor needs to check the UI state before doing something, it will never do anything because the UI state could change in between checking it and doing something, so you have to check again, and again, and again.

You have to protect your machines and forgive your users. You may need to put delays into the system to do this, similar to Schmitt triggers in electronics. Rather than having the push button with the green light, you want to have an OK button with a round LED next to it. Pressing the button sends sends a message to the actor which then sends a user event to light the LED if everything works. Or you could just pop the push button back out if the state can't stick.