When we shipped the XenApp 6.5 Mobility Application SDK (XAMA SDK for short) last December, it included documentation and samples.  Unfortunately the documentation and samples were not tied together on the web pages and it was not obvious that the samples were there.

This has changed this week.

The SDK team have updated the web documentation to include the samples and make it possible to download them.  But wait, there is more.  Not only are the original samples included but we also have new samples for C# and WinForm-based programs.

The official SDK documentation location is http://citrix.com/mobilitysdk/docs.

Our recent plans have revolved around updating the documentation more often and making all of it online instead of waiting for the next shipping SDK version.  This means that the existing PDF document will be replaced with the online docs.

It has been quite an experience to embrace doxygen as the primary tool for generating the SDK documentation.  It was the right choice and we have not exhausted the possible uses for it.  Most recently I have been exploring what it would take to support other written languages with Japanese being the highest priority.

If you are itching to get straight to the samples, the link is http://citrix.com/mobilitysdk/docs/cmpsamples.html.  If you just want to download the entire samples in one go, get the lot.

We spent a fair amount of time creating new samples and also revamping the ones we had.  Overall the samples are easier to read and make it more obvious how they work.

In case you have not heard, our Mobility Pack is going to be supported by XenDesktop in the not too distant future.  This will make it possible to support a whole new user base with the same set of API.

Interest in the SDK is growing and it is exciting to see developers think of new uses for their customers.  We are still in the early adopter stage but things are moving ahead much faster than what I expected.  We only shipped about three months ago.

To me, the most positive feedback comes from developers who want more.  It means that we still have a bright future for more advanced versions.  The process of an evolving product helps to secure a position in the market.

So, do not forget to collect your free samples.  Be the first of your peers.

During the initial development of XenApp Mobile Pack, certain choices were made for the status/error codes.  This all made sense during that time but certain topics have come up since then which requires attention.  Nothing serious, but rather more of an indication that things need to be better explained.

Chain of thought:

• Most of the XAMA API return CMPRESULT
• CMPRESULT is a 32-bit signed number
• CMPRESULT is directly related to CMP_ERROR_ID
• CMP_ERROR_ID is an enumeration in the cmpenum.h include file in the SDK
• Each CMP_RESULT_ID entry uses the STATUS_CODE macro to build the status code (error code)
• The macro takes two parameters: the component id, and the error number
• The two numbers are 16-bit each and combine to form the 32-bit status code (the component id is the high word and the error number is the low word).
• When the error number(low word) is zero, it is considered a successful operation.  Having a non-zero status code could mean that it was successful.  It is necessary to mask the high word to determine success.

The pattern is similar to how Microsoft has documented its Windows API return codes.  The major difference is that the codes between Windows and XAMA API do not correspond.  Said another way, the status codes for XAMA cannot be used against Windows status codes.

Even though there was some overlap between Windows and XAMA, there were several areas that only XAMA had status codes.  It was necessary to use our own status codes.  This is a good strategy in order to support as many different receivers as possible.  Since our status codes have a well known limit of codes, all our server and Receiver code can act separate from the platform they run on.  The MRVC channel exchanges these status codes and it would not have made to leave it open to unlimited error code pattern.  That is probably a bit too much detail.

One of the goals of this post is to include a document for the current XAMA API  StatusCodes

This PDF includes all the current status codes with the hexadecimal values and a brief description.  Based on a few different events inside and outside Citrix, it has become clear that mapping the hex code to an error message is very valuable.  Until it is more automated, this chart should help to find a match.

The most common errors report to me are 0×120008 and 0x002C.  These translate into CMP_ERROR_GVCH_NOT_CONNECTED_STATE (0×120008) and CMP_ERROR_CLIENT_DRIVE_UNAVAILABLE (0x002C).

GVCH stands for Generic Virtual Channel.  This error just means that there is no connection to the mobile device using MRVC (Mobile Receiver Virtual Channel).  There are a number of likely causes:

1. The Mobile Receiver version does not support XAMP/XAMA with MRVC.
2. The session is currently disconnected
3. The Mobile Receiver might have MRVC support turned off. (currently not a problem but could be in the future)

