Last weekend I participated in the first Auckland Startup Weekend, an awesome experience run out of Biz Dojo. The weekend kicked off friday night with around thirty people pitching their ideas to the crowd, we ended up pruning the list down to around seven different teams of biz guys (and gals), designers and devs.
As I've been looking to push my Windows Phone 7 skills and possibly do a little evangelising about the platform (especially around the ease and speed of development) I looked for the teams where I could add functionality through a WP7 app.
Ultimately I ended up working with a group putting together a business tentatively named Hotspot built around social recommendation / reputation and location. We had a great team for the weekend with five developers, a designer and three guys dealing with the pitch and direction. By lucky coincidence I ended up in the same team as the guys from Touch Maniacs who have just released their New Zealand business directory application named Poqet Directory.
With so many developers on the team we managed to get quite a bit built, including a Python server feeding JSON data down to an .Net MVC website and the WP7 app. On a side note it was really interesting to see the different teams using different technologies for the startups, the winning team Taxi Surfer built a pair of iOS apps powered by an WCF REST service. It really was a case of using the best tool at hand for the job for every team.
Our team had a great strategy in that by the end of Friday night we knew we were going to be building some sort of location / social / recommendation system, the specifics around the business would still need some ironing out. This let us developers concentrate on building the backbone to the technology without the inevitable pivots affecting us too much, ultimately our superb business guys work away through the weekend on the idea knowing they'll have a good amount of tech backing them up.
To increase the drama a little our PowerPoint presentation failed completely, full credit to our team doing the presentation to the judges as they carried on like nothing was wrong. In fact I think the strength of the presentation despite the lack of slides really did us proud and we ultimately were awarded third!
Overall it was fantastic weekend, it was a great opportunity to meet a lot of similar minded people in Auckland. The amount of energy you get from participating in an event like this lasts for weeks and the seriously talented people you meet really pushes you on. Can't wait for the next one.
On a side note the winning team Taxi Surfer has already received their first C & D.
As a developer for Windows Phone 7 one app I've found incredibly useful is AppTracker from Very Software. It quickly brings together all reviews for an app from the different marketplaces.
It quickly gives me an idea of how new versions of To Do Today are performing and also when there are new reviews.
I highly recommend you check it out on the Marketplace
In the MVVM (Model, View, ViewModel) pattern in xaml based applications (Windows Phone 7, Silverlight and WPF) there are two different ways a view model will notify the view of changes. If you're unaware of the differences you can end up wondering why your changes aren't being reflected in your view.
The most common is implementing the INotifyPropertyChanged interface, the other is through the INotifyCollectionChanged interface. Most developers really won't use second interface but its useful to know about and how it affects your view model.
When you bind to a property on your view model the binding infrastructure will listen for INotifyPropertyChanged events from your view model for that property.
If the type of the property implements INotifyCollectionChanged (such as ObservableCollection) it will also listen for events off that property.
The distinction is important because a common pattern with developers is implement collection properties as automatic properties. This however limits the way you can interact with the collection such that changes will be reflected in the view.
publicclassCorrectViewModel : ViewModelBase
{
public CorrectViewModel()
{
Items =newObservableCollection<Item>();??
}
publicObservableCollection<Item> Items
{
get; set;
}
publicvoid Add()
{
var items = GetItems();
Items.Clear(); // Collection changed raised
foreach(var item in items)
{
Items.Add(item); // Collection changed raised
}
}
privateIEnumerable<Item> GetItems()
{
returnfrom i inEnumerable.Range(0, 10)
selectnewItem
{
Name ="Item: "+ i
};
}
}
publicclassIncorrectViewModel : ViewModelBase
{
public IncorrectViewModel()
{
Items =newObservableCollection<Item>();
}
publicObservableCollection<Item> Items
{
get;
set;
}
publicvoid Add()
{
var items = GetItems();
Items =newObservableCollection<Item>(); // No notification raised
foreach(var item in items)
{
// Collection changed raised but view unaware of new collection
Items.Add(item);
}
}
privateIEnumerable<Item> GetItems()
{
returnfrom i inEnumerable.Range(0, 10)
selectnewItem
{
Name ="Item: "+ i
};
}
}
Notice the difference between the correct view model and the incorrect one is that the correct one alters the already existing collection and the view is notified with INotifyCollectionChanged events. The incorrect view model replaces the collection with an entirely new one, but because the automatic property doesn't fire an INotifyPropertyChanged event the changes will not be reflected in the view.
The incorrect view model can be fixed by either modifying the Add method to not replace the collection but modify it in place, or to modify the Items collection to fire property changed events.
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.
publicvoid 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.
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.
