From Android to PCThe customer came to us with a big poster, which included a project of an application prototype. Obviously, they were intended for a mobile version – more specifically, for the Windows Phone. When we started discussing the project, the customer quickly saw that the market at which he targeted his application (the printing market) very often uses traditional PCs; thus, it would be a great idea to prepare an application version for the Desktops. As we had already dealt with the start-ups, the MVP (Minimum Viable Product) version was supposed to be delivered, which, according to the assumptions, should be a working, stable version which included the most important functionalities, which would enable us to persuade the potential investors as well as future users to invest into the project.
Since our company is specialised in Xamarin technology with the MVVM framework Cross, having the perspective to create a project both for desktops and mobiles, we decided that the desktop version would be implemented based on the WPF (Windows Presentation Foundation) technology, and the logical part, the so-called core would be the common part. This means that we write one code, which we can use on both mobile systems (Android, IOS, WindowsPhone), as well as on desktop systems.
SYNCHRONIZACJA DANYCHThe next challenge was synchronising data in the whole application – the devices were to have the ability to synchronise from all around the world; additionally, all operations made by other users from the same company were to be available in real-time for everyone. We used the cloud solution. There, we put the previously-implemented API (Application Programming Interface) which is responsible for the whole logic of the system together with connecting it to a database and other services and providers integrated in the application.
Due to the size of the application and the complexity of the processes taking place in it, we decided to use proven solutions – the API created in the ASP.NET technology, WebAPI, with which we have a lot of experience, and a relational database based on MS SQL. The whole solution lacked one, very vital component – asynchronous call sends from the server for a dedicated group of users, which were supposed to notify them about a change of data when other users performed some operations. Here, the well-known SignalR helped us, which allowed us to update user data based on the data fetched from the servers only when it was really necessary. The advantage of this solution was the client library for SignalR which was also used for all platforms – the whole implementation was in the Core, thanks to which we had to handle events and to react to them on the platform side.
EXTERNAL SERVICESApart from the standard technical solutions, the application had to use external services as well. These services enabled purchasing subscription to a product, sending text messages and mails and registering all operations for the given account. For subscribing to a product, we chose the Recurly system, which enables users to control their accounts from the desktop application with ease and clarity. This solution was also chosen due to the business model on which the application is based – the clients pay for new users in the company and/or for every sent text message. Since we knew what the scale of the product would be in the future, we decided to transfer the text messages service to proven services – our first choice was Twilio, which suited our expectations. We can also create sub-accounts for every new customer, which heavily influences the control of expenses when we send a great deal of text messages. We used another proven system – SendGrid – for sending massive numbers of emails. The system was also configured to use the domains specified by the customer – it means that the incoming mails are redirected to the clients domain (erpos.com), which also positively influences the perception of the technical aspect of the whole project.
A vital problem with cloud-based applications is… connection with the Internet. In this case as well there were some problems with network stability and frequent signal interruption. We wanted to deliver to the user an application which would be able to deal with these obstacles. Thus, we had to implement a few background mechanisms, which analyse the connection stability with the server, and if any problems occur, they try to automatically connect and synchronise data without the user’s intervention. An additional challenge was handling the hibernation mode and any issues with freezing of the application or a device, resetting it together with up-to-date data – we also solved it by using appropriate system events and background mechanisms enabling smooth use of the application.
From MVP to 1.0 However, the greatest challenge in the whole application was building an MVP version… which transformed in the development process to a full 1.0 version – we did not clearly delineate the limits of functionality and changes of concepts during the implementation contributed to the fact that the first scope did not end with a demo version of an application, but a whole system, which has its own implementations at our customer’s.