Prioritizing delivery methods

Overview

The ability to very strictly restrict the environments in which each delivery method can be used provides an aspect of flexibility in determine how your application should be delivered but the key to securing the exact app delivery strategy that fits best with your requirements is the ability to order the defined delivery methods, assigning each a priority that dictates the exact conditions under which it should be used.

Being able to picture exactly how your selections will be applied in each of your real-world environments can take some getting used to but this article should give you a good grasp of the concepts and how you can utilize them to provide the right experience for your users. 

How does priority work?

The basic concept of delivery method priority works exactly as you would expect. Using the drag and drop interface provided when editing the delivery methods for an app, you assign each delivery method a priority from top to bottom, where the topmost delivery method has the highest level of priority. The priority that is currently assigned to each delivery method is shown in the blue circle and updated when you click the Save Order button. 

Of course, on it's own, the priority isn't much use, as the first delivery method in the list would always be chosen! That's where the restrictions come in to give us the idea of "smart prioritization".

To give you an idea of what is actually happening, each time a user logs into AppsAnywhere on a particular device, AppsAnywhere first looks at the restrictions applied to each delivery method and rules out all those that are not permitted. Once it has done this, it looks at the delivery methods that remain and then takes their priority into consideration to decide which one to offer to the user. 

A simple example

Consider the situation where we have an application that can be delivered by Cloudpaging or through a VDI/RemoteApp session. Obviously our preference would be to deliver the app via Cloudpaging, as it doesn't require the allocation of server resources to run the VDI session, however, Cloudpaging might not always be available. 

The most obvious restriction that applies to Cloudpaging is that it is only available on Windows devices. If we were to visit the AppsAnywhere on a non-Windows device then you can see that this delivery method would no longer be available which lends us to a scenario where the second preference, the delivery by VDI, could/would be used. 

This is the simplest example; if the user access AppsAnywhere on a Windows device, then the app is launched via Cloudpaging, otherwise it is launched in a VDI/RemoteApp session. Either way, the user gets access to the Windows app and we reduce our use of VDI to the absolute minimum (rather than relying on it by default). 

Of course, operating system compatibility isn't the only reason you might choose not to use a particular delivery method, you also three other restrictions at your disposal:

• Is the device on-site?
• Is the device owned by the institution?
• Is the device joined to the domain?

By applying these restrictions to your delivery methods either instead of or in conjunction with the OS restrictions, you can further tailor the delivery workflow. Back to our example, let's assume you are delivering a strictly licensed piece of software. In this case, you may set Cloudpaging as your first preference, but only on Windows devices (obviously) that are joined to your domain. Additionally you may restrict the second preference delivery method (the VDI/RemoteApp delivery) to on-site devices. This means that the app can be used natively on managed devices, or on un-managed devices through VDI, but is completely unavailable in any other scenario. 

This simple example is already getting rather complex, but hopefully you can begin to see the power of smart prioritization. 

Unleashing the power

Let's take a look at a far more complex example, with 7 different delivery methods that are being used to support many different types of devices in a multitude of different environments. 

The examples above should reflect the process with which AppsAnywhere determines the delivery method that should be used in each environment; first ruling out all those delivery methods that do not apply to the particular environment and then choosing the one with the highest priority of those remaining. 

Generally speaking therefore, you should strive to consider for each delivery method which environments you wish it to be used in and apply the restrictions accordingly. Once you have done this, you can start defining your priority preferences. In most scenarios, the more restrictive delivery methods will be given a higher priority to ensure they are used whenever the particular environment they apply to is presented with the less restrictive delivery methods 

Mutual Exclusivity

Without wanting to complicate things too much, it's worth adding a note about delivery method restrictions that result in them being mutually exclusive; that being that they would never both be available on any single device. 

To explain this concept, consider the iOS and the Android delivery methods in the example above. The iOS delivery method (an external website link to the Apple AppStore) is only available on iOS devices, while the Android delivery method (and external website link to the Google Play Store) is only available on Android devices, as specified by the administrator in the operating system restrictions for each delivery method. 

Quite clearly, there are no devices running both iOS AND Android and therefore there is no scenario where both of these delivery methods would be considered as possibilities. In this case, it makes absolutely no difference in which order these delivery methods are placed, respective to each other, only how they are placed in the list relative to other delivery methods that might apply on those devices. 

If, for example, they were the only two delivery methods, it would not matter the order in which they were placed as the iOS delivery method would be the only one available on iOS devices and the Android delivery method would be the only one available on Android devices and as such the priority would never even be considered. 

Looking back at our example above, it does not matter where in the list they sit, or their priority respective to each other, as long as they are both above the delivery method shown at the bottom of the list in the example, as that is the only one that also applies to those devices. 

Simple when you think about it...