Why You Should Rebuild Your Windows Application

Over the last three weeks we have overhauled our Windows client application. This was prompted by the reaching of our MVP (minimum viable product) and our desire to have a code base that is both updatable and easily debugged. In one of our earlier posts, we discussed our belief in the MVC model and significant code modularity. It was that internal debate that pushed us in this direction. It also gave us a good opportunity to revamp the UI and UX with newer and more professional designs.

We began by trying to adapt as much of the previous code as possible. This meant holding to the same Windows development platform: Windows Forms. Remaining on this platform would guarantee the reuse of our business logic and the libraries would remain. Where problems were likely to be found was on the User Interface (UI) end. The first static designs turned out well. It seemed to be no problem following the images given to us by our UI designer from Bolt.io – our first VC and start-up accelerator.

It was in the implementation of specific UI elements, like a customized list, and animations that we ran into significant problems. As there is no native library option for animations it became difficult to move forward on this platform. We were forced to port our code over to Windows Presentation Framework (WPF). With their XAML layouts and native animation APIs, this development foundation is much better suited to building customized, good-looking and smart UIs. Perhaps we were wrong in our preference for WPF UI design tools, but as the lead on our UI development team has a stronger background in mobile development, this was his preference.

Anyway, the trouble was going to be implementing our business logic solutions within this new framework. This was made easier by them both belonging to Windows Visual Studio and therefore being compatible with C# or C++. Also aiding this switch was our decision to modularize the code. It allowed for us to attach it to the front end piece by piece, whereas before it was an ugly fusion of view and logic.

When we finally started we found little resistance from WPF in the execution of our designs. It was, for the most part an easy switch. We only ran into any trouble when piecing together our custom PasswordBox element. We required it to have a placeholder and as far as we could tell the native object did not have such an option. Our solution was to situate a TextBlock on top of the PasswordBox until it is selected, at which point we send “focus” to the PasswordBox and hide the TextBlock. A simple, but hacked together solution.

In all, this was a rewarding experience. We managed to modularize our code, update our design and add animations to what was once a static application. Beyond that we gained experience in the more modern development environment that is Windows Presentation Foundation. The guys at Infragistics still see a use for WinForms and they may be right. However, my recommendation to all, and I wish that we had found this earlier in our prototyping stage, is to move yourself into a future of glossy UIs and responsive UX.

Contact Us!

Share on Facebook0Share on LinkedIn4Tweet about this on Twitter


You may also like

×