Category: Experience

Few days after the Dream Build Launch hackathon held at Microsoft Singapore office, Desmond and I received an email from Microsoft. The email is to inform us that our app, EsplanadeGo!, that we built during the 24-hour hackathon was selected as one of the applications with high potential on the Windows Store and thus both of us got the opportunity to take part in the Premier Field Engineer (PFE) consultation sessions.

I had been excited about it ever since I received the email and confirmed the 2-hour timeslot for our PFE consultation session. We’re actually invited twice to the PFE consultation session. The first time was in 25 July. During the consultation session, we received feedback from Noemi, Premier Field Engineer from Microsoft Philippines, through Skype. During the consultation session, we went through each item listed on Application Profile Survey. In the survey, as the developers of the app, we needed to answer the questions related to the user experience, user interface and performance of our app.

Through the PFE consultation session, we found out some of the mistakes we made in our app. With the suggestion given by Noemi, we were able to further improve our app which was later reviewed again in 16 August. After the second review, we were finally granted a token which allowed us to submit our Win8 app to the Windows Store. Hence, I decided to have this post to share the problems we encountered in our Win8 app development journey as well as some of the solutions we tried.

Network Connectivity Detection

As what Justin shared in his talk “HTML5 – The road to multi-platform serenity” during the Geekcamp.SG, it’s important to check for the network connection status of a mobile device and to make sure the mobile apps that we build can function properly even in an environment without the Internet access.

I only found out that EsplanadeGo! would crash in Airplane Mode after the end of the hackathon. During our first consultation session, we were advised to use the ConnectionProfile from Windows.Networking.Connectivity to check for network status and to receive network status change event.

In order to have the event handler to be added to the NetworkStatusChanged event at the moment our app runs, we have the following code in our App.xaml.cs.

namespace EsplanadeGo
{
    public delegate void NetworkStatusKenaChangedEventHandler(object sender, NetworkStatusKenaChanged e);
    ...

    sealed partial class App : Application
    {
        public static event NetworkStatusKenaChangedEventHandler NetworkKenaChanged;
        public static bool registeredNetworkStatusNotif = false;
        ...

        public App()
        {
            ...
            if (!registeredNetworkStatusNotif)
            {
                NetworkInformation.NetworkStatusChanged += new NetworkStatusChangedEventHandler(OnNetworkStatusChange);
                registeredNetworkStatusNotif = true;
            }
    }

    public statis bool isConnected()
    {
        ConnectionProfile profile = NetworkInformation.GetInternetConnectionProfile();
        return (profile != null && profile.GetNetworkConnectivityLevel().Equals(NetworkConnectivityLevel.InternetAccess));
    }

    void OnNetworkStatusChange(object sender) 
    { 
        NetworkKenaChanged(this, new NetworkStatusKenaChanged(isConnected()));
    }

    ...
}

The reason why we have another event defined by us triggered when OnNetworkStatusChange event occurs is that we need to show a message to our user telling him/her that there is currently no Internet access. However, we cannot directly add the code in OnNetworkStatusChange() because a change to the UI through a non-GUI thread will raise an error: Element not found.

After doing some searching on the Internet, I found a solution suggested by invalidusername on StackOverflow. Although that is a Windows Phone 7 related discussion, his method works very well in our Win8 app. So, when App class receives a notification about the change of network connectivity status, it will trigger another event, NetworkKenaChanged, which is subscribed by all the pages in our app. As a result, no matter where the user enters our app, the user will always receive the notification about the change of network connectivity.

Here is what we have in our NetworkStatusKenaChanged class (By the way, “kena” is Singlish, which is served as the passive marker as “by” in English).

public class NetworkStatusKenaChanged:EventArgs
{
    bool isConnected = false;

    public NetworkStatusKenaChanged(bool isConnected):base()
    {
        this.isConnected = isConnected;
    }

