My issue list for Ubuntu Touch 14.10-devel r179 on Nexus 5

This is my issue list from using Ubuntu Touch as my primary mobile operating system for a few days.  While this seems like a large list, don't let it scare you away.  This list shouldn't tell you that Ubuntu Touch will be a failure.  There are a few things to keep in mind.  First, Ubuntu Touch isn't even in Beta yet.  Second, most of these issues are polish-type problems.  It doesn't stop the user from doing something, and it doesn't happen very frequently, but it is noticeable.  Polishing is something you tend to do when you get the major issues out of the way.  Finally, I am using an unsupported device.  The only phone that is officially supported at this point is the Nexus 4.  These are all issues I experienced on a Nexus 5.

On to the list:

When I first installed Ubuntu Touch, after the wizard, the system wasn't usable until I rebooted.  The landing team knows about this issue.

Sometimes, when I boot, the lock screen never comes up. After a few minutes, I tried hitting the power button thinking the system locked up on boot, and the lock screen came up. It turns out the system booted, but the screen had gone blank due to an idle timeout before the lock screen was available. This only happened twice to me.

When hitting the power button to turn off the screen, the backlight stays on. This drains the battery very fast. I have noticed that it will eventually turn off. This is the one of the two problems that I consider a true blocker for me, since the phone dies way too fast.  Other users have noticed this on the Nexus 5 and Nexus 7, but I haven't seen a forum post about it happening on the Nexus 4.

In Settings->Storage, in the list of apps, each app is listed twice.

When upgrading apps, the "Transfers" area in the notification bar shows an entry for each app, but the entry only shows a red X to cancel the transfer. It doesn't tell you anything about it, like the app or the download status.

Sometimes, the action bar of the app slides up by 50% of the height of the action bar. This means the top 1/2 of the action bar is cut off, hidden under the notification bar. Sometimes the app fixes itself, but I mostly open up task manager, swipe to kill, then relaunch.  I have seen a bug report of this in Launchpad already.

Sometimes, clicking on an app in the home screen that is already open causes weird things to happen. It does work from time to time. I have seen it just hang there for a few seconds, though. When it hangs there, I usually cannot switch to that app anymore. I have to kill it and restart it. I have seen it kill the app and restart it as well. It will sometimes just do nothing. I get frustrating thinking the app won't launch until I realize that it is already open and I just need to switch to it.

In System Settings, the "Updates available" section doesn't go away after you perform all the updates until you relaunch the System Settings app.

Clicking on System Settings->About this phone->Developer mode crashes the System Settings app. I have no idea what is supposed to be in there, but I was curious.

Open up Messenger, Click in the "Write a message..." text box to bring up the keyboard, hit the power button turn off the screen, hit the power button to bring up the lock screen, swipe to unlock. The bottom row of the app (that has the text box and send button) are still in the higher position (as if the software keyboard was still there), but the software keyboard isn't actually showing. Clicking on the text box does not bring up the keyboard because the text box already has focus. You can get back to normal just by scrolling in the app.

Bluetooth does not work. This is a blocker for me, since I use the Bluetooth on my phone to play music while I drive.  This is a known issue.  I don't know which devices have Bluetooth working.

Sometimes, launching an app will leave you at the home screen, frozen and unusable, for a long time before actually starting the app

The Facebook app is mostly just a webview. My news feed doesn't seem to auto-update. I have to open the menu and click on News Feed, but that doesn't always refresh my news feed.  This isn't technically an Ubuntu Touch issue.

When rotating the phone, sometimes the phone detects the first rotation really fast, but takes some jiggling to detect the rotation back.

I sometimes have problems connecting to my work WiFi network.  That network is a little....special.  Other devices have issues, but Ubuntu on my Nexus 5 has more issues than Android on my Nexus 5.  The main problem is the WiFi network requires you to enter in your ActiveDirectory credentials on a page before you can do anything.  On Android, the notification bar will usually pop up with something that you can click that takes you to the login page.  Ubuntu doesn't do anything to let you know that you need to go to the webpage.  As a backup, the WiFi router is supposed to send an HTTP redirect to the login page if you try and access any webpage.  This is the part that is the real issue.  Ubuntu doesn't seem to want to handle or understand the redirect.  If I can't authenticate, then I can't access the internet.  I have to drop back to 4G and try again later.  I found the easiest way around the issue was to authenticate to the WiFi in Android, then boot into Ubuntu.

The Importance of Backups

I have a decent amount of data.  All my data is stored in a ZFS RAID-Z array.  RAID is not a replacement for backup, however.  I had a data corruption issue that luckily didn't have an effect on me, since I had an appropriate backup.

First, some background.  One of the hard disks in my ZFS array is in an external chassis.  I didn't realize this chassis was plugged into the wrong outlet on my UPS.  It was plugged into the "Surge Only" outlet.  I had a power flicker and my ZFS went down to a degraded state.  Normally, I would have gone down there to take care of the problem immediately, but children change your response time.

When it rains, it pours, however.  When I restarted the enclosure (after plugging it into the right port), ZFS ran a scan.  The scan discovered 5 files that had bitrot.  Luckily, I had a backup of all 5 files, and I was able to restore them.

Here are some tips on effective backups:

1) Categorize your data by importance.  My really importance files (tax/legal documents and family pictures/video) are stored in the cloud (my personal Owncloud instance).  I keep the important files offsite in the event that my house is completely destroyed.  For less important files, I store on an external USB3 hard disk.  This disk is not normally connected to my server.  I have to plug it in to perform a backup or restore.  I don't want a lightning bolt to destroy my data and my backup, but I am less concerned with losing this data if my entire house is destroyed.

2) I highly recommend ZFS.  Although it is not impervious to bitrot, but is far better than other solutions.  It also identifies which files have been impacted.  "zpool status -v" gives you a list of files that have issues.  It is much easier to restore 5 files and to restore everything.

3) Schedule a ZFS scrub.  A scrub will go through your data and verify that all the data matches the CRCs.  While ZFS can let you know something bad happened, it is good to pre-emptively verify your data.  I perform a scrub once a week.  I know the data corruption issue I had occurred within a one week window.

I installed Ubuntu Touch on my Nexus 5

I have been waiting very anxiously for the ability to install Ubuntu Touch on my phone.  I have been every excited about this phone operating system.  I was looking at some forums and I noticed that someone said they had Ubuntu Touch running reasonably well on their Nexus 5.  I previously was only looking for support on a Galaxy S4 (a backup phone) since there are a few apps that are a must for me.  I did a quick search to see how far Ubuntu Touch has come on the Nexus 5 and noticed this forum post talking about Multirom support for Ubuntu Touch.  Multirom is a tool that allows you to dual-boot various different Android roms.  The tool has been greatly expanded to support dual-booting alternative operating systems, like Ubuntu Touch.

