It’s too easy for many of us to fall into that trap of doing the familiar, working the same way, choosing the comfortable path. That kind be stifling. You do the same things the same way, and it becomes habit.

If you want to stretch, you need to open yourself to new ideas, make your brain do different things, and grow.

That’s why we did a workshop this past winter with The Improv Effect. It was an exhausting afternoon of fun. Our entire team ran a number of different exercises. Throughout the afternoon, everyone was laughing, thinking, and trying to produce the best improv sessions we could. it was fun because the exercises are designed to apply humor to your daily activities. you look at challenges from a different perspective when you’re trying to make them humorous. It was exhausting because you use very different parts of your brain than you do when creating code. You’re reacting to your partners in Improv. You’re listening very carefully. You’re doing the first thing that comes to mind. You’re going to make mistakes and fail. A lot. And then, you need to recover.

Because of all that, maybe software development should be more like Improv. We should handle change. We should handle updates. We  should handle mistakes. If you’re tasked with making innovative applications, stretching the boundaries, and implementing new ideas, maybe you need to treat your brain the same way: Stretch it. Try new things. Innovate in different areas.

I encourage you to try totally new disciplines. We found Improv a great way to expand our minds. I encourage you to do the same. And, if Improv isn’t your thing, look for other opportunities to grow your brain in other areas.

I didn’t take notes on the headers part of the sample, because it’s really quite straightforward.  The semantic zoom is pretty cool though.
Even here, the code (and the XAML) is very straightforward. In fact, almost everything is in the XAML.

If your app supports semantic zoom, you just add a semantic zoom control to your page, and define the two different views (the zoomed out view, and the zoomed in view):

<SemanticZoom x:Name="semanticZoom" VerticalAlignment="Bottom">

    <SemanticZoom.ZoomedOutView>

        <GridView Foreground="White">

            <GridView.ItemTemplate>

                <DataTemplate>

                    <TextBlock

                        Text="{Binding Group.Key}"

                        FontFamily="Segoe UI Light"

                        FontSize="24"

                        Foreground="Black" />

                </DataTemplate>

            </GridView.ItemTemplate>

            <GridView.ItemsPanel>

                <ItemsPanelTemplate>

                    <WrapGrid ItemWidth="75" ItemHeight="75" MaximumRowsOrColumns="1" VerticalChildrenAlignment="Center" />

                </ItemsPanelTemplate>

            </GridView.ItemsPanel>

            <GridView.ItemContainerStyle>

                <Style TargetType="ListViewItem">

                    <Setter Property="Margin" Value="4" />

                    <Setter Property="Padding" Value="10" />

                    <Setter Property="BorderBrush" Value="Gray" />

                    <Setter Property="BorderThickness" Value="1" />

                    <Setter Property="HorizontalContentAlignment" Value="Center" />

                    <Setter Property="VerticalContentAlignment" Value="Center" />

                </Style>

            </GridView.ItemContainerStyle>

        </GridView>

    </SemanticZoom.ZoomedOutView>

    <SemanticZoom.ZoomedInView>

        <GridView ItemsSource="{Binding Source={StaticResource cvs2}}" IsSwipeEnabled="True">

            <GridView.ItemTemplate>

                <DataTemplate>

                    <StackPanel Orientation="Horizontal" Margin="10,10,0,0" HorizontalAlignment="Left" Background="White">

                        <Image Source="{Binding Image}" Height="60" Width="60" VerticalAlignment="Center" Margin="0,0,10,0"/>

                        <TextBlock TextWrapping="Wrap" Style="{StaticResource ItemTitleStyle}" Width="200" VerticalAlignment="Center" Text="{Binding Title}" HorizontalAlignment="Left" FontFamily="Segoe UI" />

                    </StackPanel>

                </DataTemplate>

            </GridView.ItemTemplate>

            <GridView.GroupStyle>

                <GroupStyle>

                    <GroupStyle.HeaderTemplate>

                        <DataTemplate>

                            <TextBlock Text='{Binding Key}' Foreground="Gray" Margin="5" FontSize="18" FontFamily="Segoe UI Light" />

                        </DataTemplate>

                    </GroupStyle.HeaderTemplate>

                    <GroupStyle.ContainerStyle>

                        <Style TargetType="GroupItem">

                            <Setter Property="Template">

                                <Setter.Value>

                                    <ControlTemplate TargetType="GroupItem">

                                        <StackPanel Orientation="Vertical">

                                            <ContentPresenter Content="{TemplateBinding Content}" />

                                            <ItemsControl x:Name="ItemsControl" ItemsSource="{Binding GroupItems}" />

                                        </StackPanel>

                                    </ControlTemplate>

                                </Setter.Value>

                            </Setter>

                        </Style>

                    </GroupStyle.ContainerStyle>

                    <GroupStyle.Panel>

                        <ItemsPanelTemplate>

                            <VariableSizedWrapGrid Orientation="Vertical" MaximumRowsOrColumns="3" />

                        </ItemsPanelTemplate>

                    </GroupStyle.Panel>

                </GroupStyle>

            </GridView.GroupStyle>

            <GridView.ItemsPanel>

                <ItemsPanelTemplate>

                    <StackPanel Orientation="Horizontal" />

                </ItemsPanelTemplate>

            </GridView.ItemsPanel>

            <Button Visibility="Collapsed"/>

        </GridView>

    </SemanticZoom.ZoomedInView>

