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.

Quite some time ago, Microsoft invented their own way of dealing with this.  Instead of fixing the locations, it can be specified based on a “macro”.  These macros are defined at:

These macros are replaced with the real values during the build. It can be very helpful with regards to a retail versus a debug build. The most common ones I use are $(solutiondir) and $(projectdir). Any good tip is that the names already include the backslash so you will not need to specify that after the macro. Anything entered in as a path in Visual Studio should be relative to a macro unless the path is the same for everyone that might use the build.

The list is fairly extensive so you will probably find what you want. Even if you don’t, there is a way to create your own (which I am not going to cover).

The theory is that if you are born in a certain age, there is a chance you will become a part of what your time offers. This is summarized in the book “Outliers” by Malcolm Gladwell.  His theories are much more advanced than what is portrayed here.  In general, he describes a very different view to what brings success.  Typically timing and practice play major roles in competing well in a world that is always changing.

It is easy to conclude that you were not born at the right time.  Based on the examples in the book, it is clear that the computer industry leaders were largely born around 1955.  Anyone around the age of 20 in 1975 was well positioned to take advantage of the emerging personal computer generation.  Bill Gates and Steve Jobs are perfect examples.

However, this is not the whole story.  Each time has its own opportunity.  There have been a number of “revolutions” in the last 36 years since 1975.  Personally I would summarize some of the milestones as:

• 1981 – IBM PC introduced
• 1985 – Mac with GUI
• 1990 – Windows GUI
• 1993 – Mosaic (Web browser)
• 1995 – WinFrame
• 1998 – Windows Terminal Server

This was the year of the iPad. For there to be so much success in such a short time indicates that critical mass has been reached. Even though the tablet form factor has been around since the early 90′s, it was not until Apple delivered the iPad that the market really kicked off.

The rate of change seems to be accelerating. With the iPad 2 coming soon, it is clear that Apple will pursue this path for deeper market adoption.

This is the first post that I am writing from an iPad. This would be difficult to do without the bluetooth keyboard. This is acceptable for a user experience. There are some quirks here and there but it is still good.

This is being done in the lounge room (living room) for the first time. I could have done this with a laptop awhile back but perhaps it was not quite as interesting. There is something more appealing about having it run in this way.

This is through Safari with WordPress web site. Okay, it is probably not that interesting to most. It’s something to write about.

So, how does this apply to Citrix?

Well, obviously Citrix wants to support iPad as best as possible. This is being carried out with the Citrix Receiver for iPad. The concept of connecting to XenApp or XenDesktop with Receiver is well known. Citrix is also releasing GoToMeeting on the iPad which is a great match.

There are some problems remaining however. It can be difficult to interact with Windows programs using an iPad. This is due to the applications being based on a mouse. It is also due to controls being too small for a touch interface.

In general, it can be a stretch to use Windows applications on iPad. Unless the user learns some tricks, it is going to present a problem.

A new paradigm is arriving. Instead of always trying to work with existing programs, Citrix is proposing a model based on knowing about the environment and making changes for it. This has been demonstrated by Project GoldenGate. The potential is large. This will be the first time that Citrix will ask developers to build custom solutions for XenApp.

Going back in time to 1995, Citrix considered encouraging custom development. Unfortunately, we did not have enough market to justify that kind of special development. Fast forward to 2011 and we have a large market share. In the next couple of years, the financials could hit 2 billion dollars. Obviously things have changed from our approximate earnings of 10 million in 1995.

And, of course, the customer base is much larger now as well. The time is right for custom applications.

The point is that the new mobile devices challenge typical Windows ways of thinking. The only way we can flow through new mobile features is to inject a new interface. Windows simply does not support the diversity of devices out there in the mobile space.

Citrix Labs is investigating how to best support developers in this new space. Opinions in this area will always be considered. More details to come in the coming months.