I rooted my phone (I didn't have a need previously to this) then followed the instructions.  It took about an hour to install Ubuntu Touch.  I installed 14.10 devel, build r179.

I was surprised how usable the system was.  There are a few major issues and a lot of minor issues.  I wouldn't consider it usable for most people.  It is almost usable for me, though.  I imported my Gmail contacts and calendar.  I text regularly with my wife.  I use the Gmail and Facebook webview apps.  The Pandora app works.  The unofficial Dropbox app doesn't work very well.  I can list my content, but downloading is a little weird.  I tried the camera and gallery apps.  I have launched the terminal a few times.  There wasn't a need to launch the terminal, I just launched it to see if it would work.

Wifi and 4G work, but Bluetooth does not.  The built in browser works ok.  I tried the Youtube app, but that is just a webview.  I installed a Google Maps app but I haven't actually tried turn-by-turn directions.  It did use the GPS to correctly identify my location.  The file manager app is ok.  I haven't tried a music player yet, but I'm assuming it will work fine since Pandora worked.  The weather app works ok.  The basic weather information is native, but if you click on anything to get more detail, you get the www.weather.com mobile website.

I haven't figured out how to copy files between the Android and Ubuntu sections of the SD Card.  My Qi charger still charges the phone.  The swipe gestures from the top, right and left edge work perfectly fine.  The swipe gesture from the left edge doesn't always work when I have my phone cover on.  If I take the cover off, then it works fine.  I am compiling an issues list that I will post in a few days.

Overall, I am very impressed with how far the Ubuntu Touch development team has come.  I am excited at the progress and the prospect of using it as my primary phone operating system.

My First QML App - KidsDraw

I wrote my first QML application.  It is a simple app that allows you to draw with a touchscreen.  There are multiple colors to select from.  The draw surface supports multi-touch so you can use two fingers to draw two lines at once.  It was designed for my son to use.  He doesn't like it when I use my laptop without him.  He really likes my laptop since he can touch the screen and things happen.  The only problem so far is he uses more than two fingers.  In Ubuntu, the system recognizes 3-finger and 4-finger gestures, so my son can easily get out of the program by mashing his hand on the screen....which he does regularly.

The app is very bare bones.  It does not contain any automated test cases.  It assumes more of a laptop or tablet display, since it puts a row of color buttons that probably won't fit on a phone.

You can take a look at the source code here.

Blindly Following Documentation

I have been working on a project that has multiple development teams working together.  One of the teams has a habbit of blindly following documentation without understanding what is actually going on.  This caused us problems before.  This project was to build a proof of concent Google Glass app for my company.  On this project, we needed to store some data that would be globally available to every activity.  I had learned my lesson already and chose to store the data insize of a custom Application class.  Every activity that needed the data was able to access it without the fear of the data being nulled out during a GC cycle.  The other team tore me apart.

They said I should use a static class with a public static variable that would store the data.  They citced the official Google documentation for the Application class.  In the documentation, you will see a paragraph that says to do the exact opposite of what I implemented.

There is normally no need to subclass Application. In most situation, static singletons can provide the same functionality in a more modular way. If your singleton needs a global context (for example to register broadcast receivers), the function to retrieve it can be given a Context which internally uses Context.getApplicationContext() when first constructing the singleton.

I tried to explain the GC issue with static classes, but they didn't really care too much.  They complained about needing a reference to the Context to be able to access that information.  I explained that everything should already have access to the Context.  That is when things got ugly.  I was accused a promoting the worst possible style of Android development.  Apparently, I was advocating a Worst Practice.  Passing the Context around is evil.  Android developers should do as much as possible to prevent having access to the Context (some blog post was quoted where people were keeping static references to Activities, keeping the entire view in memory).  In their mind, when documentation says "In most situation(s)", that means NEVER.

Through more discussions, it turns out the other team didn't really understand the GC issue.  After fully explaining it, the lead on that team suggested that we should store the data in SharedPreferences instead.  Now, every time an activity starts up, we read from the internal SD card on the UI thread.  That is way better!  On top of that, SharedPreferences requires access to a Context, so we are still passing the (evil) Context in.

Pros and Cons of Removing Boilerplate and Using Frameworks

My team has started to look into the use of Java Annotations to help get rid of some of the boilerplate that can be involved with Android development.  We created annotations for injecting view references in Activities and Fragments.  We created annotations for handling the registration of broadcast listeners.  We created annotations for getting and maintainer references to certain classes, like to the host Activity from the Fragment.  The pilot code that uses the annotations looks a lot cleaner (less casting, fewer lines of code).  It looks easier (for me) to maintain.  It had fewer bugs.  Are those good reasons for removing boilerplate, though?

Saying the code has fewer bugs seems like a slam dunk.  Lets analyse the bugs that occur, though.  All the bugs that are prevented by using the annotations are related to the lifecycles of Activities and Fragments.  Our developers were grabbing onto references to other objects incorrectly.  Sometimes, they grab them in the wrong method (onCreateView vs onActivityCreated).  Sometimes they don't handle saving the state to the bundle correctly.  These are the type of mistakes that junior developers make more often than senior developers.  Using annotations to hide these details prevents junior developers from learning the details of Android lifecycles.  It holds them back, making it harder for them to become senior level.  It also makes it harder to on-board mid-level developers.  Mid-level developers will be used to seeing the boilerplate.  It will take time for them to get used to the annotations.

One of the other developers on my team pointed out that debugging issues could be harder.  The annotations make assumptions about the code it is in.  If you inject a view with the id of R.id.button1, the assumption is a layout was already inflated that has a view with id R.id.button1.  What happens if that assumption is wrong?  Currently, you get a NullPointerException the first time you try use the reference to the view.  A mid-level developer might spend hours diving into the framework, accusing it if being crap.  They will curse the seniors to writing it, saying what they are doing is fine.  The problem won't go away until a senior developer points out that they inflated their layout incorrectly, or they were in landscape mode and forgot to add R.id.button1 to the landscape layout.  They might make this mistake because they aren't getting exposed to the type of mistakes that forces them to learn more about how Android works.

The annotations remind me a lot of the other frameworks that I have either used or written.   They accomplish two things very well.  First, junior developers can write code with fewer bugs.  The frameworks do this by hiding the advanced details of what they are doing.  This reduces bugs at the cost of never allowing them to advance as developers.  The second thing these frameworks do is allow senior developers to write code faster.  They can write code faster without sacrificing code quality.