As for CMP_ERROR_CLIENT_DRIVE_UNAVAILABLE, the most common reason is that Android Receiver has Client Drive Mapping (CDM) turned off.  It is necessary to edit the settings on the Android Receiver to all read or full access to the SD card.  This error should only appear if there is an attempt to take a picture with the API and CDM is not enabled on both sides.  Since it is the default to turn CDM off on Android Receiver, that is why this error has happened so often.

We are in the process of updating the documentation to better explain the status codes and include the hex values.  This upgrade to online documentation should come in the following weeks if not sooner.

When something new is created, it is often difficult to capture its essence in words.  If not that, then it is hard to know where to start.  Sometimes it is much easier to create with the hope that the explanation will happen later.

Later is now.  In the coming weeks we will be providing new documentation and samples.  We are also providing our first videos for the SDK.  This is a new business model for us and we are working hard to make sure that the SDK is accepted and used in businesses.

Today I am going to cover the SDK functional groups.  The hope is that describing the functionality in groups will make it easier to understand what the API can do overall.  The first stop is the documentation on the web.  Please take a moment to look at the functional groups.  This documentation page was only meant for C/C++ but the ideas could be mapped to COM and C# as well.

Here is a quick summary of the groups:

Overview of Functional Groups

• Button
• Camera
• Capability
• Channel
• Conversion
• Device
• Display
  • Orientation
  • Scroll Mode
  • Settings
  • Viewport
• Event
• Init/Uninit
• Keyboard
• Location
• Notification
• Open/Close
• Phone
• Picker
• Process
• Receiver Controls
• Session
• SMS
• Version

These functional names are not quite enough to demonstrate what can be done.

Here is a quick tour.  More detail to follow in future posts.

Button

The ability to hook certain device buttons (Back button on Android) in order to catch button events and handle them in the application instead of on the mobile device.

Camera

Support for being able to take a picture from the application on XenApp using the mobile device.

Capability

Collection of API which allows for determining agreed up features between the server and Receiver.

Channel

Determines the state of the virtual channel used for the Mobility Pack.

Conversion

Conversion routines between different string types (UTF-8, UTF-16, BSTR, Multistring).

Device

Determine various mobile device settings to better help understanding what support is available.

Display

Collection of API related to the display.  There are four sub groups: Orientation, Scroll Mode, Settings, and Viewport.

Orientation

Get and set the application orientation relative to the device.

Scroll Mode

Controls how touch events interact with the application.

Settings

Determines the display settings for the mobile device.  Includes things like resolution and PPI.

Viewport

Get and set the viewport location for the application.  Useful for selecting content to view on a larger application.  Also good for knowing how big the Receiver display area actually is.

Events

Allows for enabling and disabling notification of certain events.

Init/Uninit

Initializes and uninitializes COM for the sake of Citrix Mobility Pack.

Keyboard

Show and hide the display keyboard.  The on screen keyboard is needed for inputting text into the applications.

Location

Get location of the mobile device for use with the application.  This is protected with security measures so that privacy is preserved.

Notification

Allows notifying the user of events.  The notification can trigger four different techniques: sound, light, vibrate, and text.

Open/Close

Open and Close make it possible to treat the CMP interface like a handle used by file open and close.  All operations require a handle to work.  This is not true of COM or C# since they are based on an object model.

Phone

Allows making a phone call using a given phone number.

Picker

Local mobile device selection process for a list of entries.  The application submits the request for the user to select one item.  The mobile device displays the list and the user picks one thing.

Process

Detect and register processes as being aware of Citrix Mobility Pack.  This is most useful for applications that create child processes and do not want the automatic Citrix code displaying the keyboard or using the picker automatically.    In most cases, it will not be necessary to use APIs from this group.

Receiver Controls

Enables and disables the Receiver controls.  The Receiver controls are usually enabled and display options for controlling the Receiver (like keyboard popup). On some Receivers, the controls are available on the screen which takes away from the application experience.

Session

Get the state of the session and set some of the session options.

