Dallas TechFest 2011

Phones are personal devices, so users expect their data to be local. But they are also collaborative devices, so users expect them to talk to each other. An occasionally connected Windows Phone application is the best of both worlds. It stores personal data locally for instant access. And it synchronizes with remote services for collaboration.

Correspondence is an open source library specifically designed to make it easy to build occasionally connected applications. When you design your data model using its DSL, it generates both a local database and a network protocol. Then it gives you an object model to code against that seamlessly bridges the two worlds.

Not only will I demonstrate a collaborative Windows Phone application, but I’ll teach you how to write one. You start with the data model, written in a Domain Specific Language called Factual. Then you expose that model through a View Model layer. Data bind your View Model to the UI, and your application is complete.

When the user makes a change, it is both stored to the local database and published to the server. Changes made by other users are automatically pushed to the phone. Through the magic of data binding, the user is instantly notified of the change.

Tool vendors like Microsoft are not the only ones who publish APIs. When we create layered software, each layer has an API that is consumed by the next one up. To ensure the quality of our software, we should try to create provable APIs. These are interfaces that guide the caller to the correct usage patterns. They help the compiler help us to verify the correctness of our code.

An unhelpful API throws exceptions whenever we get something wrong. These kinds of APIs can cause stress and lead to bugs that are difficult to correct. There is a right way to call them, but there is also a wrong way. The wrong way still compiles, but it contains bugs nonetheless.

We will look at a set of language features and patterns that help us to prove that our API is being used correctly. Then we'll walk through some examples of unhelpful APIs to see which of these language features we can apply. We will be in Visual Studio during most of this talk.

* Language features and patterns
o Parameters
o Callbacks
o Foreign keys
o Factories
o Constructors
* Examples
o Shopping service
o Cache
o Phone number
o Connection
o Shopping service revisited
o Practice management system