</SemanticZoom>

I’m not sure why, but this sample sets the DataSource for the zoomed in view using binding, and sets the source for the zoomed out sample using code:

cvs2.Source = dataLetter;

(semanticZoom.ZoomedOutView as ListViewBase).ItemsSource = cvs2.View.CollectionGroups;

The pinch gesture support is built into the control, so that just works. This sample adds a button to switch views, and that changes from the zoomed out to the zoomed in view when pressed:

private void scenario3switchViewsClickHandler(object sender, RoutedEventArgs e)

{

    semanticZoom.ToggleActiveView();

}

Sure, this isn’t rocket science, but it does show a couple worthwhile design ideas. For one, semantic zoom is not that much code. If your app should support it, do so. Second, while the XAML for Windows Metro looks familiar, there is some interesting new concepts there.

The most important part about this sample is that semantic zoom is not about showing the same view in a larger or smaller view. Semantic zoom done right reimagines your data in a different view. The zoomed out and zoomed in views do display different controls. You have one view when you’re zoomed out. You have a totally different view of the data when you are zoomed in on a subset of the data.

Public Service Announcement: I interrupt our regularly scheduled technology content for a discussion of government policy.  If that’s of no interest, just skip this post. Regular tech posts will resume shortly.

I spent the early part of this week in Washington, D.C.  in meetings with legislative and executive staff on issues relating to the software industry. I’m glad you’re still with me. What our government does (or doesn’t do) affects us. We should pay attention.

ACT Online wrote about the event here.  Morgan summarized the focus of the event quite well. Rather than repeat the main concepts, I’ll discuss my own experience from the perspective of a developer and business owner in Michigan.

The software industry is one of the main bright spots in our economy. It’s continuing to grow. The jobs the software industry creates are high-paying jobs. I went to Washington to help ensure that our policy makers understand that they have both a positive and a negative impact on our industry. The software industry is still young, and we are constantly creating new applications and new technology ideas that open up new areas of innovation.  This industry has been especially instrumental in Michigan’s recovery. New businesses, like ours, have grown over the past 10 years. Larger companies are making new investments in software. The renewed investment in Detroit is almost completely due to software companies.  Public policy affects the environment for new businesses, influences society and education, and creates the regulations that govern our commercial interactions.

Overall, our message is that government has an important role to play by allocating public resources, like spectrum. It also has an important role to play in regulation. We want consumers to feel safe when they interact with software companies, whether those companies are large corporations or small one person startups. Finally, and most importantly, we know that government has an important role to play in creating a society where people have the skills and talent to help the software industry keep growing.

