DSI SubApps: May the Force Be With You

Beep Boop Beep,” said a famous astromech droid while fixing the hyperdrive of the Millennium Falcon evading a fleet of enemies.

Now the fact that this droid was able to actually fix something should be no surprise due to it being a droid. But what exactly enabled the droid to get the job done?

Well, the short answer, for the sake of my story, is that its programming was written using the DSI framework. But the long answer dwells within a particular hyperdrive SubApp. Which then begs the question, what is a SubApp? Also, what significance does it hold when writing programs for other droids so that they too can perform the same feat?

SubApps – A New Day, a New Beginning

A SubApp is a modular function that can be called from within applications, other SubApps, subroutines, and events with relative ease.

In the screenshot below we see inside the SubApp that provided that famous droid with the ability to save the Millennium Falcon and its crew, under the ID – FX_HYPRDRV. While a SubApp is similar to a subroutine, the exception lies with the fact that subroutines are restricted to being used from within the applications, forms or SubApps they’re written in. In the case of FX_HYPRDRV in the screenshot below, the four subroutines cannot be called externally.

SubApps are modular functions which can be called externally, unlike subroutines whose scope is limited to the domain they are defined in.

Mobile SubApps

But, Why SubApps?

Now that SubApps have been distinguished from subroutines, what would be a notable reason to use a SubApp, versus a subroutine?

As a SubApp is a modular approach to subroutines, it provides flexibility and efficiency to applications that would otherwise not be possible with just subroutines, given their limitations. We understand the fact that a call can be made to a SubApp across multiple applications that may need to perform the same functionality. So, lets apply this to multiple droids that require the ability to repair hyperdrives. Take a look at the screenshots below for an illustration of this.

We currently have two astromech droids that need to be programmed:  R5-D4 and U9-C4. While we could in fact just go into each individual application for each droid and write out the same subroutines that we wrote for the SubApp FX_HYPRDRV, like so:

….this causes a developer to repeat unnecessary code and waste time when they can utilize the power of the SubApp and apply it once to each droid’s application. For example:

(Notice the subroutines from the screenshot above have been deleted as they are no longer needed)

Now we have all our droids up to standards with our heroic droid. The galaxy is one step closer to outstanding astromech droids that can fix hyperdrives in dire situations with tact and precision!

What Did We Learn About Mobile SubApps?

If it is not already apparent that SubApps are quite powerful, then reiterating when and where they can be used should shed light on their scope.

SubApps can be called from within applications, events, subroutines and SubApps (thus becoming nested SubApps).

So when would a developer want to take full advantage of utilizing SubApps?

  • Seeking to leverage the same functionality across multiple areas within an application (or applications – such as with the droids)
  • Encapsulating code in order to keep it organized, logical and modular
  • Avoiding unnecessary duplication of code and making maintenance a breeze

For more information on SubApps and how to build them within the DSI framework, please look into registering for a course with DSI here.

The Extra Perk of SubApps

By taking full advantage of SubApps, the DSI developer is adhering to good principles such as the DRY principle. By not repeating code unnecessarily, and encapsulation by encompassing logic and functionality, it makes the overall flow of the application much cleaner, understandable and maintainable.

There’s more to explore at Smartbridge.com!

Sign up to be notified when we publish articles, news, videos and more!