Posted Monday, March 21, 2011 by Nigel Sampson
The eventing mechanisms in .NET are great for being notified when certain things occur, but often you don't care about every occurrence just the next one, really what you're wanting is a callback. The most common scenario I've encountered for this during my development on the Windows Phone 7 is wanting to execute code after an animation is complete and by extension when an animation part of a visual state is complete.
What I want to show is two different mechanisms to create one time event handlers, then how to build simple extension methods to make use of these to create callbacks and then also how to use it with animations and the visual state manager.
The first and easiest method is a self removing event handler, rather than simply adding an event handler to the event we first create the event handler as a separate variable initialised as null. We then initialise the handler as a lambda that does what you need to do and then takes advantage of closures to remove itself from the event.
This can seem quite complicated, what makes this work is that we're splitting what would usually be one statement (declaring the event handler and assigning to the event) into three, declaring the reference to the handler, declaring the handler itself and assigning to the event. By splitting the declaration of the variable and the initialisation means we can reference the variable in the handler itself.
public void AttachWithHandler()
{
EventHandler handler = null;
handler = (s, e) =>
{
MessageBox.Show("Completed!");
storyboard.Completed -= handler;
};
storyboard.Completed += handler;
}
The alternate way is to use the new library from Microsoft called Reactive Extensions this allows us to use a more declarative syntax, for one off event handlers the important method is the Take(1). What's cool about this approach is that you can handle multiple events easily over the first approach. We can also add filters and other features of the Reactive Extensions framework to our handler if required.
public void AttachWithRx()
{
Observable.FromEvent((EventHandler<EventArgs> e) => new EventHandler(e),
e => storyboard.Completed += e,
e => storyboard.Completed -= e)
.Take(1)
.Subscribe(e => MessageBox.Show("Completed"));
}
So now we have our approaches lets build some extension methods to make this into a simple extension method, rather than caring about a full event handler all we really want is to be able to define a callback method and have that executed on event completion. To solve our storyboard completion animation problem we'll create an extension for storyboard that takes a callback and then uses the first approach to use it as a one off event handler.
public static void Begin(this Storyboard storyboard, Action callback)
{
EventHandler handler = null;
handler = (s, e) =>
{
callback();
storyboard.Completed -= handler;
};
storyboard.Completed += handler;
storyboard.Begin();
}
Here's how I'm using it in To Do Today.
private void OnDeleteAll(object sender, EventArgs e)
{
AnimateDelete.Begin(ViewModel.DeleteAll);
}
Posted Wednesday, March 09, 2011 by Nigel Sampson
One of the controls I felt was missing out of the box for the Windows Phone 7 was a Notification control similar to how Toast notifications are displayed. As part of an application I'm working on I need a control like this with some of the animation effects the toast has.
On a side note the Coding4Fun Toolkit has a more fully featured control but lacks good view model integration (to be fair 90% of controls do).
It has three properties, Title and Text (I'll most likely be adding an icon at a later date) are fairly self explanatory, the third OnDimiss is a callback when the notification is dismissed by a tap.
<controls:Notification x:Name="Notification" />
From the code behind it displayed with the following calls.
private void OnDisplay(object sender, RoutedEventArgs e)
{
Notification.Display("Title", "Text", () =>
{
MessageBox.Show("Dismissed", "The notification control has been dimissed", MessageBoxButton.OK);
});
}
private void OnDismiss(object sender, RoutedEventArgs e)
{
?Notification.Dismiss();
}
From a view model we can expose a unit testable notification source and bind that to the control.
public class NotificationViewModel
{
public NotificationViewModel()
{
Notifications = new NotificationSource();
}
public INotificationSource Notifications
{
get;
set;
}
public void Display()
{
Notifications.Display("Security", "Tap to authenticate the application", () =>
{
MessageBox.Show("Authenticated", "The application has been authenticated against the server", MessageBoxButton.OK);
});
}
}
The source code here contains the code for this notification control as well as the Status Indicator control.
Posted Thursday, February 24, 2011 by Nigel Sampson
An avid reader of startup blogs I've always enjoyed reading about the companies that are completely transparent about their numbers, how the company is going and the history for those numbers. There are some great lessons that can be learned from other companies when they do this. So I thought I'd do the same for the first three months of my first app To Do Today.
A bit of history first, To Do Today was originally written with the idea of building my first app in a relatively known domain and to get my feet wet in building and releasing an app into the marketplace.
I released the first version around the 11th of November 2010, not long after the launch of the phone. Thankfully with a decent emulator released before launch I had a good head start to build what I considered my Minimum Viable Product, a very simple task manager, no categorisation or anything I'd consider advanced.
At launch the things that I thought made it unique was that it the app that fit the closest with Windows Phone 7 "Metro" design language and had some usability short cuts to let users select "Today", "Tomorrow", "This Week" etc. as due dates.
About two months after launch (early January 2011) I rolled out the first major update (1.2) including recurring tasks as a feature. It was one of three major feature requests I was receiving via email and given no other task app in the marketplace supported the feature I felt it was the obvious choice to concentrate on.
In late January, early February I released the next major update (1.4) that added categories for tasks, I've been receiving positive feedback for both releases and the average review score has been climbing.
The numbers
In total To Do Today has been downloaded 1,150 times in the last three months 234 of those have been paid downloads. The history of the trial vs paid downloads is as follows:
The initial trend that jumps out is the spike in downloads in the first month after launch, followed by a decline to a another steady rate, although in the last month or so daily sales figures are rising again. An interesting note is the complete lack of Christmas bump, I'm not sure why that is.
From what I can see the inadvertent price change in early January (discussed in What went wrong) and no effect on sales.
The latest version update looks to have had a positive effect on sales, I'm crossing my fingers that this continues.
What went right
Looking at the numbers you'll see the conversion rate from downloading the trial (which is limited to four tasks) is hovering around 20% which I'm really happy about. Hopefully I can keep the conversion rate going as the marketplace increases in volume.
Given the market size of the phone users, the fact that the app hasn't been featured by Microsoft or any major website the numbers fall in line with my expectations when compared other platforms in similar situations.
The "Metro" design of Windows Phone 7 really appeals to me and for someone with limited design skills a lot of the resources available allow one such as me to build something that looks like it fits in with the rest of the phone. I believe a lot of initial sales were driven by this.
The decision to reorder my feature priorities and release recurring tasks in the first update was the correct one. I believe getting recurring tasks out as a unique selling point (at that time) was beneficial.
The marketplace submission process has been fairly painless, the average turnaround on any submission was around 48 hours. There were a couple of rejections, initially frustrating but I think some of the feedback from the rejection made the app a better product.
What went wrong
One thing that got the best of me is that the Windows Phone marketplace doesn't pre-populate the update forms with the existing details of the application. You have to re-populate all your tags, descriptions, categories and so forth.
This was where my attention to detail slipped and I posted an app update in the wrong category with the wrong price. The unfortunate extra detail on this is that the default category is Games / Puzzles, so suddenly my app moved from the standard menu into the Games hub. As soon as I noticed I pushed another update, in total it was placed incorrectly for about six days.
I'm not entirely certain whether the shift in category is related, but by the time it made it's way back to the Productivity category it came in about fifteen places lower in the category and as since slipped further down the lists.
The price change was the other missed change, I had accidentally upped the price from $1.99 to $2.99, I noticed this pretty quick but decided to leave it as an experiment. It hasn't had an adverse affect on sales, but I may lower it again to see if it has a positive affect.
At the time of wiring To Do Today received 21 reviews with an average of 6.95 / 10 according to the marketplace aggregation website on Windows Phone Geek. One thing you'll notice a number of 0 / 10 reviews with comments that don't warrant such a harsh score. This I believe is a side effect of the Zune software where people are entering comments without posting a rating and therefore rating it a 0.
Quite frustrating and no real way for me to deal with it. Looking at iOS and Android sites there doesn't seem to be any better ways to deal with negative reviews in other marketplaces once they're posted, but there are strategies to prevent them.
A great point of difference for WP7 are the Live Tiles on the home screen, being able to display useful information in those tiles provides a fantastic feedback mechanism and can add real polish to an app. A task management app really lends itself to a Live Tile as well. Unfortunately my attempts have been hampered so far in adding one, I've covered the technical reasons why in "Why To Do Today doesn't have a Live Tile".
Lessons learned
So what have I learned from the process so far?
The first is to check, double check and triple check the details of any submission to the marketplace, a stupid mistake by me here certainly cost.
Provide easy in-app mechanisms for users to send you feedback. This will give you a way to start a dialogue with a frustrated user that would be impossible if they just left a negative review. During the latest update I ensured the support email address on the about page was clickable, this tripled the amount of email feedback and I haven't had a negative review since.
Where to from here?
From a functionality point of view I think To Do Today is pretty much complete. If the capability to add decent Live Tiles becomes available I'll certainly be adding that. Otherwise the most requested features are different integration points which I'll be leaving out for the moment. The goal being a simple stand alone app.
In terms of my next app I'm currently in the process of brainstorming that.
What I'd like to see
In terms of the marketplace I'd love to see better access to sales figures, compiling the above graphs was such a pain in the ass. Also populating updates with app details would be nice.
On the technical side, better Live Tiles, more integration with phone software and hardware would go a long way to being able to create better apps.
Posted Monday, February 21, 2011 by Nigel Sampson
A lot of the built in applications have really subtle transitions and effects that really add polish to an existing application. In the process of building a new application I've been working on mimicking those controls. The first I'm releasing is the Status Indicator most commonly seen in the email application.
It's a fairly simple control that has two properties Text and InProgress controlling both the displayed status and whether the progress bar should be displayed. The control exposes two methods Display and Clear to easily set the properties of the control as well as manage state for nice animated transitions between the two.
<controls:StatusIndicator x:Name="Status" />
private void OnDisplay(object sender, RoutedEventArgs e)
{
Status.Display("Loading...", true);
}
private void OnClear(object sender, RoutedEventArgs e)
{
Status.Clear();
}
One thing that frustrates me when dealing some out of the box controls is that there's often no nice way to interact with the control when using some sort of UI separation pattern such as MVVM. To deal with this the control exposes a Source property, you can then have a property on your view model that implements the IStatusSource interface and will allow you to determine the properties and state of the control from your view model. It's all very unit testable as well!
<controls:StatusIndicator Source="{Binding Status}" />
public class StatusViewModel
{
public StatusViewModel()
{
Status = new StatusSource();
}
public IStatusSource Status
{
get; set;
}
public void Display()
{
Status.Display("Updating", true);
}
public void Finish()
{
Status.Display(String.Format("Updated {0:d}", DateTime.Now), false);
}
}
Of course here's the source code.