    public book ConnectionStatus
    {
        get { return isConnected; }
    }
 }

Thus, in every single page in our app, after subscribing the event, what we need to do is just having the following code to show the message telling our user that there is no Internet connection.

private async void App_NetworkKenaChanged(object sender, NetworkStatusKenaChanged e)
{
    if(App.isConnected())
    {
        await Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPrority.Normal, 
            async() => { RetrieveItemInfoFromWeb(); });
    }
    else
    {
        await Dispatcher.RunAsync(Windows.UI.Core.CoreDispatcherPrority.Normal, async() =>
            {
                MessageDialog msg = new MessageDialog("There is no Internet connection.", 
                    "No Internet Access");
                await msg.ShowAsync();
            });
    }
}

Local Storage

In the first design of our app, Esplanade web pages would be crawled each time when the app was launched. As suggested in the Application Profile Survey, unnecessary or repeated downloads should be minimized. Thus, now, our app will crawl one Esplanade web page only when a certain tile is clicked by the user.

In addition, since the data we use in our app is live data. So, we need to store the data in local storage so that our app is still usable under the environment without the Internet access.

There are nothing much to store in local storage for our app. What we are going to store is just be the info of the events, such as date, venue and description of the event. Since they are just texts, so we can easily do the local storing with ApplicationData.LocalSettings, as shown below.

// For storing local settings
Windows.Storage.ApplicationDataContainer localData = Windows.Storage.ApplicationData.Current.LocalSettings;
// Save event info to Local Settings
localData.Values["Title"] = individualEvent.Name;
localData.Values["Subtitle"] = individualEvent.DateTime;
localData.Values["ImagePath"] = individualEvent.ImagePath;
localData.Values["Description"] = individualEvent.Venue;
localData.Values["Content"] = synopsis.ToString();

To retrieve the information from local storage, we simply need to use the ApplicationDataContainer.Values property to access the setting in the localData container.

Cached Images Hide-and-Seek

Something that I did not find out before attending the second PFE consultation session is that how come the event thumbnails are cached without us doing anything in our code.

During the second consultation session, we spent about half an hour just to find out the place where the thumbnails were cached. It turns out that the cached thumbnails are actually located in “C:\Users\<UserName>\AppData\Local\Packages\<AppName>\AC\INetCache”. It is a hidden folder which “Hide protected operating system files (Recommended)” under the Folder Views needs to be unchecked first before it can be visible.

For the <AppName>, it can be found in the Windows App Certificate Kit Test (WACK) Results report.

It is interesting to know that the caching of images used in the app is automatically handled without doing any programming. Thus, we only store the path to the image in the local settings without storing the image itself.

Besides, under the directory “C:\Users\<UserName>\AppData\Local\Packages\<AppName>\Settings”, there should be a file named settings.dat where values stored in local settings can be found.

Handle PLM State Appropriately

PLM stands for “Process Life-cycle Management”.  As stated in the Application Profile Survey, handling PLM is “to allow your users to switch across apps and feel like they never left your app”.

One way of doing that is saving the application data when the app is being suspended. This helps the app to be resumed even if it is terminated by Windows. There is, in fact, a list of official guidelines for app suspend and resume available as well.

For our app, EsplanadeGo!, due to the fact that we already store the relevant information when the user clicks on a tile, so we do not need to write any code for the app suspend. What we do is actually just to have the following code in the App.xaml.cs to load the saved states of the app.

