Learning the MVA Framework - Tutorial 1: Start by Stopping

- By Chris Cilino, Composed Systems Partner

I recently became a partner at Composed Systems in July 2019.  I hope you'll join me in my journey as I come up to speed on our tools set. One tool I want to highlight is the MVA Framework. The MVA Framework accelerates our development and give us flexibility to rapidly respond to changing requirements. And it can do the same for you since Composed Systems has made the framework open sourced.

I've found that I learn best when I first personally succeed at a task, and then share that knowledge with others. So I'm blogging about my journey to master the MVA Framework.

All of the tutorials are available at the  MVA-Tutorial Bitbucket Repository. Each tutorial is a LabVIEW project designed to present the smallest set of concepts possible to accomplish a meaningful task. And each tutorial builds on the concepts of the previous one. So DON'T SKIP!

To view any of the tutorials
1. Clone the repository using Sourcetree (or your favorite Git method).
​2. Install GPackage manager.
3. Open GPackage manager and navigate to the directory containing the LabVIEW project for a given tutorial.
4. Install the dependencies:

5. Use this blog in conjunction with the comments on the block diagrams to go on the journey with me.

The longest journey begins with a single step, so what better way to start than by learning to stop? Wait for it.... here's what I mean. Whenever I learn a new framework or look at someone's code, my very first question is "How does it stop?"  In learning how code stops, I find I learn the most fundamental notions of the code. So that's where I'll start with the MVA framework (hence the clever title "Start by Stopping").

In this first tutorial I'm sharing how I migrated the following application into an MVA application.

There's nothing terribly fantastic about this VI. It's designed to start, wait for the Boolean button value change, and then stop. The MVA framework allows us deconstruct the front panel and block diagram into more granular parts you can programmatically interact with. Deconstructed food is a good analogy here, mostly because I like food. You might be used to a hamburger that looks like

But the MVA Framework deconstructs it to look like

so you can eat any part independently of the other and in whatever order you'd like.  Let's deconstruct our VI into is separate parts. 

First we will split the front panel from the code by using subPanels, and we'll insert our UI into something designed to host UIs. I'm going to concentrate more on "What we are doing" and less on "Why" for the time being.

We'll make both the thing hosting the VI (aka the "hoster") and the hosted VI Actor Framework actors.
​WAIT! Actor Framework?! Ruuunnnn!!!! Deep breaths...before panic sets in, I'm a noob with the Actor Framework (AF), so I'm with ya. There isn't much AF stuff you'll need to know to use the MVA Framework. You'll see... just keep with me. 

To create the "hoster" MVA actor

1. From a LabVIEW project right click on "My Project" and select "Actor"
2. Inherit from \gpm_packages\@cs\mva-framework\Source\Framework\IViewModel\IViewModel\IViewModel.lvclass

To create the "hosted" MVA actor

1. From a LabVIEW project right click on "My Project" and select "Actor"
2. Inherit from gpm_packages\@cs\mva-framework\Source\Framework\IViewable\IViewable\IViewable.lvclass

​
So this is what we're putting together.

Next we cut up the block diagram and represent elements of the block diagram with VIs. The while loop becomes the actor core and, instead of the event handler, we introduce an API to Register For Control Events. The VI used to register for events is called "Register For Control Events.vi" and looks like 

 Path: gpm_packages\@cs\mva-framework\Source\Framework\ActorEvents\IEventAggregator\Register For Control Events.vi
We pass in an array of control references to dynamically register to an event handler (we'll get there). We also pass in an array of event types we want to handle. In this case we are saying "Something execute when the value of "stop" changes." In effect the code above is a programmatic version of:

Since we have two actors running (our hoster actor and hosted actor) we want our stop command to be handled by the hoster. The MVA framework propagates the "stop" to the hosted Actor. So we need to create an override in the hoster called "Catch Nested Value Update.vi". While each UI can (and often does) handle each value change event, stop is a little special because we want to close the hoster as well as the hosted VI. So in the hoster we create an override of "Catch Nested Value Update.vi". This VI is designed to handle messages sent from any sub actors or "nested" actors. The block diagram of the override looks like:

In the override we use an MVA function called "Unpack Nested Value Update" that outputs the label and value of the registered item (in this case the "stop" button). So in the "stop" case we stop the hoster actor which will in turn stop the hosted VI.

So now we'er almost done! We just need a "chef" to assemble our deconstructed hamburger on the serving plate. In every MVA application, the "Assembler" is responsible for inserting actors into actors. Let's take a look at the Assembler of our application. 

I've added pictures and comments in the code to explain what's going on here. The red class is the hoster and the purple class is getting hosted. We use the MVA framework function called "Construct MVA Application" to stitch everything together. The "IViewModel" is the hoster (red class) and, in this case, the startup view is our UI being hosted (IViewable, purple class). When the program starts the MVA starts the actors and stitches them together. 

What?! All that work for...??

Soooo what gives? This seems like a whole lot of complexity for not a whole lot of return. Here's the payoff:

1. I can easily swap out the purple class for any other class instantly without changing anything else in the code. And at this point, all we assume is the hosted VI is sending a "stop" message. (actually, the hosting vi automatically handles the panel close event too!)
2. Developers can work on separate sections of the UI without stomping on each other's work.
3. UIs become more modular. It's almost like we are developing "widgits" of a UI instead of monolithic sets of code.

In the next tutorial I'll show how the MVA framework let's us have N widgets in a UI working together. We'll start with "A Community of Two". So stay tuned!