That last item is the most important, in my mind. We had a fantastic meeting Monday morning with Danny Weitzner, President Obama’s Deputy Chief Technology Officer for Internet Policy. (As an aside, when 30 tech people have a meeting at the White House, they all get some impressive bragging rights on FourSquare). One of my key messages there involved education and building the talented workforce we need. There is a lot of discussion around STEM fields, and ensuring that more young people become interested in these fields. Much of that discussion misses the mark.  There seems to be an emphasis on training for a specific job (Java programmer, iOS programmer) rather than careers (software application development). Our software programs are created by teams with diverse skills: artists, designers, User Experience experts, developers and more. The game industry includes script writers, musicians and engineers. While we need people with specific skills, we need creative people that can come up with new ideas and implement them even more. Changes to our education system must address math and science. More than that, it must create life-long learners that have the breadth of knowledge and the creative skills to create the next Instagram, Facebook, Google or Microsoft.  When we hire people, we ask questions that are outside the realm of simple coding questions.  We want to know if you can think about problems, come up with new ideas, make new products that people haven’t even thought about wanting. I was really excited to see Mr. Weitzner latch onto that concern.

Overall, it was a great trip, and a great way to take my perspective on our industry to our governmental leaders.

When your application starts, it becomes the active app. Your application will receive events that indicate your application is being started, loaded and activated.

If you’ve used Windows 8, you’ve probably noticed that you don’t have any explicit way to terminate an application. (Yes, you can close an app, using the swipe action from the top to the bottom, but that doesn’t actually stop the application from running.)

The environment will close your application if there’s memory or CPU pressure on the machine. The first thing that will happen is that Windows will suspend your application if the system needs more resources. Your application will receive a Suspend event, and will have 5 seconds to store its state, and then the system will suspend your application.

If the system still needs more resources, the system will terminate suspended applications to free up more resources. Since your application was already suspended, your application won’t get a new event for termination; rather the system will simply unload your application.
Your users have expectations around suspending, resuming, terminating, and restarting your app.  When the system suspends your application, you must save state so that you can resume your app’s state exactly where the user left off. You need to respond to those events, save and restore state correctly.

First, suspend:  Suspend is easy.  Just save your state. Do it async, and don’t take more than a few seconds. App storage will backup your state into the user’s Live account storage. It will automatically be visible across Win8 machines for that user.

Next, resume: You probably don’t need to do anything here. Your app was still in memory, and can simply be resumed.  However, some applications, which may have time sensitive data (think news or weather apps) should look at the elapsed time and consider if they should update content. In addition, you may store state in the cloud. When you app resumes, you should consider that you may need to update the content based on the user working on your app on another machine (think EverNote). Once again, remember that the storage will be available across WIn8 machines.

Finally, consider Activated: You will get this event when your application starts.  One of the properties in the event arguments is the Previous Execution State. If this is the enum value Windows.ApplicationModel.Activation.ApplicationExecutionState.terminated, that means your application was run previously, and saved state on suspend, and was then terminated by the system to free resources. You should restore state, and use the same guidance I just gave on resume.

Of course, if you’ve got to code these capabilities, you need to be able to test and debug these scenarios.  Visual Studio 11 gives you capabilities to do that. Unfortunately, the necessary commands are bit hidden.  It took me several minutes to find the right magic to find and turn on the right commands.  One of the new toolbars in VS 11 beta is the “Debug Location” toolbar.  You need to customize your toolbar, and turn on this feature.  It’s not on by default.  The “Debug Location” toolbar (shown below) contains three new commands to suspend, resume, and suspend then terminate the app being debugged:

Once you’ve turned on that toolbar, simply debug your app. You’ll have buttons on the toolbar button to suspend your app, or suspend and terminate your app. You can walk through the code that handles these features and ensure that your users will get the proper behavior.

The next sample provides an overview of WinRT data binding.  This sample actually has seven different scenarios; it’s one of the biggest samples so far.

However, I’m only going to briefly cover this sample.  TLDR Version:  If you’ve used DataBinding in WPF or Silverlight, it is very familiar.

For those interested in more:

You can support one way, two way, and one time bindings:

<TextBox x:Name="tbOneWayDataBound" 

    Text="{Binding ElementName=sliderOneWayDataSource, Path=Value, Mode=OneWay}" 

    Grid.Column="2" Grid.Row="2" HorizontalAlignment="Left" VerticalAlignment="Top"  Width="150"/>

<TextBox x:Name="tbTwoWayDataBound" 

    Text="{Binding ElementName=sliderTwoWayDataSource, Path=Value, Mode=TwoWay}" 

    Grid.Column="2" Grid.Row="4" HorizontalAlignment="Left" VerticalAlignment="Top" Width="150"/>

<TextBox x:Name="tbOneTimeDataBound" 

    Text="{Binding ElementName=sliderOneTimeDataSource, Path=Value, Mode=OneTime}" 

    Grid.Column="2" Grid.Row="6" HorizontalAlignment="Left" VerticalAlignment="Top" Width="150"/>

You can create Converters similar to WPF or Silverlight:

<TextBox x:Name="tbValueConverterDataBound" 

    Text="{Binding ElementName=sliderValueConverter, Path=Value, Mode=OneWay, Converter={StaticResource GradeConverter}}" 

    Margin="5" Width="150"/>

public class S2Formatter : IValueConverter

{

    //Convert the slider value into Grades

    public object Convert(object value, System.Type type, object parameter, string language)

    {

        int _value;

        string _grade = string.Empty;

        //try parsing the value to int

        if (Int32.TryParse(value.ToString(), out _value))

        {

            if (_value < 50)

                _grade = "F";

            else if (_value < 60)

                _grade = "D";

            else if (_value < 70)

                _grade = "C";

            else if (_value < 80)

                _grade = "B";

            else if (_value < 90)

                _grade = "A";

            else if (_value < 100)

                _grade = "A+";

            else if (_value == 100)

                _grade = "SUPER STAR!";

        }

        return _grade;

    }

    public object ConvertBack(object value, System.Type type, object parameter, string language)

    {

        throw new NotImplementedException(); //doing one-way binding so this is not required.

    }

}

Other scenarios in this sample show how to respond to data source changes (It looks like INotifyPropertyChanged), bind to elements in a collection (just like in WPF or Silverlight) , bind to color properties (just like WPF and Silverlight), modify collections (like WPF and Silverlight), and navigate collections (like in WPF or Silverlight).

In short, it’s really familiar code, if you’ve done anything with WPF or Silverlight.

There are two parts to implementing a background task for a Metro style application: 

1. Implement the IBackgroundTask interface (contract).
2. Register the background task with the system so that Windows starts the task at the appropriate time.

The IBackgroundTask interface has only one method: Run().  The only parameter to Run() is an IBackgroundTaskInstance.  Your background task will communicate with the Windows system through the IBackgroundTaskInstance. In this sample, the background task registers to receive the Cancelled event from the IBackgroundTaskInstance if it should stop working on the current problem. The background task also updates the IBackgroundTaskInstance.Progress property to notify the system of its progress on the current problem.

You can think of the IBackgroundTask.Run() method as similar to the Task.Run() method in today’s .NET environment: it’s the entry point for your background task.

Registering a background task in WinRT is a bit more involved. Remember that this background task is not the same as just running something asynchronously. Instead, these background tasks communicate with the OS, so that they can receive events while your application is suspended. For example, a Mail client will be awakened, check mail, then update its live tile periodically when suspended. That requires using the Windows system Background Task contract.

You register a Background Task in a few steps, using a BackgroundTaskBuilder object. There are several properties you need to set on the BackgroundTaskBuilder:

var builder = new BackgroundTaskBuilder();

builder.Name = name;

builder.TaskEntryPoint = taskEntryPoint;

builder.SetTrigger(trigger);

The name is simply a name you use to identify the task (uniquely) in your application. The TaskEntryPoint is the fully qualified class name for the type that implements IBackgroundTask.

The trigger specifies when the task should be started. Any of the event types you specify must also be specified in you application’s package manifest. If you don’t specify the event types, your registrations will fail.

Aside: Here the sample seems a bit of a kludgy demo. They trigger some of the tasks when the machine’s current TimeZone changes. That, I think, is just for demo purposes. It’s easy for you (as the user) to switch time zones, and make the background task start. The other scenarios use a timer, and start the background task every 50 ms. That’s closer to a production scenario, but a little short of a time span.

Once you’ve initialized the builder, you register the task:

BackgroundTaskRegistration task = builder.Register();

That BackgroundTaskRegistration object contains some additional APIs that you use to create and communication channels between your foreground task and your background task.

task.Progress += new BackgroundTaskProgressEventHandler(OnProgress);

task.Completed += new BackgroundTaskCompletedEventHandler(OnCompleted);

private void OnCompleted(IBackgroundTaskRegistration sender, BackgroundTaskCompletedEventArgs e)

{

    //

    // Update the UI with progress reported by the background task.

    //

    SampleDispatcher.InvokeAsync(CoreDispatcherPriority.Normal,

    (task, args) =>

    {

        try

        {

            var taskCompletion = task as IBackgroundTaskRegistration;

            var completionArgs = args.Context as BackgroundTaskCompletedEventArgs;

            if ((taskCompletion != null) && (args != null))

            {

                if (completionArgs.Status != null)

                    throw completionArgs.Status;

                var key = taskCompletion.TaskId.ToString();

                var settings = ApplicationData.Current.LocalSettings;

                switch (taskCompletion.Name)

                {

                    case SampleBackgroundTaskName:

                        SampleBackgroundTaskStatus.Text = settings.Values[key].ToString();

                        break;

                    case SampleBackgroundTaskWithConditionName:

                        SampleBackgroundTaskWithConditionStatus.Text = settings.Values[key].ToString();

                        break;

                    case ServicingCompleteTaskName:

                        ServicingCompleteStatus.Text = settings.Values[key].ToString();

                        break;

                    case TimeTriggeredTaskName:

                        TimeTriggeredBackgroundTaskStatus.Text = settings.Values[key].ToString();

                        break;

                }

            }

        }

        catch (Exception ex)

        {

            Error.Text = ex.ToString();

        }

    },

    sender,

    e);

}

private void OnProgress(IBackgroundTaskRegistration sender, BackgroundTaskProgressEventArgs e)

{

    SampleDispatcher.InvokeAsync(CoreDispatcherPriority.Normal,

        (task, args) =>

        {

            var taskRegistration = task as IBackgroundTaskRegistration;

            var progressArgs = args.Context as BackgroundTaskProgressEventArgs;

            if ((task != null) && (args != null))

            {

                switch (taskRegistration.Name)

                {

                    case SampleBackgroundTaskName:

                        SampleBackgroundTaskProgress.Text = "Progress: " + progressArgs.Progress + "%";

                        break;

                    case SampleBackgroundTaskWithConditionName:

                        SampleBackgroundTaskWithConditionProgress.Text = 

                        "Progress: " + progressArgs.Progress + "%";

                        break;

                    case ServicingCompleteTaskName:

                        ServicingCompleteProgress.Text = "Progress: " + progressArgs.Progress + "%";

                        break;

                    case TimeTriggeredTaskName:

                        TimeTriggeredBackgroundTaskProgress.Text = "Progress: " + progressArgs.Progress + "%";

                        break;

                }

            }

        },

        sender,

        e);

    }

}

Of course, if you can register background tasks, you probably want to unregister them and make them stop.

The sample unregisters the background task by looping through each task and removing the requested task by name:

foreach (var cur in BackgroundTaskRegistration.AllTasks)

{

    if (cur.Value.Name == name)

        cur.Value.Unregister(true);

}

I’m assuming that you can also unregister the task by using the BackgroundTaskRegistration returned by the original register task call.

The key points to this sample are that there is a contract for Background Tasks that enables the your application to be awakened by Windows to perform some functions in response to time, or system events.

The keys to this sample are that there is a contract you should follow if your application needs to do periodic work while suspended, or running in the background. By following that contract, you’ll find much of the infrastructure you need is built into the operating system.

If you want to experiment with the code (or the slides) while watching, all the samples are here on BitBucket.

Of course, the current VS11 / C# 5 software is a moving target.  When we spoke in January, we were working with a pre-beta CTP of VS 11.  The sample code reflects that drop of the upcoming release.  Jon has written a recent blog post in his EduSync series that describes the changes (some public, some private implementation) between the VS11 preview build and the VS11 Beta build released in March.

Happy async coding!

This sample has quite a few more features to digest. There are six different control scenarios. This application supports landscape, portrait, and snapped orientations. As a result, this post will get longer than my average post.

Screen Orientation Support

Most of the orientation support is provided by the underlying framework. Your application must  respond to the ViewStateChanged event:

