It has been over 2 years since Canonical announced Ubuntu Touch. In my opinion, the success of Ubuntu Touch depends to a large extent on its developer story. After all when you use your phone, it is important that it allows you to get work done which in turn requires applications and scopes. So let's evaluate that developer experience today and see how it fares.
The developer story is sort of a like a jigsaw puzzle where many different pieces come together to create something meaningful. The key pieces in this puzzle include the Ubuntu UI Toolkit, Qtcreator IDE, Ubuntu Developer Portal, Ubuntu Touch Store and Platform Services. Hopeful this review will raise attention to how far we have come and the current drawbacks or holes in this story.
I will split this review into a couple of parts to help me review each piece of the puzzle in more detail without making this too long. Also it helps with my short attention span.
Ubuntu UI Toolkit
The toolkit reached its first beta in August 2013. It was the beginning of something new, exciting and powerful. With a standard toolkit offering, users get a consistent experience across their apps and devices. The SDK has come a long way both in terms of the maturity of the components that it offers and the ability to customize them. I remember just a few months back where changing something as simple as the font color of a Standard list item was just not possible.
The Ubuntu SDK components were rigid, forcing app developers to by-pass it with their own components.
On one hand this rigidity promoted a uniformity amongst ubuntu apps at the cost of customization and developers being unable to brand their apps to their liking and requirement. As a result, developers usually find a way around it by either creating their own components or using undocumented APIs which can break at any point. I have already noticed a few apps like Pockit which break in Vivid due to using APIs that were not stable and undocumented.
Taking a peek behind the curtains, Ubuntu Components 1.3 does come with a brand new app theming tutorial and sub-theming capabilities that will allow app developers to customize various parts of their apps to their liking. This should alleviate the rigidity issue, but the fact that this will land only in 15.10 which is a good 6 months away seems a bit too long to wait for.
Ubuntu Components 1.2 currently shipped in vivid (which the phone will transition to in a few weeks) comes with a nifty set of improvements like new list items that are way more customizable and feature filled (reordering, multi-selection mode, better performance). A natural evolution to the list items that we have come to love and hate in the past release of the SDK. This is exciting and I can't wait to get around to using them.
However the one thing that stomped on these bells and whistles of Ubuntu Components 1.2 was unfortunately the absence of a ubuntu-sdk-15.04 development framework during the Ubuntu 15.04 development cycle. Why is that so important? Well it is always to the benefit of everyone that app developers and SDK developers work together and help test new SDK features before they become final.
During the 14.10 development cycle, this was possible by using the ubuntu-sdk-14.10-dev1, -dev2 framework. This allows app developers to test the new features of the toolkit and provide timely feedback. That however has been completely missing in the 15.04 cycle which concerns me of the issues that new app developers might face when they get their hands on the new features that landed in the 15.04 cycle.
The whole framework concept has sadly not been handled to the expectations that one would expect after working with them for more than a year.
To make matters worse, once the toolkit for a certain ubuntu release like vivid becomes final, it is a horrendous nightmare to get bug fixes backported to it. Here's a classic example of a bug that was never fixed in the current ubuntu phones based on utopic (RTM).
Bug 1341814: Using search in the header can sometimes have a text field from a different tab
The above bug literally makes the new header features like head.contents impossible to use in a app that has a somewhat complicated navigation structure and affected apps like the Music App, Flashback, Podbird etc. The temporary fix these apps had to use was to add some workaround code in every page that used the head.contents feature. Granted these app developers were aware of the bug and knew how to temporarily patch it, what about new developers?
If you look at the merge proposal, it was fixed in the toolkit (vivid) in January 2015. Between Jan 2015 and April 2015, we have had 3 OTAs been pushed to phone users. If such a high priority get glanced over, how can one hope that other bug fixes would be backported to current production phones? Considering that we have been dealing with frameworks for over a year, I would expect this to become smoother over time, but sadly it has been the exact opposite.
And most importantly guys, please support other ubuntu projects like U1db better! In my testing, I have noticed that the SortFilterModel which can be used to sort and filter rows in a list model doesn't work with Ubuntu's own U1db model. Personally I am disappointed that U1db is in maintenance mode with no new features nor bug fixes being committed to trunk.
Don't get me wrong, the SDK devs are doing a great job. They have a lot in their plate and when looking at the size of their team, what they have achieved over the past couple of months is nothing short of being impressive. But it still raises questions as to if that is enough? I mean that are still tons of bugs in the SDK and the conversation there always starts with, "well if you use this workaround then you can get around it..." that just won't cut it new developers.
There is Ubuntu Online Summit (UOS) coming up on the May 5th-7th where we can bring this up to the SDK team. We all have the same goal which is to provide this awesome developer experience. Let's help make that happen.