© Marc A. Brown. All rights reserved.

  • White Facebook Icon
  • White Instagram Icon
  • White Twitter Icon

Developing for Metro, Part 3 -- UI development using XAML

April 16, 2012

As I mentioned in my previous entries in this series, I am currently writing an app to track participation in various activities. I am writing the app for the Windows 8 Metro UI as a means of teaching myself how to write these apps. In this article, I will discuss what I'm learning about UI development using XAML. Many (perhaps even most) of the things I'll discuss will apply to using XAML for other platforms, but that's only natural since I'm a novice in using XAML.

My first modification to the participant UI was to add three text blocks (for labels) and three text boxes to allow editing of the participant's first and last name and nickname. I did this with a combination of the designer and the XAML editor because some tasks are easier one way and some the other. I bound the controls to the appropriate properties in my participant class and my sample data showed up when running the app. The values changed when I selected different participants, as expected. The only issue was that any changes I made to the values weren't reflected in the data objects. Fortunately, I found the solution quickly. By default, the data binding is one way; however, it is easy to make it two way as follows:

Text="{Binding FirstName, Mode=TwoWay}"

 

By adding "Mode=TwoWay" to the Text property's binding, changes made to the data in the field are reflected in the data object when the text box loses focus.

The next step was to add a list view to show attendance objects for the selected participant. While working on this, I realized that I needed to revisit the data objects because I had no simple way to retrieve the attendance objects. I added a property to contain the current activity and another to contain that activities attendance records (picked out of all attendance records for that participant). That completed, the task of filling the list view was trivial. I bound the listview to a participant's current activity's attendance records. By adding a single line of code (telling the participant which activity was the current one) to the participants page's OnNavigated handler and to the participants list view's SelectionChanged handler, I was able to get the selected participant's attendance records for the current activity and display them via the attendance listview's data binding.

Next I needed to build a new page to allow editing of attendance entries -- dates and types of participation (such as "Present" or "Served snacks"). It seems kind of silly to build a whole page just to edit two items, but this is educational as well as practical, so I'm doing it anyway. I started by creating a new page using the "Basic Page" template, which automatically gave me a working back button and the page title. I set up navigation to the page by looking at the navigation from the activities page to the activity/participants page and using the appropriate data source (in this case, the attendance entry selected). I added text blocks to display the participant and activity names, a text box for date, and a combo box for participation type.

The most interesting part of this was setting up the combo box. Here is the line of XAML:

<ComboBox Grid.Column="1" Grid.Row="3" Margin="10,0,1,1" ItemsSource="{Binding Activity.Participation}" SelectedItem="{Binding Participation, Mode=TwoWay}"/>

 

The ItemsSource binding fills the combo box's list from a collection of strings in the attendance object's Activity property. Then we bind the SelectedItem property to the attendance object's Participation property, allowing updates to flow both ways. I'm continually amazed at just how easy some of this stuff is, coming from an environment where I was stuck manually setting and getting data to and from controls. I'm not thrilled with the way the new page looks when in full screen (landscape or portrait) and filled views. It's just too sparse. However, as I said earlier, it works and is a good educational experience.

Next up is to allow the user to select a custom image for a participant. I'll need the same for activities, but haven't yet constructed the activity editor. The Metro file dialog is simply beautiful to look at and simple to create in code:

FileOpenPicker p = new FileOpenPicker();
p.SuggestedStartLocation = PickerLocationId.PicturesLibrary;
p.ViewMode = PickerViewMode.Thumbnail;
p.FileTypeFilter.Clear();
p.FileTypeFilter.Add(".jpg");
p.FileTypeFilter.Add(".jpeg");
p.FileTypeFilter.Add(".png");
StorageFile f = await p.PickSingleFileAsync();

 

That bit of code gives you a gorgeous thumbnail-based view of the Pictures library root, showing only JPEG and PNG image files, and subdirectories within the library. It allows you to pick a single file. If you need multiple files, you change PickSingleFileAsync to PickMultipleFilesAsync and change StorageFile to IReadOnlyList<StorageFile>. If, after PickSingleFileAsync returns, f is not null, the user picked a file and tapped the "Open" button. In my app's case, I then verify that the user wants to replace the current picture, copy the file to a repository directory for the app, then load the image into the object's Image property. Thanks to property binding, the updated image is automatically displayed on the participant page.

See also:

Developing for Metro

Developing for Metro, Part 2

Share on Facebook
Share on Twitter
Please reload

Recent Posts

June 17, 2017

Please reload

  • White Facebook Icon
  • White Twitter Icon
  • White Instagram Icon
Follow Us
RSS Feed