Windows.UI.ViewManagement.ApplicationView.GetForCurrentView().ViewStateChanged += 

    new TypedEventHandler

    <Windows.UI.ViewManagement.ApplicationView, Windows.UI.ViewManagement.ApplicationViewStateChangedEventArgs>

    (MainPage_ViewStateChanged);

When you receive this event, you instruct the Visual State Manager to transition to a particular state:

VisualStateManager.GoToState(this, 

    ApplicationView.Value.ToString() + DisplayProperties.ResolutionScale.ToString(), false);

The States must be defined in your main window’s XAML description.  Your XAML must include a <VisualStateManager.VisualStateGroups> node.  This element contains a sub-element called VisualStateGroup.  The VisualStateGroup element contains a number of VisualState elements. These elements are named and those names are the states used in the GoToState call above.  Here’s en edited version from the Controls sample:

<VisualStateManager.VisualStateGroups>

     <VisualStateGroup x:Name="OrientationStates">

          <VisualState x:Name="FullScreenLandscapeScale100Percent"/>

          <VisualState x:Name="FilledScale100Percent">

         <!-- elided -->

          </VisualState>

          <VisualState x:Name="FullScreenPortraitScale100Percent">

         <!-- elided -->

          </VisualState>

          <VisualState x:Name="SnappedScale100Percent">

         <!-- elided -->

          </VisualState>

          <VisualState x:Name="FullScreenLandscapeScale140Percent">

         <!-- elided -->

          </VisualState>

          <VisualState x:Name="FilledScale140Percent"/>

          <VisualState x:Name="FullScreenPortraitScale140Percent">

         <!-- elided -->

          </VisualState>

          <VisualState x:Name="SnappedScale140Percent"/>

     </VisualStateGroup>

</VisualStateManager.VisualStateGroups>

This application supports eight different visual states.  See the documentation for the ViewStateChanged event for more details.

Once the app is loaded, it runs mostly like a familiar WPF or Silverlight application. There is a control for the list of scenarios.  When you select a different scenario, the main window loads the input and output panes for that scenario.

With only one exception, the scenarios are entirely coded in XAML. Rather than put a lot of declarative XAML in the enntry, I’ll point out the big picture concept:

If you have been writing WPF or Silverlight applications at all, the XAML used for the WinRT controls will be completetly familiar to you. Run the application, and you can likely guess exactly what the XAML looks like.

