More Reactive Traders!

Since releasing Reactive Trader earlier this year at React Conf, we have been busy working on a number of ports to other platforms. This work took place over a couple of months earlier this year. We have already talked about development of a web version – if you’d like to know more, I suggest having a listen to the interview I did with Scott Hanselman.

2014-09-04 15_49_11-Reactive TraderMore recently, we also published Reactive Trader to the Windows Store, available here for Windows 8.1. That port was relatively straightforwardly, and was based on the WPF version that we originally wrote for React Conf. We will write a blog post outlining the specific techniques and architecture we moved to to support multiple Windows version of Reactive Trader in the coming weeks.

Reactive Trader for iOS

Photo 04-09-2014 15 50 13We are also very excited to now announce, somewhat belatedly, Reactive Trader for iOS. You can get Reactive Trader on your iOS 7 or later iPhone here. To port Reactive Trader to iOS, we used Xamarin’s toolset.

From a development perspective, we paired an experienced iOS developer, Jason Newman with an experienced .NET developer – myself! While Xamarin allows you to develop in C# and target iOS devices, leveraging your existing C# and .NET experience, it simply (and thankfully!) exposes the native iOS Cocoa Touch APIs directly. This means that you still need to know how iOS works, and how you are expected to build a fast, responsive application using the built in controls and libraries.

Pairing a .NET developer for their C# knowledge, and a iOS developer for their iOS knowledge was a fantastic way for us to accelerate the porting of the UI layer of Reactive Trader to iOS. Xamarin allowed us to completely re-use all of the lower level code – in WPF parlance, everything from directly beneath the viewmodels down to the SignalR API. This crucially includes the implementation of the Reactive Trader client/server protocol and API, meaning that we got two extra benefits: we did not need to re-develop any of that functionality for iOS, and that we could re-use the existing server in its entirety and without any modification.

This hugely accelerated developent, and was a very enjoyable way to kick off the project. Once Jason and I had spent a few days pairing and had settled on an architecture and the patterns for implementing the various parts of Reactive Trader, we split apart and worked independently. We encountered a number of different technical challenges – some related to Xamarin and some related to iOS libraries themselves. Either Jason or myself will hopefully go into these in a later post.

Reactive Trader Architecture

Early on we made the deliberate decision to not attempt to re-use any of the views or view-models from the desktop-oriented versions of Reactive Trader. There are a number of different technical solutions that existed when we began, and more have become available since then. These approaches are fundamentally based on wrapping up more and more functionality that can be found across different platforms into a ‘common’ set of APIs and components, and then using that common subset to build your application.

This approach seems to be worthwhile if you assume that your users expect to access the same functionality, in the same way, through a similarly styled application that lets them perform identical workflows and has the same use cases. Based on Adaptive’s work for our clients in the financial services industry, this assumption just isn’t true. There is no ‘one-size-fits-all’ set of user experience (UX) requirements that will benefit from the investment in using one of these development platforms, beyond the most trivial of applications.

While these may be the target for this set of technologies, it is important not to see them as the silver bullet for large, complex applications that expose functionality that can be accessed across a wide range of footprints – web, desktop, mobile. I see there being huge value in the code re-use of the common libraries, APIs and underlying client/server protocol that Xamarin brings, and being able to reduce the development effort required to target a different platform to ‘just’ the development of the specific UX required for that platform.

Additionally, settling on one of these ‘core subset’ technical approaches always leaves open the risk that a future requirement, driven by some new feature or functionality built in to just one of the various platforms being targeted will lead to compromises in application architecture in the short term, and an increase in the maintenance and testing costs in the future.

We see the best business case for Xamarin’s cross-platform approach to be to enable re-use of the backend server and APIs, as well as giving a huge amount of code re-use to reduce development and testeing, while the individual UX workflows for each platform are developed on a case by case basis.