Introducing Coding4Fun toolkit for Windows Phone 7 - Part 2
Join the DZone community and get the full member experience.
Join For FreeIn 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.
Opinions expressed by DZone contributors are their own.
Comments