Skip to main content

Please welcome FINDaPAD to the WP7 app store

I'm proud to announce the release of FINDaPAD into the WP7 app store, it's been a long journey working on this app and I'd like to thank my co-workers Rich & Nick for all their hard work. We've spent the last 6 months working on this at the weekends and as with all software released to market the last few weeks seem to have been the hardest.

So what is a FINDaPAD? 

FINDaPAD is a property search app for buy or rental properties in the UK housing market.

We aren't the first app to go to market offer property search services but we do believe we offer something different from a UI perspective - we've tried to follow the Metro-style guidelines for WP7 as much as possible. The app is very much designed with the idea of being used when you're out & about looking for properties and you need a quick and easy way to search the local area. You also have the ability to search locations using post code, place name or geo-location.

The rest of this post describes the technologies used in developing the app.

The app is currently NOT a mango app - yes I've said it, it's NOT a mango app. The simple reason being we started the app on the 7.0 and we took the decision in late August not to move to Mango until after we had a stable release. August might seem a long time ago but when you're trying to get something out of the door, days and weeks seem to go by very quickly indeed. The app was first submitted for approval prior to the Microsoft BUILD conference in early September and after two failed submissions it was finally approved and in the store by late September.

You might be wondering why wait until now to start talking and publicising the app? We realised after getting the app into the market place there was still plenty to do - website, twitter, PR, support, etc. We choose the achievement of a successful submission to be a soft launch of the app with friends and relatives testing and giving feedback. Since the initial release we've submitted eight updates to the market place in the last 6 weeks, these including a couple of big bug fixes and the addition of missing functionality which only became obvious after family used it to find their new home in Brighton. So now we're ready for a hard release with a PR push.

We built the app using the following APIs, frameworks & libraries:

Nestoria API - open source API providing property information for the UK and other countries,

UK Crime API - open source API providing crime stats for the UK,

WP7Contrib - we use this for all communication with back end web services, custom MVVMLight messenger, UI transitions and custom controls including SmartTextBlock,

Silverlight Toolkit - LongListSelector for infinite scrolling lists and bing maps control,

MVVMLight Toolkit - Laurent's great framework for making life with MVVM easier,

Reactive Extensions (Rx) - we use this for handling asynchronous calls and event subscriptions,

Visiblox - a great charting package for visualising data, big thanks to @ColinEberhardt,

Funq- a compact and fast DI container for WP7,

PreEmptive Solutions - post build weaving of runtime analytics into executables.

We're now working on a Mango release and hope to have this out in a couple of weeks and we're looking forward to performance improvements around HTTP compression support and fast app switching.

Until then happy property searching :)


Popular posts from this blog

Showing a message box from a ViewModel in MVVM

I was doing a code review with a client last week for a WPF app using MVVM and they asked ' How can I show a message from the ViewModel? '. What follows is how I would (and have) solved the problem in the past. When I hear the words ' show a message... ' I instantly think you mean show a transient modal message box that requires the user input before continuing ' with something else ' - once the user has interacted with the message box it will disappear. The following solution only applies to this scenario. The first solution is the easiest but is very wrong from a separation perspective. It violates the ideas behind the Model-View-Controller pattern because it places View concerns inside the ViewModel - the ViewModel now knows about the type of the View and specifically it knows how to show a message box window: The second approach addresses this concern by introducing the idea of messaging\events between the ViewModel and the View. In the example below

Implementing a busy indicator using a visual overlay in MVVM

This is a technique we use at work to lock the UI whilst some long running process is happening - preventing the user clicking on stuff whilst it's retrieving or rendering data. Now we could have done this by launching a child dialog window but that feels rather out of date and clumsy, we wanted a more modern pattern similar to the way <div> overlays are done on the web. Imagine we have the following simple WPF app and when 'Click' is pressed a busy waiting overlay is shown for the duration entered into the text box. What I'm interested in here is not the actual UI element of the busy indicator but how I go about getting this to show & hide from when using MVVM. The actual UI elements are the standard Busy Indicator coming from the WPF Toolkit : The XAML behind this window is very simple, the important part is the ViewHost. As you can see the ViewHost uses a ContentPresenter element which is bound to the view model, IMainViewModel, it contains 3 child v

Custom AuthorizationHandler for SignalR Hubs

How to implement IAuthorizationRequirement for SignalR in Asp.Net Core v5.0 Been battling this for a couple of days, and eventually ended up raising an issue on Asp.Net Core gitHub  to find the answer. Wanting to do some custom authorization on a SignalR Hub when the client makes a connection (Hub is created) and when an endpoint (Hub method) is called:  I was assuming I could use the same Policy for both class & method attributes, but it ain't so - not because you can't, because you need the signatures to be different. Method implementation has a resource type of HubInnovationContext: I assumed class implementation would have a resource type of HubConnectionContext - client connects etc... This isn't the case, it's infact of type DefaultHttpContext . For me I don't even need that, it can be removed completely  from the inheritence signature and override implementation. Only other thing to note, and this could be a biggy, is the ordering of the statements in th