Applications are useless without data

Take a word processing application for example. Without data, the word processing application is really stupid. As soon as you start typing a document, you are creating data.  The application is just a mechanism for creating or consuming data.  And, in a lot of cases, this data is interchangeable between applications.  In other words, it is the data that is important – not the application.

Applications are just a data access layer

I like programming and a staple of any good programming language is object orientation. One of my favorite design patterns is called a façade pattern. The definition of façade is “the face of” something. So a façade in this case is the face of an object. The “face” is easily switched out, but the underlying objects remain the same (loose coupling).

Let’s relate this to applications. Applications are the façade to the data. Let’s take our word processing example again. I personally use Microsoft Word (for Windows and Mac), Google Docs, and iWork Pages. All these programs access the same data and they are easily switched out, so they are the face of the data. Dropbox (and more recently GDrive) keep my data where I need it, so those things are completely different facades to the exact same data. I can get my data on a fat client, web, mobile, offline, etc.

Consumerization and Cloud is driving the trend

Mobile devices have exploded and BYOD is gaining popularity. These 2 trends are directly associated with user demand – not IT demand. Brian Madden put it well on ConsumerizeIT.com – “The new reality: The IT department has to compete against every random app & website out there!”

Let’s look at another example that is more consumer related.  When I purchase an online book from Amazon, I’m paying for the data (book).  I then have a choice of interchangeable applications that can be used as the face of the data – many versions of the Kindle, multiple iOS applications, multiple Android applications, multiple Windows applications, etc.)  The application is much less important than the data.  Consumers are getting used to freedom of choice and everything “just working.”  The same will creep into the enterprise and IT will need to cope.

So now what?

Windows applications aren’t going anywhere anytime soon, so we’ll still be delivering those for quite some time. However, I see where the application is less important and we’ll be thinking more about data security, offline data, application and platform choice (Windows, Mac, Linux, mobile, web, etc.), data integrity, etc.  Or, perhaps I’m way off here.  What do you think?

Further Reading

VDI, ok? What’s next? Stephane Thirion http://www.archy.net/2012/05/31/vdi-ok-whats-next/

The VDI Party is Over. Benny Tritsch http://drtritsch.com/2012/05/the-vdi-party-is-over

In the previous version, the responsive design code only kicked in on session initiation (i.e. logon) – meaning if you started a session on a fat client and then reconnected to the session on a mobile device, then the fat client display would show up on the mobile device. We don’t want that. So, by catching the reconnection event, we can re-style the app at any point (session initiation or reconnection). Start the application on a fat client and then reconnect via a mobile device and the mobile style will kick in (and vice versa).

Here’s the bit of code to take care of it (if you don’t care about the code and just want to skip to the download, just follow this link):

[DllImport("WtsApi32.dll")]
private static extern bool WTSRegisterSessionNotification(IntPtr hWnd, [MarshalAs(UnmanagedType.U4)]int dwFlags);

[DllImport("WtsApi32.dll")]
private static extern bool WTSUnRegisterSessionNotification(IntPtr hWnd);

private const int NOTIFY_FOR_THIS_SESSION = 0;
private const int WM_WTSSESSION_CHANGE = 0x2b1;
private const int WTS_REMOTE_CONNECT = 0x3;
private const int WTS_REMOTE_DISCONNECT = 0x4;
private bool registered = false;

protected override void OnHandleDestroyed(EventArgs e)
{
    // unregister the handle before it gets destroyed
    if(registered)
        WTSUnRegisterSessionNotification(this.Handle);

    base.OnHandleDestroyed(e);
}

protected override void OnHandleCreated(EventArgs e)
{
    base.OnHandleCreated(e);
    registered = WTSRegisterSessionNotification(Handle, NOTIFY_FOR_THIS_SESSION);
}

protected override void WndProc(ref Message m)
{
    if (m.Msg == WM_WTSSESSION_CHANGE)
    {
        if (m.WParam.ToInt32() == WTS_REMOTE_CONNECT)
        {
            // The session is in the reconnect state, so style the app for the new session
            setAppStyle();
        }

        if (m.WParam.ToInt32() == WTS_REMOTE_DISCONNECT)
        {
            // The session is in the disconnect state, so close the CMP if it is open
            if (this.cmp != null && this.cmp.IsChannelOpen())
            {
                try
                {
                    this.cmp.CloseChannel();
                }
                catch {}
            }
        }
    }
    base.WndProc(ref m);
}

