Battletech Live

Online, Turn-Based Battletech – Development Logs

Local Connections are a potential lifesaver

For the readers who have been following along, I’ve been working on a problem for quite some time.  The main application file contained most of the structure for how the site worked, while detailed components such as the calendar, email and avatar selectors were built as separate modules that were then loaded into containers.  The problem is that the code necessary to enable a module to be loaded and to be fully referenced took up 400kb, making the main file anywhere from 600kb up to 1.1mb, depending on how much or how little I stripped out of it.  It seemed that the more I removed, the larger it got, needing to keep references around to make the other modules usable.  I followed a comment from a user, stating that the main file should be extremely small and should contain very little except the code necessary to load a single module, which would then act as a loader for everything else.  That’s where my big issues began.

When I moved the primary constructors out of the main file, inter-module communications fell apart completely.  I could load modules in, but I had no way to send data between them.  I’ve now started working with Local Connections, which are proving to be extremely beneficial.  A Local Connection is essentially a pipe that is connected between two modules and is one way.  They allow variables to be passed from one to another, as well as for functions in the target to be called.  For example, a login box allows a member to sign in and upon completion, an image in an accounts module needs to change to reflect who is signed in.  However, the login box is incapable of saying “acctBox.memberPic.source=pic;” because one module doesn’t have literal access to objects and functions of another module.  Instead, the login box processes the signin as normal and retrieves a number to represent the users picture.  It then creates a connection to the accounts panel, passing it the connection name, a function name and a variable.  The accounts panel then executes the function it’s told to run and uses the variable passed to it to set the icon.  It’s actually extremely simple, it just sounds complicated.

The big thing is that any single connection name should be reserved specifically for one sender and one recipient.  If one module has a need to at times, send information to three different modules, then it needs three connections.  Then, if one of those modules needs to send information back to the first module, a separate connection is made.  The easiest way to organize this is to set the name of the connection as sender_recipient so that everything always ends up in the right place.

I’m going to get started on this tonight, but I expect it to solve at least 80% of the problems I’ve been encountering.


June 29, 2009 - Posted by | Project Development


  1. Wile LocalConnections work, they’re kind of a pain to set up. I started out with my primary application file plus three modules. Three are loaded directly, so are children and one is loaded as a grandchild. The main application stores the variables for who is logged in, then passes that information on to the children so that they can do their own processing. Every LocalConnection defines a name, a connection name and one or more variables or objects to be passed from the source to destination. The name and the connection name must be unique per module, so the main file has one connection for every other module that it sends to, plus one for every module that it receives from. So, if my brain math is right, the maximum number of connections, if every module has some occasion to need to talk to every other module, would be modules * (modules – 1), each with a unique name and connection name, making things hectic. Once up and running through, it works great.

    Comment by Charles Shoults | July 1, 2009

  2. When the application loads up, it starts a 30-second timer. It then instanciates each subordinate module and adds an event listener to each. When each reports a ready state, an icon on the main window changes from gray to green and a conditional statement is placed into the tickTrigger, only firing events to those modules if they report ready. In addition, a number of counters are set up so that certain events trigger at specific time intervals. For example, checking for new mail, forum posts and development updates takes place every 5 minutes, while online status is updated every 30 seconds. Other events, such as logging in our out, sending mail or entering a forum post, take place immediately, so are handled outside the tickTrigger.

    Comment by Charles Shoults | July 1, 2009

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: