The following guest blog was written by Joth Pigott of 2434.com Limited.
Our company, 2434.com Limited develops and distributes Backstage, a business application for managing all aspects of a professional classical orchestra from event management to projecting their annual budget. The Backstage database has over 1,000 discrete fields, and the budget projection reports are processor intensive since the payments to each musician for each day are dependent on many factors.
Backstage
Backstage has taken over 10 years to develop and is written in C# on the WinForms platform. It also populates a summary ‘web-app’ optimized for mobiles and tablets written in Javascript. We wrote Backstage as a desktop application rather than an internet/browser based system due to the processor intensive reports and complex interfaces which, 10 years ago, we judged would have loaded too slowly. About 3 years ago we started to actively look at porting Backstage to a new platform. Our principal concern was the feeling that the mobile operating systems (Android, iOs, and UWP) were the platforms of the future and if Backstage couldn’t fully run on them, we may start to struggle to retain our existing customers as well as attract new ones.
We were still reluctant to port Backstage to a browser based solution such as ASP.NET in case it still performed poorly and so were ideally looking at another desktop/app platform. We’ve known of Xamarin and about Mono for many years, but prior to the Microsoft take-over, had read some reports making us uncertain about their future given that we would become totally dependent on their success. Since our company is too small to consider developing multiple native apps in C#, Java, Swift, we experimented heavily with one of the JavaScript/hybrid platforms. However, it was really daunting as it became more and more clear how much work would be involved in porting such a large application to a new language and the real difficulty of then maintaining two solutions until the new one was completed. Then suddenly decisions became very easy when Microsoft announced it was buying Xamarin. Xamarin appeared to tick every box. We decided to build a Xamarin.Forms application using a Portable Class Library (PCL) and, due to the limitations of the PCL compared to the full .NET Framework, we would re-write existing functions in the WinForms Backstage where necessary to work with the PCL so as much of the code-base as possible could be shared.
The next issue was deciding on a component vendor. Key components of Backstage are a powerful scheduler as well as heavy integration with Microsoft Office products – particularly Excel. This choice was in fact very easy in that, at the time of looking, Syncfusion were the only Xamarin partner to offer a scheduler. We then found we qualified for their free community license! This seemed too good to be true, although we were nervous about what level of support would actually be offered to free customers. However, we found their forums and online documentation extensive and had absolutely no reason not to give them a go.
The Syncfusion Community License Offers full support to qualifying developers.
We have in fact had to make considerable use of their support which has proved excellent. WinForms is a very mature product that has a large repertoire of complex controls that are very quick to work with due to the excellent visual designer in Visual Studio. Working with Xamarin and XAML is a very different experience with a considerable learning curve. We’ve visited a number of developer conferences and know we are not the only ones to experience that. Getting code to compile on the various platforms was initially very frustrating. However, once you’ve learned where everything sits and what the various compile errors actually mean, it becomes very useable.
Xamarin Forms is also very spartan compared to WinForms due to the limitations of the common controls on all the various platforms. For example, it lacks a checkbox or multi-select dropdown which we make heavy use of in WinForms. However, there are workarounds – you just have to be a bit more creative. For example, we built our own multi-select control based on the Syncfusion SfNavigationDrawer and SfListView. In the scheduler, we also wanted a ‘status bar’ on each event, which the Syncfusion SfScheduler doesn’t offer out of the box. However, their free community support returned to us in under 24 hours a project showing us how to enhance the scheduler to show the status of an event.
As for now, we’ve got many months ahead of porting the code across. Howeve,r it’s a great feeling to believe that you’ve chosen the very best tools for the job combined with the knowledge that every year they will get better and more fully featured together with mobiles and tablets getting even more powerful. Many thanks to Microsoft, Xamarin, and Syncfusion!