SMS

Send a SMS message.

Version

Determine the version of the SDK and supporting DLL files.

XAMA SDK documentation is now available online at http://www.citrixcloud.net/mobilesdk/index.html. The documentation was generated from the source code using doxygen.  Because of this, the information is more up to date than typical SDK documents.  Three interfaces are covered.

1. C/C++ XAMA API
2. COM XAMA Interfaces
3. C# XAMA API

Since COM and .NET are supported, it actually means more languages would work besides C/C++/C#.  However, we have not tested other combinations.

Looking through the API online is the easiest way to get an idea of how the API are called.  For example, take a look at CMPTakePicture for C/C++.  Given this knowledge along with the takepicture sample, it would be possible to build a program that uses the camera pretty fast on XenApp.

As a side note, one of the interesting use cases is being able to transfer photos right after they are taken to the server.  The access is protected over the ICA link and the copy process uses client drive access.  In other words, it is fully under the control of the program how the picture data is copied once it is taken.  There are security and privacy concerns so some rules are in effect.  First, the user has to enable access to the SD card to Receiver.  Second, the administrator has to enable transferring data with CDM (Client Drive Mapping).  Third, the user selects when the picture is taken manually.  The server cannot say when the actual picture is taken but can only set the stage for getting ready for it.  This tangent is hopefully interesting for those of you that want to play with the SDK.  Personally I find the take picture API very interesting with quite a bit of potential.

Back on track now.  One last thing to clarify.  In order to get this same information in case you do not have an internet connection, just use a web browser to open “c:\program files (x86)\citrix\mobilitysdk\doc\html\index.html” assuming that you installed to the default path on an x64 system.  On IE, it will give a popup warning against running scripts.  Let the scripts run since it will create the navigation pane.  There is no ActiveX in the SDK.

It has been a real challenge to produce the SDK documentation this way and there is certainly room for improvement.  This is the first time I have used doxygen for so much.  It is an incredibly powerful tool and hopefully the SDK will use more of its features in the future.

However, to anticipate potential questions, there is a solution regardless of when the questions are asked.

First of all, there is a Citrix forum dedicated to the XAMA SDK.  There has not yet been much traffic here yet but we have had a few questions.  The forum is the place to go when you have an issue with getting the SDK to work.   So far we have covered some of the issues that happen when you first start and also how to debug.  Thanks go out to Jason Conger for being an early adopter.   Just remember that we are instantly notified of any new request and do our best to answer the question within a day.

Another path is to use our direct email account.  The group that worked on the Mobility Pack has a group email alias.  This address is mobilitysdk (at) citrix.com.  As usual, substitute “(at)” with @.  I wrote it this way in the vain attempt to hide the email address from automated programs.

The email address is direct and instant and is directed to several people in Citrix.    It probably comes down to preference whether you want to use the forum or email.  Either way, you will get the help you need with the XAMA SDK.

When a developer first experiments with mobile phones and tablets, one of the first questions is how it can be debugged.  With PCs it is fairly easy to start a debugger for a program since the environment is well established and there is plenty of screen space.  With a phone, the space is very limited.  On top of this, there is very limited input control.  Using touch is very effective for mobile devices but not always that effective for debugging the applications than run on these devices.  There has to be some kind of outside control to make this more effective.

There are some general strategies:

1. Using tracing to log files
2. Using tracing to remote consoles
3. Interactive Debugging inside session
4. Interactive Debugging in another session

Each has merits but each one represents a more difficult layer to achieve.

Tracing to Log Files

The pros are that it is really easy to write code to include trace statements.  These trace statements are typically disabled for retail builds.  The tracing usually ends up in a log file with time stamps so that the situation can later be diagnosed.  Typically this would be used with real customer issues that are not under the control of a developer.  The trace statements can be helpful but only if the volume of data is not too large and the trace covers areas that are broken.  It is fairly easy to miss detail with trace statements since it cannot be easily predicted what will be a problem.  If the developer thought it would be a problem, it would already be fixed.

Also, the output file is collected after everything has happened.  There is no chance of gathering more or less data around the time of the event.

Tracing to Debug Console

The concept of outputting to a debug console makes the trace more live.  It might be possible to select levels of debug information.  It might also be possible to pick certain categories of trace information.  This makes the log information more selective and the trace information is shown when the events happen.  However, it is still a trace.  There is no option for examining specific execution of lines of code.  There is also no ability to change any variables or set breakpoints.  It is better than a log file trace but still not always enough.

Interactive Debugging in Same Session

Most Windows developers use an IDE (Integrated Development Environment) to work with and debug programs.  Working with text traces is often not enough to determine what the problem is.  Modern applications are based on advanced techniques that can only be captured using an application focused on debugging.   Most Windows developers can focus on debugging inside Windows using Visual Studio in the same session.  It is not hard to have a debugger running at the same time as the application.  The application alternates being in the foreground with the debugger based on whether it is running or being debugged.

There is a lot of power behind this model.  It allows for a widespread coverage that is much easier to work with than tracing.  It is possible to pause the program at any time either from breakpoints or pressing the break button.  Once stopped, the variables can be examined and potentially changed.  The call stack can be examined.  Memory can be viewed.  The path of execution can be observed step by step.

However, this model would not suitable to mobile phones.  First of all, the devices are much too small to allow something like Visual Studio to run well.  Second, the controls for Visual Studio are too small on high density pixel devices.

It is possible to use a tablet with Visual Studio but the process is too frustrating to use for too long.  Touching such small elements has the potential for error which sometimes leads to unwanted closures.

Interactive Debugging in Another Session

This is the most advanced use case but also the most useful.  Given that we are using a WTS-based server, it is completely valid to use another session.  This strategy is newer than the others and therefore the most unproven.  However, in the workings of supporting mobile devices, sometimes you need to do something  like this.

Here is what I did to get it working:

1. Install Visual Studio 2010 onto the XenApp 6.5 server that has XAMP (XenApp 6.5 Mobility Pack)
2. Have two different accounts (one user, one administrator)
3. Login to the administrator and start Visual Studio
4. Login to the user with a mobile device
5. Start the application for the user (but do not do anything yet)
6. As administrator, on the Visual Studio, select Debug/Attach To Process
7. Click the two checkboxes for showing processes for users and sessions
8. Sort the process names and find your user program and select it
9. Attach to the program (the program should continue to run after this happens)
10. Break into the program and make sure the symbols are set correctly for the program
11. Set any desired breakpoints
12. Use the program as a user

There are weaknesses with this model (complexity) and it does not cover controlling the application from the beginning.  This could be handled by having a stub code section that waits before launching the main part of the program.

However it does work and gives use two main things:

1. The debugger can be used fully like it was meant to be used on Windows
2. The application is not affected by the debugger being displayed in the same session.

It is important that the administrator has rights to debug any program in the system.  I do not remember doing anything special for this so it should just work.

This gives the application and the debug view different display surfaces.  Best of all, the debugger can use the standard keyboard and mouse.

It is possible to do the other three tactics with mobile applications but each of these have serious limitations.  One strong exception to this is time sensitive activities.  Sometimes debugging slows things down enough that it can affect the outcome.  The most obvious reason is network transactions.  If the requests do not get a response within a certain time, the request will fail.

In this realm, using tracing is actually better.  It is just important to make sure there is enough information in the trace and the trace has an accurate time reference.

Debugging, to me, has always been more of an art than a science.  The situation largely determines how it can be attacked.  Developers have different preferences and obviously this is reflected by what tools they use and how much experience they have fixing problems.  Even though it might be a bit painful to use the most advanced option for debugging mobile device applications with XenApp, it is also the most rewarding way to get results.

I did not mention how to get administrator access to the server.  In my case, I used XenServer to access the console of the server.  From this “local” console, I logged on as administrator and started Visual Studio.  I should have also mentioned that XenServer is hosting my copy of XenApp.  As a Citrix developer, using XenServer makes it much easier to try different servers as well as including support servers like AD controller.  Last I heard, XenServer is still available free.

