SketchFlow to Production
While I have my own beliefs on if this should be allowed or not and personally I am of the school of thought that say that prototype is best left alone. You may lift some concepts from it to take to your production (by age old and still very popular cut paste method), but you should not have a direct path to this conversion. A direct path in my view defeats the very purpose of prototype, which is to try things out and then throw them away (throw the various artifacts, not the learning). Added to that is the point that in UI prototyping you are more interested in getting the look and feel of the screens validated and are neither focusing on the application architecture in terms of layering nor following right coding standards like class naming, method naming etc. hence taking such a code directly to a production targeted project, will break some of the standards that such projects are meant to follow.
Anyway, getting into this debate wasn’t really the purpose of this blog, but that I did want to at least give this option a trial, not for the sake of actually taking anything to production, but to just get a handle on what steps need to be followed. Many people have also written about the 16 odd steps that one needs to do and that it is so painful and all that. Doing these manually, however, didn’t take me more than 5 min.
Most of the steps are pretty trivial and the only place where I have seen some of the people getting stuck a bit is on the final step, where the player is no longer set as root visual, but rather the first screen is set. The challenge here mostly is in figuring out the right name of the XAML file. Blend, by default, names this page as Screen 1.xaml and it is this blank space in the name that possibly ticks people off. The trend that developers are today used to is that the filename and the class name is the same and hence since the class name for this default screen is Screen_1, some people confuse this with file name as well and use that for the XAML file name as well. A related challenge is that while doing your screens, you most likely will rename them as you add them. While this renaming is shown in the SketchFlow map, it actually doesn’t rename the file below. Also the friendly names you see in Blend against the screen name, seem to be Blend specific. If you happen to open this project in Visual Studio (VS) you won’t see these names. In the figure below you can see this difference. The left part shows view in Blend and right shows the view in VS.
I think it will be a good idea for MS to fix these issues.
Further on, having successfully converted my project and I ran it and I could see my first screen load and there was no player, which is what was expected, but my excitement was short lived as my navigate to screen, active state and screen animations no longer worked and I started getting exceptions for the same. If I had some logic built into a control template like doing some animation via control's visual state manager (VSM), it works fine.
[Edited: Jan 20] I had earlier mentioned that navigations didn't work. But they actually do work. The steps to convert to production ask you to remove reference to Microsoft.Expression.Prototyping.Runtime.dll. I had done this, but for some strange reason, when I checked the solution again later, it was still there. Removing it, got the navigation working. The activate state behavior doesn't seem to work still and one solution is to handle appropriate events in code behind and make explicit calls to VSM's GoToState method.
Any comments/opinions? Do write back.
If you know the best way out, do write back.