Welcome, join me into this series of a Journey of a Windows Phone 7 application: from mere ideas to real deployment into Marketplace Hub.
This journey has the purpose of share with you my experiences of designing, creating and deploying the InputStudio application.
This experiences have much to do with nice people like Jesse Liberty and the SilverlightShow community whose blog posts always were for me at the exact time when I needed (sterling/OData/MVC3/Silverlight Code Testing/etc), Thank you!.
This initial post should give you an idea of the whole of the project. Subsequent posts will dig in detail on each of the aspects of the application, some with sample code.
First of all, since long time ago I had the wish burned on my mind to create an application killer, an application where you can create applications easy and quickly: the dream of every software developer. Finally, the conditions were there so I was able to start the making of my app.
As a starting point, the app needed to be bind to a specific domain: I choose to address the problem of data recording/processing, where you have specific needs:
- you want to track your car’s mileage performance.
- you want to track your travel expenses.
- your wife wants to manage her small cloths business sales.
- you want to keep a record of your house bills, and so on.
Why the Windows Phone 7 platform?
From previous experiences I’ve had while working at some outsourcing companies providing software solutions, I decided the app should work based on configuration vs binary code; what I mean, is the applications created in InputStudio should be just configuration files that can be then executed by some sort of interpreter (player); this is different from appMakr where each created application needs to be published into Marketplace Hub. With appMakr you end up with many binary applications in your phone while in InputStudio you just have one binary and many configurations; by the way appMakr and InputStudio solve problems for different domains.
As an obligated consequence of this selection, the configuration format had to be chosen. I choose the xml format because of several reasons:
- Xsd2Code makes your xml definition a class.
- you can create viewlet definitions and test classes (for testing your definitions) by applying xslt transformations.
Of course this application definitions (applications) needed to met certain rules like:
- At least one data entity (business object) must be configured.
- At least one attribute (property) must be configured in a data entity.
- At least one screen (page) needs to be configured.
- At least one data entity needs to be attached (to be rendered) in a screen object, and so on.
All of this application rules and their children ones needed to be validated when saving or navigating back from the designer pages.
Regarding the Tombstoning, as each of the application definition objects and it’s children have and ID of type Guid, just saving that ID makes quite fast the saving and resurrecting of app objects.
The application should also support at least the standard languages (english, deutch, french, italian and spanish) , so it should be a localized app.
The application should follow the Data-First approach where you first create your business objects and the business rules that drive them and then attach (render) that entities into pre-built user controls plugged in some screen (page). Mimicking the real world, this data entities which represent real world objects or concepts should be related one to the others in parent-child relationships.
Some user controls needed then, dynamically create it’s content or input controls (text boxes, list boxes, buttons, etc) based on the attributes (data type, caption, etc) of that data entities.
As you assemble some data entities and screens into a single application, some of this data entities needed to interact with others and resolve some mathematical expressions.
For example: you create an application for you Bank Accounts Management. You have the Accounts data entity which resumes all of your transactions, the Account entity and the Transaction entity. Every time you make a bank transaction you account needs to be updated since the transaction was applied to some specific account and finally, your total balance may be affected. Here is where the great David Cook’s GoldParser library arrives as an expression solver for the Windows Phone 7.
But your data means almost nothing if you can’t use it in MS Excel or another productivity tool? Then the app should be able to export your data in some way easily accessible to you. The chosen format was html.
Another main objective of the app is that the apps created could be easily shared with a community of users, in such a way that you can import apps created by others based on it’s rating the community give them. To address this feature an ASP.NET MVC 3 application with some web services support needed to be created.
This is all for now but stay tuned for the following series part.