However, it would also be possible to either use ICA or RDP to access the server remotely to run Visual Studio.

The first version of the Citrix XenApp 6.5 Mobile Application (XAMA) SDK has been published on the Citrix web site as of December 17, 2011.  In order to use the SDK, the XenApp server must have the Citrix XenApp 6.5 Mobility Pack (XAMP) installed first.  The team has worked for around a year bringing this together.  The overall goal is to make it easy for enterprise Windows developers write software that works well on mobile devices (phones and tablets).

Currently the Android Receiver supports this new programming platform with the iOS Receiver to follow soon.  The main Android Receiver has the required code to support applications using XAMA.

The basic things that would need to be done:

1.  Setup a test XenApp 6.5 server
2.  Install the XenApp 6.5 Mobility Pack on the XenApp server
3. Install XenApp 6.5 Mobility Application SDK on Windows 7 64-bit dev machine
4. Install Citrix Receiver for Android (minimum 3.0.59 version) on Android device

More tips:

1. Select Web Interface for XenApp to test apps/desktops
2. Use XenServer to host XenApp and other support servers (like AD controller)
3. Learn about Google Android SDK and hook up the phone/tablet with USB debugging
4. Use client drive access or Windows Network to exchange files between server and dev machine (Windows Network is faster)
5. Visual Studio 2010 is best to use with server and dev machine
6. XAMA SDK is has HTML documentation included in SDK.  Just open the index.html in the doc\html directory with web browser.  Or, go online at http://www.citrixcloud.net/mobilesdk/.

The primary concept is that the SDK enables Windows applications to be aware of mobile device features.  Once aware, these applications can utilize the features to accomplish things which were not possible before.  Currently the most obvious benefit is being able to customize content to the variable screen sizes and pixel densities.  Long-term, full integration will allow for powerful bonding between server applications and mobile devices.  The best of both worlds will bring a better experience to the users.

Over the last couple of years, Citrix Labs has been working on a project to make standard Windows applications more usable on mobile devices (phones and tablets).  This started with the development of Project GoldenGate and the production of an email client that runs on XenApp but acts like a native mobile device application when run remotely.  In the early demonstrations, it was clear that customers were interested for a few different reasons:

• The email would be kept in the data center and therefore would be more secure.  If the device was lost or stolen, the information would not be there.
• The email application could be maintained inside the organization instead of on different devices at remote locations.
• Deploying standard Windows email programs via XenApp is not easy due to user expectations for usability.

You can learn more about the latest release of GoldenGate here.

Producing this kind of application is important but not the whole story.  There is also a need to make it easy for other software companies to produce software for XenApp and mobile devices.  The intent is to publish a SDK for developers to use to get all the same benefits along with a few new ideas along the way.

To get a first impression of this SDK, please example the doxygen-generated documenation for XenApp 6.5 Mobile Application SDK.  This documentation was released during Synergy Barcelona in late October 2011.

The online documentation focuses on the C/C++ interfaces for the SDK.  The internal name for the SDK was Citrix Mobility Pack SDK (CMPSDK).  That is why there are so many references to CMP in the documentation.

The announcement for the XA MA SDK includes a video that share the vision for producing these kind of mobile applications.

It is important to keep these kind of things in mind:

• It is a fairly steep learning curve to pick up knowledge in mobile device platform development.  It is far easier to leverage existing Windows development experience.
• The XA Mobility Pack enables several new features from the mobile device including GPS, display metrics, onscreen keyboard, SMS, camera, orientation, mobile device properties,  button redirection, user notification, picker control support.
• The SDK works with C/C++/COM/C#
• The SDK is used by GoldenGate

