In a not-so-basic-application you might have pages which are used for multiple similar purposes. You pass query string with many fields with multiple values between such pages (or web pages). In database driven apps, parameter values could be user generated and stored in the back-end and you pull more info from database on the basis of the value in query parameter. This is not the scenario of back-end driven app. This is more about “Field Names” and Values, which are part of the design and known to you while coding, and you want to manage them effectively and make the code more readable.
Let’s take an example:
You have a page in your app which loads different lists (ex: city, state, pin, salutation, etc.) and lets user select an item from the list. At different places in your app you pop this page up with required parameters to load appropriate items. The call to page looks something like this:
this.NavigationService.Navigate("/ListPicker.xaml?ListType=city",UriKind.Relative)
Let’s assume your page also has the ability for editing and you want to activate appropriate functionality (select only || edit). You would add one more parameter to your query, like so:
this.NavigationService.Navigate("/ListPicker.xaml?ListType=city&FormType=select",UriKind.Relative)
If you have many such pages, each have multiple fields and their multiple values, and you make calls to these pages from different places in your code, soon it will be very difficult to manage hard-coded query strings in Uri’s.
Here comes enum based solution:
We will have enums for fields and their values. For the purpose of this example we will keep single enum for fields and multiple enums for values for different fields. Let’s code
First define enums for fields and their values:
internal enum QueryFields { ListPicker_FormType, ListPicker_ListType };
internal enum ListTypes { City, States, Zip, Salutation };
internal enum FormTypes { Select, Edit };
If you do not wish to be more detailed, you could simply build your Uri’s like so:
This.NavigationService.Navigate("/ListPicker.xaml?{0}={1}",QueryFields.ListPicker_FormType.ToString(), FormTypes.Select.ToString());
//The resultant uri - /ListPicer.xaml?ListPicker_FormType=Select
We will see below how you could parse query parameters in the called page and retrieve values in enum types.
Creating Uri as above still has string formatting which is not easy to maintain in multiple uses. To make things manageable and less error prone, let’s create a new enum for pages in the app and shift Uri building code in a single method which could be called from anywhere in the app with different field and values.
internal enum AppPages {ListPicker, Setting, Main, etc };
internal static Uri GetUri(AppPages appPage, params KeyValuePair<string, string>[] args)
{
string uriString = "";
switch (appPage)
{
case AppPages.ListPicker:
uriString = "/Views/ListPicker.xaml";
break;
case AppPages.Setting:
uriString = "/Views/Settings.xaml";
break;
case AppPages.Main:
uriString = "/Main.xaml";
break;
default:
uriString = "/Main.xaml";
break;
}
int counter = 0;
string seperator = "?";
foreach(KeyValuePair<string, string> query in args)
{
if (counter > 0) seperator = "&";
uriString = String.Format("{0}{1}{2}={3}", uriString, seperator, query.Key, query.Value);
}
return new Uri(uriString, UriKind.Relative);
}
With GetUri, you could create page navigation Uri with enums only instead of hard-coded strings:
KeyValuePair<string, string> query_1 = new KeyValuePair<string,string>(QueryFields.ListPicker_FormType.ToString(), FormTypes.Select.ToString());
KeyValuePair<string, string> query_2 = new KeyValuePair<string,string>(QueryFields.ListPicker_ListType.ToString(), ListTypes.City.ToString());
This.NavigationService.Navigate(GetUri(AppPages.ListPicker, query_1, query_2));
Once you are navigated to your page, you need to parse query strings and extract enums which you could use in the page to decide page’s functionality.
At page level you need to have required enum type fields. For this example we will have two fields, one FormTypes type and other ListTypes type. A private processQuery method which accepts a dictionary sets these two fields appropriately.
FormTypes formType;
ListTypes listType;
private void processQuery(Dictionary<string, string> query)
{
string _formTypeName = "";
string _listTypeName = "";
query.TryGetValue(QueryFields.ListPicker_FormType.ToString(), out _formTypeName);
query.TryGetValue(QueryFields.ListPicker_ListType.ToString(), out _listTypeName);
if (_formTypeName.Length != 0) formType = (FormTypes)(Convert.ToInt32(_formTypeName));
if (_listTypeName.Length != 0) listType = (ListTypes)(Convert.ToInt32(_listTypeName));
}
You would call processQuery method from OnNavigatedTo method of your page.
protected override void OnNavigatedTo(System.Windows.Navigation.NavigationEventArgs e)
{
Dictionary<string, string> _params = new Dictionary<string, string>(NavigationContext.QueryString);
processQuery(new Dictionary<string, string>());
}
If you have 100’s of case statements (to choose a page) in GetUri, and you are concerned about performance, refactore the method to accept page name with path as string. With page path name directly in string, you would not need case statements. By the way, in my case with about 80+ cases to get PageName, the query creation does not take more than 50MS, which is negligible for me. More so, navigation calls are not recursive ones.
![wp_ss_20140416_0015[1]](https://sharpsnippets.wordpress.com/wp-content/uploads/2014/04/wp_ss_20140416_00151.png)
Sharp Snippets 