So far, Windows 8 apps look a lot like WPF or Silverlight apps (if you are a C# or VB.NET developer).

Your Users Start in Metro

Do you want your application front and center in your users’ cognitive space? Do you want them starting and running your application everyday?  Once Windows 8 comes out, that means running as a Metro App. If you want your application visible on a daily basis, using live tiles to update status, and enticing customers to launch your app, your application must be in the Metro start menu.

Modern Apps win

You have a choice of environments in Windows 8:  “Modern” (meaning Metro) and “Desktop”, meaning, well, not modern.  If you’re competitors are more modern than you are, they will win.

Touch First wins

The Modern interface is a touch first experience. Chris Hoffman is not the first author to mention the phenomena of wanting to use touch on his windows 7 machine after using Metro. It really is compelling. Once your users have a touch-first experience, they will gravitate toward those applications that work for them in the touch environment. If your application is the competitor with a solid touch experience, you can successfully take marketshare from competitors that have not made a touch investment.

Desktop applications are not first-class apps

The Desktop is a Metro app. That means desktop apps do not show up as individual apps in the task bar, or in task switching. They have limited features for sharing, standard metro menus, and more.

Metro apps will be more fully integrated into the Windows 8 experience than any legacy desktop applications.

Metro Apps have greater market reach

Windows 8 runs on Intel x86 and i64 processors. It also runs on ARM processors, used on tablet devices where battery life is a key driver.  Traditional desktop applications will not install on ARM devices running Windows 8 (exceptions may be made for Office, Windows Explorer, and a few other Microsoft applications.  If you want to reach the greatest market, you must create Metro apps.

The Windows App Store sells Metro Apps

The Windows App store makes it easy to install apps, try them, rate them, and purchase enhanced versions or add ons. It makes it easier for customers to try new applications safely, and purchase those apps they like the best. The App Store keeps track of the apps a user has purchased, and automatically installs any updates and bug fixes. That lowers your support costs: users will be automatically upgraded to the latest released version.

OF course, those business features are only available for Metro apps. If you’re trying to sell legacy desktop mode apps, you must still manage this entire process yourself. Once again, Metro apps incur lower costs, and gain new benefits from the ecosystem.

Some closing remarks

Windows 8 is a big change from Windows 7.  When it is released, existing Windows 7 apps will look as dated as Windows 3.1 applications looked when Windows 95 released. That change drastically modified the marketplace at the time. Those companies that were ready to ride the wave of Windows 95 started a very impressive growth curve. Their competitors that bet against change slowly faded from relevance. Regardless of the platform, the software industry has proven time and again that betting against the latest upcoming release is a bad idea. Stay close enough to the leading edge to stay relevant.

Let me start by noting that all these samples are designed to show how the API is structured.  These samples do not show proper separation of concerns, or architectural patterns like MVVM. In fact, all the code is in the CodeBehind for the MainWindows.xaml.cs.  Oh well, that’s not what the samples are teaching.

There are two key takeaways from this sample.  First, IO programming in WinRT is very similar to IO programming in the .NET Framework. The addition of the ‘await’ keyword before each call is the only new technique here. Second, Metro applications should not just browse the file system for storage locations.  Each application should restrict its storage to the application specific document library.  The code shows both of these concepts pretty clearly.

The main Window’s Initialize() code initializes a StorageFile object by searching for the file on disc, and creating the associated StorageFile object (asynchronously, of course):

async void Initialize()

{

    try

    {

        sampleFile = await Windows.Storage.KnownFolders.DocumentsLibrary.GetFileAsync("sample.txt");

    }

    catch (FileNotFoundException)

    {

        // 'sample.txt' doesn't exist so scenario one must be run

    }

}

The other file APIs all work in a similar fashion.  Reading a file looks almost exactly like reading a file with the current .NET BCL library:

async void Scenario2ReadText_Click(object sender, RoutedEventArgs e) 

{ 

    if (sampleFile != null) 

    { 

        string fileContent = await FileIO.ReadTextAsync(sampleFile); 

        this.Scenario2Output_textblock.Text = "The following text was read from '" + 

                sampleFile.Name + "':" + Environment.NewLine + Environment.NewLine + fileContent; 

    } 

}

The Streaming APIs are also present, and look quite familiar:

async void Scenario4WriteToStream_Click(object sender, RoutedEventArgs e)

{

    if (sampleFile != null)

    {

        string userContent = Scenario4Textbox.Text;

        if (!String.IsNullOrEmpty(userContent))

        {

            using (IRandomAccessStream writeStream = await sampleFile.OpenAsync(FileAccessMode.ReadWrite))

            {

                using (DataWriter dataWriter = new DataWriter(writeStream))

                {

                    dataWriter.WriteString(userContent);

                    await dataWriter.StoreAsync();

                    await dataWriter.FlushAsync();

                    this.Scenario4Output_textblock.Text = "The following text was written to '" +

                        sampleFile.Name + "' using a stream:" + Environment.NewLine + Environment.NewLine +

                        userContent;

                }

            }

        }

        else

        {

            this.Scenario4Output_textblock.Text =

"The text box is empty, please write something and then click 'Write' again.";

        }

    }

}

async void Scenario4ReadFromStream_Click(object sender, RoutedEventArgs e)

{

    if (sampleFile != null)

    {

        using (IRandomAccessStream readStream = await sampleFile.OpenAsync(FileAccessMode.Read))

        {

            using (DataReader dataReader = new DataReader(readStream))

            {

                uint numBytesLoaded = await dataReader.LoadAsync((uint)readStream.Size);

                string fileContent = dataReader.ReadString(numBytesLoaded);

                this.Scenario4Output_textblock.Text = "The following text was read from '"

                    + sampleFile.Name + "' using a stream:" + Environment.NewLine + Environment.NewLine + fileContent;

            }

        }

    }

}

I won’t simply repost the rest of the code. This is enough to ensure that you get the main ideas.  There are two main ideas to get across from this sample:

1. Store your application’s data in the application specific sandbox.

2. Use the familiar IO APIs, but remember that they are async.