Ramping up with XAMP

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 0x87654321

//
// 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.