Try It Out Yourself

Want to try it out yourself?  I have made the program and the source available so you can beat it up and come up with some more ideas.  You can download it here.

Applying Responsive Design to Enterprise Applications

Just like web pages, enterprise applications are starting to get viewed on a myriad of devices.  What if we could take some of the same techniques web designers are using and apply that to enterprise applications?  Well, as it turns out, we can with the help of the Citrix XenApp 6.5 Mobile Application SDK.  By using the Mobile Application SDK, enterprise applications that are hosted on a XenApp 6.5 server can respond to the type of device using the application.

Responsive Application Example

As an example, I wrote an application that takes data from EdgeSight about the types of Citrix clients used in an environment.  The application displays this information in a chart as well as a table.  I then published this application from AppCenter on a XenApp 6.5 server and launched it using a fat client.  You will notice that both the chart and the data table are shown as well as a menu strip at the top to select a chart type.

Now, if you launch the exact same application from the exact same server using a mobile device, some very interesting things happen:

1. Only the chart is shown initially.  If you rotate the device, only the data table is shown.
2. The application’s window chrome is gone.
3. The width and the height of the application were changed to the width and height of the device.
4. Tapping the chart image brings up the device’s native picker.
5. Changing the orientation of the device changes the display.

Check out this short video for a demo:

Try It Out Yourself

Want to try it out yourself?  I have made the program and the source available so you can beat it up and come up with some more ideas.  You can download it here.

There are 2 parts that you need in order to develop applications that utilize mobile capabilities on a XenApp 6.5 server:

1. The XenApp 6.5 Mobility Pack – this is the part that goes on the XenApp 6.5 server.
2. The Citrix XenApp 6.5 Mobile Application SDK – this is the part you use to develop mobile applications.

XenApp 6.5 Mobility Pack

When you install the Mobility Pack, 2 new services are added to your XenApp server:

1. Citrix Location and Sensor Virtual Channel Service – this service enables a server side application to leverage Location and Sensor capabilities.
2. Citrix Mobile Receiver Virtual Channel Service – this service enables a server side application to use mobile device capabilities.

These 2 virtual channels are kept separate for security reasons.  Maybe you want to have mobile device capabilities available, but you cannot enable GPS features due to security compliance.  Location services are disabled on the Citrix Receiver by default. The way to enable the location capabilities is via Citrix policies.  In order to use these policies, you will need to install the Citrix Group Policy Client-Side Extensions.  These extensions are part of the XenApp Mobility Pack .zip file.

This policy is located under ICA\Client Sensors\Location. Notice that by default, location is disabled.

Citrix XenApp 6.5 Mobile Application SDK

So, the requirements for the Citrix XenApp 6.5 Mobile Application SDK state that you need Windows 7 64 bit (and the MSI is even named XenApp65MobileApplicationSdk64), but it installs to ..\Program Files (x86)\Citrix\MobilitySDK\.  I tried installing the SDK on a Windows 7 32 bit system as well and it worked, so I’m not sure if something absolutely will not work on 32 bit.

I’m using Visual Studio for the examples.  It appears that Visual Studio Express (free) will work as well, but I haven’t tested that myself.

Anyway, the documentation that comes with the SDK is pretty comprehensive so I’m not going to rehash it here.  Since I will be showing you some of the examples using .Net, I do want to point out that you will need to run one of the following commands on your development machine in order for things to work:

Regsvr32 cmpcom.dll

Regsvr32 cmpcom64.dll

Notice that there is a 32 bit or a 64 bit DLL register. So again, not sure why Windows 7 64bit is a requirement for development. Anyway, make sure you run the appropriate command above as administrator, otherwise you may receive an error stating “The module was loaded but the call to DllRegisterServer failed with error code 0×80070005” (which is a permissions error).

Compiling Examples

The final part of this article will focus on compiling and using the examples that come with the SDK.  The one I’m going to point out here is the picker example.  This example uses the native device’s UI to display a list of options.  The example is actually a console application that has no graphics, so it is actually using the local device’s display mechanisms rather than trying to do some trickery on the XenApp server side.  So, here we go…