/// <summary>
/// Invoked when the application is launched normally by the end user. Other entry points
/// will be used when the application is launched to open a specific file, to display
/// search results, and so forth.
/// </summary>
/// <param name="args">Details about the launch request and process.</param>
protected override async void OnLaunched(LaunchActivatedEventArgs args)
{
    // Do not repeat app initialization when already running, just ensure that
    // the window is active
    if (args.PreviousExecutionState == ApplicationExecutionState.Running)
    {
        Window.Current.Activate();
        return;
    }
    // Create a Frame to act as the navigation context and associate it with
    // a SuspensionManager key
    var rootFrame = new CharmFrame { CharmContent = new CustomCharmFlyout() };
    SuspensionManager.RegisterFrame(rootFrame, "AppFrame");
    if (args.PreviousExecutionState == ApplicationExecutionState.Terminated)
    {
        // Restore the saved session state only when appropriate
        await SuspensionManager.RestoreAsync();
    }
    if (rootFrame.Content == null)
    {
        // When the navigation stack isn't restored navigate to the first page,
        // configuring the new page by passing required information as a navigation parameter
        if (!rootFrame.Navigate(typeof(ItemsPage), "AllGroups"))
        {
            throw new Exception("Failed to create initial page");
        }
    }
    // Place the frame in the current Window and ensure that it is active
    Window.Current.Content = rootFrame;
    Window.Current.Activate();
}

If you are using a template project offered by Visual Studio 2012, then all these are actually done for you already. Thanks nice guy Visual Studio. =P

So, when will the app terminated? According to MSDN on the topic of application life-cycle, “Windows may terminate your app after it has been suspended for a number of reasons. The user may manually close your app, or sign out, or the system may be running low on resources.” Thus, in the code above, there is this line which helps us to check if the app is terminated by Windows or not:

args.PreviousExecutionState == ApplicationExecutionState.Terminated

Settings Charm

Another thing we added to the second version of our app is the About and Privacy pages added to the Settings Charm. To do that, we first downloaded and installed the CharmFlyout package provided by NuGet.org. There is a very detailed tutorial written by John Michael Hauck on how to add CharmFlyout to Grid App.

Meanwhile, it is also important to not show permissions that are not even used in the app. For example, an app like our EsplanadeGo! which only display data should not have permission settings like Webcam, Microphone, Location and so on. All these can be managed under the Capabilities tab in Package.appxmanifest.

App Bar

In the second version of EsplanadeGo!, we introduce a Refresh function in the App Bar. The position of the button in App Bar is important. Based on and the UX design guidelines in MSDN and the official guidelines for commands in the App Bar, we should always places persistent and default commands on the right side of the App Bar and starts our commands on the right.

The following is the XAML code to include a Refresh button in the App Bar.

<Page.BottomAppBar>
    <AppBar x:Name="BottomAppBar1" Padding="10,0,10,0">
        <Grid>
            <Grid.ColumnDefinitions>
                <ColumnDefinition Width="50*"/>
                <ColumnDefinition Width="50*"/>
            </Grid.ColumnDefinitions>
            <StackPanel x:Name="LeftPanel" Orientation="Horizontal" Grid.Column="0" HorizontalAlignment="Left">
            </StackPanel>
            <StackPanel x:Name="RightPanel" Orientation="Horizontal" Grid.Column="1" HorizontalAlignment="Right">
                <Button x:Name="Refresh" Style="{StaticResource RefreshAppBarButtonStyle}" Tag="Refresh" Click="Refresh_Click"/>
            </StackPanel>
        </Grid>
    </AppBar>
</Page.BottomAppBar>

Previously, we wrongly put a Share command in the App Bar to invoke sharing. This is, in fact, not a recommended way of using the App Bar, as specified in the guidelines for sharing content.

RenRen with Our App: Share Fun with Your Friends

The reason why we had a Share command in the App Bar is because we implemented Share Source Contract in our app. When I first heard about Sharing Charm two month ago, I had always wanted to tried it out once myself.

To have this feature, I use DataTransferManager in our app. The following code is what I have in one of our pages to allow user to share an event info, such as event name and description to other app (RenRen HD, Mail, etc.).

DataTransferManager dataTransferManager;
protected override void OnNavigatedTo(NavigationEventArgs e)
{
    base.OnNavigatedTo(e);
    // Register this page as a share source.
    this.dataTransferManager = DataTransferManager.GetForCurrentView();
    this.dataTransferManager.DataRequested += new TypedEventHandler<DataTransferManager, DataRequestedEventArgs>(this.DataRequested);
}
protected override void OnNavigatedFrom(NavigationEventArgs e)
{
    base.OnNavigatedFrom(e);
    // Unregister this page as a share source.
    this.dataTransferManager.DataRequested -= new TypedEventHandler<DataTransferManager, DataRequestedEventArgs>(this.DataRequested);
}
private void DataRequested(DataTransferManager sender, DataRequestedEventArgs e)
{
    var selectedItem = (SampleDataItem)this.itemsViewSource.View.CurrentItem;
    if (selectedItem != null)
    {
        DataRequest request = e.Request;
        request.Data.Properties.Title = selectedItem.Title != null ? selectedItem.Title : "";
        request.Data.Properties.Description = selectedItem.Subtitle != null ? selectedItem.Subtitle : "";
        request.Data.SetText(selectedItem.Content);
    }
}

Here, I need to apologize to my friends on RenRen because I spammed their wall when I was testing this feature. =P

Logos: Design Is Important Also

During our first PFE consultation session, we were asked to have a better design for our app logo. To give the users a better experience when they are using our app, we were advised to have the same logo used for Wide Logo, Small Logo and Splash Screen.

In addition, it is important not to have app name appeared on both logo and the tile at the same time. Hence, it there is already a word “Esplanade” as part of the logo, then we should hide the app name”EsplanadeGo!” on the tile on Start page.

ProgressRing, Not Onion Ring: The App Is Still Loading!

Back in the old days, we have only things like progress bar to show the loading speed of tasks. Now, in Windows 8, we have a cooler control known as the Progress Ring. I love how a progress ring can be added to the GUI easily with just one line in XAML.

<ProgressRing x:Name="prLoading" Width="32" Height="32" IsActive="True" />

I also read a post on Windows 8 App Developer Blog on how to add a progress ring to the Splash Screen. I like how it explains the app launch events in a detailed manner. Due to the fact that our app does not require additional loading on launch, the Default App Launch without a progress ring is sufficient.

VariableSizedWrapGrid

Thanks to Noemi’s recommendations in our second PFE consultation session, I get to read great tutorials on implementing a variable-sized grid-view cells in the homepage of EsplanadeGo!. The one I read and found it useful is the article posted by Diederik Krols. There is also a documentation on MSDN about VariableSizedWrapGrid.

To implement that look-and-feel, I modified the sample code generated by Visual Studio in SampleDataSource.cs as follows.

namespace EsplanadeGo.Data
{
    public interface IResizable
    {
        int Width { get; set; }
        int Height { get; set; }
    }

/// <summary>
/// Base class for <see cref="SampleDataItem"/> and <see cref="SampleDataGroup"/> that
/// defines properties common to both.
/// </summary>
[Windows.Foundation.Metadata.WebHostHidden]
public abstract class SampleDataCommon : HelloWorldSplit.Common.BindableBase, IResizable
{
    ...
    public SampleDataCommon(String uniqueId, String title, String subtitle, String imagePath, String description, int width, int height)
    {
        ...
        this._width = width;
        this._height = height;
    }

    ...
    private int _width = 0;
    public int Width 
    {
        get { return this._width; }
        set { this.SetProperty(ref this._width, value); }
    }
    private int _height = 0;
    public int Height
    {
        get { return this._height; }
        set { this.SetProperty(ref this._height, value); }
    }
}

Having Dinner with EsplanadeGo!

In the last few weeks, I went to Bugis Junction and some other restaurants with Internet access to have dinner so that I can work on our EsplanadeGo! project after work. Although my daily work is already all about C# and ASP.NET and I have only my dinner time to work on this project, it is still quite fun to work on EsplanadeGo! (Imagine, coding with nice food in a comfortable environment. How fun is that? =P).

Thanks to this project, I get to try many new stuff that I haven’t seen before and share the new technology with my colleagues and my boss. Yup, they all love it very much and would like to learn more about Windows 8 app development. Who knows? Maybe one day our company will have our first mobile app on Surface. =P