Tuesday, 24 November 2015

An important aspect in any application is the ability to use different languages within an app and FTrack is no different.

The current iOS and Android versions have platform specific language files which doesn't transfer over well to Xamarin Forms. Thankfully, it's easy enough to internationalise a forms application and make use of how Windows Phone does things (with the multilingual toolkit).

The issue though comes with there being around 2300 different strings and there isn't a chance that I will copy and paste each over to the resx file. The solution was simple.

The resx XML looks like this

<data name="foo" xml:space="preserve"> <value>some text</value></data>Rather than have to re-write anything, a small piece of code reads the old Apple en.lproj file, parses the code and spews out the XML which you then add directly after the last <resheader> and before the closing </root> (removing anything else between it).A couple of gotchas though - you can't have / or . in the name property. This is a pain as many text lookups are of the form uipage.textproperty. The code to do the conversion is thisusing System;using System.IO;using System.Collections.Generic;namespace MessageConverter{ /* <data name="Done" xml:space="preserve"> <value>Done</value> </data> */ class MainClass { public static void Main(string[] args) { var dataList = new List<string>(); var fileLines = File.ReadAllLines("Localizable.strings"); foreach (var f in fileLines) { var lines = f.Split('='); if (lines.Length > 1) { dataList.Add(string.Format("<data name=\"{0}\" xml:space=\"preserve\">", lines[0].Replace("\"", ""))); dataList.Add(string.Format("<value>{0}<\\value>", lines[1].Replace("\"", "").Replace(";", "").Replace(".","_").Replace("/", "_"); dataList.Add(string.Format("</data>")); } } File.WriteAllLines("newtext.resx", dataList); } }}

Okay, there is no error trapping in there and the file has to be in the same directory as the binary, but hey, it works and means I don't have to convert everything by hand!

Using the new strings in the app

Thankfully, when I wrote FTrack2 I did it in such a way that I use a string lookup and then add the string into the UI directly viz

myUILabel.Text = Strings.GetString("myText");

A quick search and replace and Strings.GetString becomes LangResources.myText

Okay, there is a bit more to it than that, but still covers much of the grunt work

Operation Declutter

By far the biggest job is the moving over of the UI. There isn't an automated way to generate XAML from a XIB file, so much of the UI has to be written by hand. The way iOS works is to create a designer file as well as the standard C# file associated with the xib. This includes a lot of stuff in there which is very specific to iOS - all of which has to be removed. There is no easy way to do this other than go through each source file and remove it.

There is a big advantage in this - I can go through the code base and rip out the common methods to create some nice clean generic ones which should help with the performance. Let's see what it yields!

Sunday, 22 November 2015

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#