1. Browse to \Program Files (x86)\Citrix\MobilitySDK\samples\native\showpicker
2. Double click on showpicker.sln to open the solution in Visual Studio
3. Build the solution by pressing F6
4. This will create an executable in \Program Files (x86)\Citrix\MobilitySDK\samples\native\Win32\Debug\showpicker.exe
5. Copy this showpicker.exe to your XenApp 6.5 server (I copied mine to \Program Files (x86)\Mobility\picker\showpicker.exe)
6. Publish the application via Citrix AppCenter
7. Launch the published application using an Android device (or emulator) with the latest Citrix Receiver installed.

NOTE: You may receive an error message that states “The program can’t start because MSVCR100D.dll is missing from your computer…”  Here’s why – the solution was built in debug mode.  Thus, debug DLL’s (notice the “D” in the DLL name) need to be on the XenApp 6.5 server.  Here is what you can do:

Copy:

• From: \Program Files (x86)\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist\x86\Microsoft.VC100.DebugCRT\msvcr100d.dll on your development machine
• To: \Windows\SysWOW64\msvcr100d.dll on your XenApp 6.5 server

• Jeff Muir - Debugging XAMA SDK Applications
• Andrew Borzycki - Debugging applications remotely with Visual Studio

The Result

Here is what the end result looks like.

Once you pick one of the colors, the console application will give you feedback on the chosen item.  When the appropriate receiver is available for iOS, then the native iOS selector would be shown with no code changes on the developer’s part.  That is pretty cool!

In the next article on this topic, I will show you how to use mobile device orientation to change what is displayed to an end user.  The example will include data and graphics.  Stay tuned…

As of this writing, only the Android version of the Citrix Receiver is supported (iOS is on the way).  Since I do not own any Android devices and I was anxious to get started, I had to set up an emulator and install the Citrix Receiver to get going with the SDK.  Here is how I did it.

Install the Android SDK

Go to the Android SDK download page (http://developer.android.com/sdk/index.html) and pick the correct installer for your platform. I’m using Windows, so I chose the .exe installer file.  After you run this .exe, you still do not have the emulator.  The reason for this is the Android SDK archive initially contains only the basic SDK tools. It does not contain an Android platform or any third-party libraries. You must install the Platform-tools and at least one version of the Android platform using the SDK Manager.

I installed the Android SDK Platform-tools and all options for Android 4.0.3.

After the install completes, be sure to add %ProgramFiles%\Android\android-sdk\platform-tools to your PATH environment variable.  This will be handy later for installing the Citrix Receiver.

Create an Android Virtual Device

After the installs complete, you can launch Android Virtual Device Manager (AVD Manager). This can be found in the Windows start menu under Android SDK Tools \ AVD Manager. AVD Manager is used to create various virtual devices running the Android OS.

As you can see, I created an Android 4.0.3 device with 100 MiB of local storage. The more storage you add to your AVD, the longer it will take to boot. Since this AVD is only being used for XenApp 6.5 testing, I only allocated 100 MiB. The first boot of your AVD will take a little longer than subsequent boots.

Download the Citrix Receiver for Android

Now that we have a functioning Android emulator, we need to get the Citrix Receiver installed. The first thing we need to do is download the .apk (Android Package) file. Normally, I would just go to http://www.citrix.com/receiver and choose “Android”. But, as of this writing, when you do that, you are redirected to the Android Marketplace. Unfortunately, Android Marketplace does not work on the Android Emulator. So, here is what you can do instead:
Go to http://www.citrix.com/downloads and choose “Receiver for Android” from the drop down list. From there, you can select the Android client and download the .apk.

Install the Citrix Receiver for Android

Ok, so now we have a functioning Android emulator and the Citrix Receiver downloaded. The final step is to install the Citrix Receiver onto the emulator. Here’s how:

1. Copy the .apk file to %ProgramFiles%\Android\android-sdk\tools
2. Open a command prompt and change the directory to %ProgramFiles%\Android\android-sdk\tools
3. With the AVD you created running, execute the following command:

adb install <name of Citrix Receiver>.apk

You now have a fully functional Citrix Receiver running on an Android emulator.  My next post shows you how to set up a development environment to utilize the Mobile Application SDK and compile some of the examples.