Introducing Coding4Fun toolkit for Windows Phone 7 - Part 2

In this part I am going to talk about the InputPrompt class. It is not something new for Windows Phone 7, since XNA already has an InputBox implementation. However, this is a bit more customizable.

The first step I am taking when it comes to working with unknown classes is open it up in Reflector and see what unique properties and methods it has. It is a good way to eliminate the IntelliSense noise when you don't want to look (or don't have the possibility to) at the source code. Here is what InputPrompt looks like:

There are four properties that interest me: InputScope, Message, Title and Value. 

REMEMBER: Since InputPrompt derives from PopUp, which derives from Control, it can be customized with separate styles and templates.

InputScope defines the behavior of the SIP. It is a handy feature to limit the type of characters on the software keyboard, so that if a user has to enter a phone number, there won't be an alphanumeric keyboard. Here is an example:

InputPrompt prompt = new InputPrompt();
InputScope s = new InputScope();

InputScopeName name = new InputScopeName() { NameValue = InputScopeNameValue.TelephoneNumber };
s.Names.Add(name);

prompt.InputScope = s;
prompt.Show();

I am explicitly specifying that there is phone number that's going to be entered, so I need the Telephone type of keyboard. Here is what I get as a result:

If I set the basic settings:

prompt.Message = "Please enter the phone #";
prompt.Title = "Phone Number";
prompt.Value = "000-000-0000";

I get this:

It is important to mention that a restrictive SIP by itself does not put restrictions on characters that can be entered in the TextBox. As you've seen above, I used two dashes in my string that otherwise could not be entered from the software keyboard. Also, with the new copy/paste functionality coming out, people will be able to insert content in the TextBox without actually entering anything manually. Bottom line: InputScope != input mask.

Depending on the environment, InputPrompt has a bigger memory footprint on your application compared to the XNA implementation (which is as plain as it can get). To test this, I have a snippet:

Debug.WriteLine(DeviceExtendedProperties.GetValue("ApplicationCurrentMemoryUsage"));

Guide.BeginShowKeyboardInput(Microsoft.Xna.Framework.PlayerIndex.One, "Title", "Description", "DefaultText", new AsyncCallback(GetString), null);

This is the trigger for the XNA input receiver. When the input is processed, I have this:

void GetString(IAsyncResult res)
{
    Guide.EndShowKeyboardInput(res);
    Debug.WriteLine(DeviceExtendedProperties.GetValue("ApplicationCurrentMemoryUsage"));
}

Ultimately, here is what I get in the Ouput box:

7409664
7655424

Not that big of a difference. Here is the current set up for InputPrompt:

Debug.WriteLine(DeviceExtendedProperties.GetValue("ApplicationCurrentMemoryUsage"));

InputPrompt prompt = new InputPrompt();
InputScope s = new InputScope();

InputScopeName name = new InputScopeName() { NameValue = InputScopeNameValue.TelephoneNumber };
s.Names.Add(name);

prompt.InputScope = s;

prompt.Message = "Please enter the phone #";
prompt.Title = "Phone Number";
prompt.Value = "000-000-0000";
prompt.Show();
prompt.Completed += new EventHandler<PopUpEventArgs<string, PopUpResult>>(prompt_Completed);

As you can see there is the Completed event handler that is triggered on input completion. Inside it, I am also trying to get the value of the current memory usage:

void prompt_Completed(object sender, PopUpEventArgs<string, PopUpResult> e)
{
    Debug.WriteLine(DeviceExtendedProperties.GetValue("ApplicationCurrentMemoryUsage"));
}

The Output box shows these results:

7393280
9744384

Considering the nature of the prompt and the ability to load custom style content, I can see where the extra memory usage comes from.

RECOMMENDATION: If you don't plan on customizing the input box, the XNA implementation will do just fine with a smaller memory footprint.

Above, I mentioned the Completed event. Generally, you can get the result by reading e.Result. Don't confuse it with e.PopUpResult - that will return the action set to be the dialog terminator - it can either be OK or Cancelled.