There is another way to talk about this SDK.  What it really means is that the client and server work closer together to produce a more native experience on the mobile device.  It also means that the mobile device gets all the benefits of the data center with the massive storage and the existing Windows infrastructure.  As an example, a Windows program could be written to use the SDK to take a picture on the device and then download the picture to any location inside the company.  There is more to the story than this.  Security is a concern.  So, for example, no automatic picture taking will happen and the server will need access to the mobile device storage through Client Drive Mapping.  However, the point is that with a bit of changes, an existing Windows program could be modified to take advantage of the features on the mobile device.  Another example is a dialing program.  Using our SDK, it is possible to tell the device to start the process of dialing the number.  The user still has to say that it is okay and let the dial happen (for security reasons).  This would make it possible to write a program that could hook into the company database and then provide a list of names based on a search.  Once a person is selected, that number will be sent to the phone so the user can dial it easily without typos or the possibility of errors with the prefix.

Yet another angle brings in GPS data.  The SDK introduces the ability to determine current location.  With this information it would be possible to reconfigure the software to provide different results.  For example, the dialer would know where it is so it can pick the right prefix to dial the number correctly.

For those early developers for this SDK, there is a forum setup in Citrix.  The forum is monitored by the people that have been working on it and the associated projects.  The team is keen to help developers and to learn what else developers would like to see.

Just to give you a simple example of code, here is a example of how to dial a number:

//
// Phonecall example:
//
// Uses Citrix Mobility SDK to start a phone call
//
// Copyright (c) Citrix Systems
//

#include <stdio.h>
#include <windows.h>

#include <cmp.h>

// change the phone number to something more appropriate
#define PHONE_NUMBER “+18005551212″

// unique number should not be a constant but it is here for an example
#define UNIQUE_CALL_ID 0×87654321

//
// Event callback for phone call started
//
void CMPAPI PhoneCallStarted(HANDLE hCMP, CMPRESULT rc, CMP_UNIQUE_ID PhoneCallId)
{
printf(“PhoneCallStarted hCMP(%p) rc(0x%X) PhoneCallId(%X)\n”, hCMP, rc, PhoneCallId);
}

//
// Reports errors if they happen
//
void ReportStatus(LPCSTR text, CMPRESULT rc)
{
// only print if something went wrong
if(CMP_FAILURE(rc))
{
printf(“%s CMPResult(%08X)\n”, text, rc);
}

return;
}

//
// main entry point for simple phone call program
//
int __cdecl main(int argc, char **argv)
{
CMPRESULT rc;
HANDLE hCMP = NULL;

// initialize for STA (Single Thread Apartment) in COM
rc = CMPInitialize(FALSE);

ReportStatus(“CMPInitialize”, rc);

// Open a handle to the mobile device
rc = CMPOpen(&hCMP);

ReportStatus(“CMPOpen”, rc);

if(CMP_SUCCESS(rc))
{
// open the link between the two sides
rc = CMPOpenSession(hCMP);

ReportStatus(“CMPOpenSession”, rc);

if(CMP_SUCCESS(rc))
{
// register for event
rc = CMPRegisterForEvent(hCMP, CMP_EVENT_PHONE_CALL_STARTED, (CMP_EVENT_CALLBACK)PhoneCallStarted);

ReportStatus(“CMPRegisterForEvent CMP_EVENT_PHONE_CALL_STARTED”, rc);

// Start the phone call process by popping up the dialer with the number already populated
rc = CMPStartCall(hCMP, PHONE_NUMBER, UNIQUE_CALL_ID);

ReportStatus(“CMPStartCall”, rc);

// let events come in over the next 30 seconds
//
// if this was a Windows program and we had a message loop, we would not need to do this
for(int i=0; i<30; i++)
{
Sleep(1000);
}

// close our connection
CMPCloseSession(hCMP);
}

// release our handle
CMPClose(hCMP);
}

// uninitialize COM
CMPUninitialize();

}

This shows the typical flow for how to use the SDK.

1. CMPInitialize
2. CMPOpen
3. CMPOpenSession
4. CMP functions (e.g. CMPStartCall)
5. CMPCloseSession
6. CMPClose
7. CMPUninitialize

The calls are matched up.  CMPInitialize and CMPUninitialize, CMPOpen and CMPClose, and CMPOpenSession and CMPCloseSession.

CMPInitialize corresponds to initializing a thread for COM.  It should only be done once for a thread and before any COM operations happen.  The SDK uses COM so it needs this to be run.  If COM is already initialized then you can skip this function.

CMPOpen creates the COM object for the SDK.  It is responsible for creating and initializing the COM interface.  CMPOpen does not guarantee a connection to the mobile device.  It will return fine even if the connection is not there.

CMPOpenSession establishes a link between the two sides (server and mobile device).  It will fail if the device is not there.  For any of the functions besides the paired ones already mentioned, require a connection to the mobile device.  If you try to issue a function when it is not connected, it will fail.

The functions in the SDK use a return code called CMPRESULT.  This enumeration is defined in cmpenum.h in the SDK and has this pattern.  If the lower 16-bits (word) are zero, then the command was successful.  The top 16-bits reveal which component generated the result.  The status codes are custom to the SDK to avoid depending on the Windows error codes too much.

To download the SDK that was released with Synergy, get it from CDN.

So many people are using mobile phones and tablets these days and Citrix has invested heavily in producing new Receiver programs for the wide array of hardware devices.  Android and Apple iOS are the most popular but there is work being done for upcoming devices from top manufacturers.

While having great Receiver software certainly helps, Citrix has realized that it needs to do more.

The wheels are turning at Citrix Labs to produce a new software development kit.  Unlike previous Citrix SDKs, this one addresses a basic need to utilize mobile device resources with programs running on XenApp.  

I have been assigned the task of putting this SDK together.  It is based on experience gathered from a number of projects in Citrix including well known projects like Golden Gate.  We love our project names like most software companies do.  The name of the umbrella project is Project San Francisco.  It includes the sub-project called Project Candlestick.  We also have Lombard, Alcatraz, and Hermes.  Perhaps you sense a theme?  Please excuse Hermes since it was invented independent of San Francisco.

Regardless of all these names, the projects aim to improve the experience with XenApp while using mobile devices.  Each project focuses on a specific topic.

Project Candlestick is all about providing an SDK.  However, it also has to worry about the implementation of the communication between the XenApp server and the Citrix Mobile Receiver.  The current name (which should stick) is the Mobile Receiver Virtual Channel (MRVC).  This new channel has already been seen as part of the Citrix Labs Android Receiver.

The message that needs to be conveyed is simple.  Running Windows programs remotely on mobile devices has a number of limitations.  It does not take long to realize that interacting with a legacy program running on XenApp can be very trying.  The new interfaces do not mesh well with the old.  There are a variety of reasons why which I will save up for a future post.

Citrix has always been about keeping things compatible and being able to work with the program from anywhere on any device.  Early on, Citrix realized the power of taking Windows applications to places it would never normally run.

Things have changed a bit.  Introducing Windows programs to a tablet is not just about making it run like a Windows program.  The shift is starting to realize that the Windows program needs to act a lot more like the mobile device platform.

So, what does this mean?  It means that for the first time, Citrix is going to recommend writing software that is specifically aware of mobile devices on the other side.  This simple shift of thinking advocates using the mobile device resources and integrating it with the application running on the host.

Project Golden Gate is the first to take advantage of this idea.  I have tried this internally written program on my Android phone.  It is impressive what it has achieved.  The program feels like a native application but all the information is at work on the XenApp server.  The message is strong and clear.  Why choose the mobile device or the server when you can have both working together?

It is going to be difficult to sell the SDK to developers because it is different from what has come from before.  I see it more as a bridge between the two worlds.  If fact, I see it as a means of creating a hybrid machine based on both.  The interface lives on the device and the core business logic lives on the server.  Different from before, the program looks like it came from the device when really it is leveraging both.

There are a number of things I could share with you.  For now, it is important just to introduce why this new SDK is needed.  The next blog post will cover what this SDK is solving.

Where does it all begin?  When does a pattern emerge?  How do we decide that one thing is better than another?  Why do we make the choices we do?

Obviously we can blame our parents first.  That which we know probably started with them.  Then we can blame the media and the Internet for the remaining bits.  We see, we do.  We like to copy that which we have seen.  If we see someone do something and it worked for them, then it should work for us.

This is the nature of primates.  The roots are deep.  It is hard to ignore those aspects of ourselves.  We see, we do.

