Debugging XAMA SDK Applications

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.

About Jeff Muir

Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide