Sunday, 22 November 2015

Welcome!

This is a semi-regular blog on the update to the ever-popular FARM APPS mobile application FTrack Live.

History

Version 1

The first version (by William Harrington) was essentially a table based application for iOS that allowed for the tracking of farm livestock. It used a proprietary SQL system and did a good job. It was basic, but ran. However, the upkeep of it was time consuming and the SQL system costly.

Version 2

The second version was more-or-less a complete re-write. The back end used Azure, the internal SQL system was based off SQLite, the UI was completely changed (thanks for feedback from users) and the codebase reworked to allow for Android and Windows Phone versions. The new version allowed for the tracking of crops, chemicals, fertilisers, rainfall, fuel, and pretty much every other aspect of farm life.

The graphics (by Ella) gave a new level of professionalism to the user interface and the reworked design meant everything worked in a far simpler to understand way. Farms could be better mapped and livestock tracked.

Launched in April 2015, this new version has met with acclaim and enjoyed by a large number of people.

Version 3

With the launch of Xamarin 4 and Xamarin.Forms 2, the newest iteration of the software has begun...

The process

The process of moving the app to forms is much simpler than you would expect with only a couple of major problem areas.

In no particular order, these are

Custom UI

Handling the calls to the Azure system

A platform independent method of messaging

UI alterations

Tabs

Custom UI

Version 2 of FTrack required some customisation of views and buttons to create lists that have an image on the left and either 1 or 2 lines of text next to is. The list was effectively a series of UIButtons in a UIScrollView with a theme attached. Each button was dynamically created. While a great idea in terms of look and feel, it is prone to dying and does mean considerable lag in terms of performance and memory handling.

For the new version, the look of this won't be changing too much, but it will be a genuine ListView with a theme attached. This means that I can use cell reuse (reducing the memory strain) and instead of having to process everything a number of times, can just bind the data to the view elements. The UI can still be themed as well which will mean the look and feel can be kept.

Given it is a genuine view, this will translate to WinPhone and Android without an issue.

Unlike iOS, Android and WinPhone will require some custom UI to ensure the look doesn't change between platforms.

Tabs

The current version relies heavily on tabs. There is nothing fundamentally wrong with tabs, but they are not handled the same between platforms. It is possible to create a pseudo tab bar, but again, it's messy. A contextual menu would be an obvious choice, but the UI was redesigned in version 2 to ensure contact with the phone was kept down (the biggest criticism of version 1 was that who in their right mind would want to put cow crap all over their iPhone?), so the fewer touches the better.

I'm not sure how I will handle these yet.

UI Alterations

One of the problems with V2 was that it didn't transition too well between phone and tablet. This was down to a design call early in development that had an unintended problem - tablets wouldn't be happy. Thankfully using a GridView will mean that I can just let the grid do the work and not me.

There will also be a few more UI alterations to make things look cleaner

Messaging

The current version uses a standard System.Event call to broadcast. While this works, it is not as efficient as the MessagingCenter code provided in Forms. That said, the MessagingCenter is not as flexible as an event. Could be a bit messy this if I don't do it right!

Azure

Most of the Azure code from version 2 can be used directly in version 3. However, some of the code is (like SQLite) platform specific and the way it interacts with the platform has not been fully tested (the app does some hideous manipulation of the Azure data in and out so there may be some issues). On the whole though, it should be fine.

Roadmap

The plan is to have this in beta by Christmas 2015 with a new year launch on all platforms. Internationalisation is handled by the Microsoft Multilingual toolkit so that shouldn't be a problem.

23-6 Dec - UI

6-13 Dec - Backend

14-21Dec - Tidy up, builds and debug

22-29Dec - Beta

30-3rdJan - Bug fix

4th Jan - Upload to the stores

Will I do it? Who knows. It's going to be fun. There are over 80 different views to bring across to forms with some code refactoring in the process. I'm not sure how much I'll end up doing in XAML or if I'll just do everything in pure C#