Sometimes things are designed to be so easy to do it is hard to avoid them.  Once they are used, it is hard to stop.  Things like telephones and televisions come to mind.  Simplicity attracts use.  Use attracts others.  Soon, a large group of customers are avid fans of that which they use.

Enter the entrapment.  Once a user gets hooked on a way something works, the user expects it to always do certain things.  The momentum of the mind will accept minor deviations in future products but will not tolerate having its basic needs met.

Think about Internet Explorer.  It first came out in the mid 90s after the huge success of Netscape Navigator.  The first decent version was 3.0 which corresponded with Windows 95.  It was a perfect time to introduce a new program based on browsing the Internet.  The timing was great and so was the way it was delivered.  Instead of selling it as a separate product, it was included with Windows.  This ultimately changed the game and forced Netscape to focus on the server products over time.  Users got IE for free and were able to browse the web with their normal Windows.

Fast forward to 2011 and the introduction of IE 9.  The expectation for IE 9 was high and Microsoft has pushed it extensively.  It is the first Microsoft browser to support HTML 5 and it has things that probably should have been included in previous versions.  It promised to make things much better for the user.

Then something else happened.  First it was my wife.  One of her web sites that she visits stopped working.  It sounded odd.  Web sites usually do not break that way so quickly.  Things were missing and other things did not respond as expected.  It truly was unusable.  Searching for the problem found results with other people having the same problem with the same site (Blogger).  And, much to my surprise, there was no easy fix.  All of the people on the forum discovered that the only way to get it to work again was to go back to IE 8.

Then it became a question of how IE 9 showed up in the first place.  I had assumed that my wife had installed IE 9 to get the latest browser version.  This was untrue.  IE 9 arrived through Windows Updates.  This means that getting IE 9 was relatively automatic and not always easy to understand how to stop.

Users have found that when they get rid of IE 9 it just tries to install itself later on through the update process.  It is necessary to hide the update as well so it will leave you alone.

I probably spent at least an hour finding this out and going back to IE 8.  After the computer was switched to IE 8, everything worked again.  It was refreshing to see it work but also a bit disturbing that it happened in the first place.

Then, within a couple of weeks, two other people in the family reported similar problems with IE 9.  A pattern was emerging.  IE 9 was not that good at supporting what people were used to.   Now it was no longer just a personal experience but a shared experience.  Bottom line, forget IE 9.  Go back to IE 8.

Being that I still develop software, I find this idea a bit offensive.  The latest version is always supposed to be the best.  Anything that worked before should still work.  Expectations are that things should be better and not worse.

And then, I remember something else.  Software companies and developers are always under pressure to meet other non-user demands.  Perhaps there is a major security threat that needs to be addressed.  Perhaps the architect wants a complete re-design.  Maybe the developers just do not care about compatibility.  It could be any of these.  At some point the past is forgotten and the company produces something that it thinks is better but actually it does not work as the previous products worked.  Resistance is quick and continues to the point that could lead to a quick exodus to other products and companies.

Sometimes companies just get cocky.  IBM had the PS/2.  Intel had the Itanium.  Microsoft had Vista.  All of these things were supposed to be so much better.  Each of these had aspects that were great.  Unfortunately, they let people down.  With IBM and Intel, it could be argued that the changes were designed to better control the market.  The problem is that people are already committed to doing things a certain way and drastic changes lead to rebellion.  The common theme is a lack of compatibility leads to greatly reduced acceptance.

People are trapped in the patterns that they do.  It is hard to change based on the momentum of the investments made.  Learning a new story and forgetting the old one can be very painful.  It is made worse when the new story is not compelling enough to change for.

Legacy entrapment means that a develop is trapped into supporting the old ways as well as the new.  There is no easy way to get adoption without it.  The only decent way to have something completely different is to make the old ways look primitive AND be able to do it so much cheaper, simpler, and faster.  Not many people still play music on cassettes.  Not many people walk to their destinations.

To ignore how things work now is a fatal flaw.  We are stuck fully in legacy mode and anything new has to respect that.