Touch != Click

I started programming for Android a few months ago, starting a few apps while playing around with the API, re-familiarising myself with Java and getting a feel for mobile development. Having spent the majority of my programming time during the last couple of years using WinForms, ASP.NET and other Microsoft technologies, I've really enjoyed breaking out and trying something new.

When moving from using a mouse and keyboard for all input to using your finger and a soft-keyboard for the first time, there are a few things that you need to learn until you can take full advantage of the OS.

No more hover

There is no hover for touchscreens, unless of course these become the norm. You can simulate hover in a mobile browser by long pressing but of course it isn't the same.

Less control

Unfortunately, your fat fingers are not as accurate as that small cursor. Your buttons will generally have to be a bit larger when developing for touch. The Android design guidelines recommend making your buttons at least 48dp (density-independent pixel) which translates to approximately 9mm, in order to offset any inaccuracy. I find that I very rarely miss touching a button if it is 48dp or larger.

You must also be mindful of the touch areas of your widgets. This is where memorising the difference between padding and margin is useful, padding with make the widget larger whereas margin will just put space around the widget.

Design Pattern: Introduction and lazy loading

Design patterns in software engineering are generic solutions to some commonly occurring problems encountered when creating software. When I was at university, I was "taught" design patterns but they went in one ear and flew out the other as they gave very little context for when they are actually useful. Trying to teach design patterns without looking at any code or having good examples for when they are effective is futile.

After leaving university however, I started noticing some common code patterns without knowing what they were. It was at that time that I started to appreciate their usefulness. In industry it is common to dumped in a large enterprise application where you're expected to learn how to navigate your way through the code very quickly. This is one of the cases where they are useful; communicating your intentions with other developers. Being able to look at a piece of code and say "oh, that's the x design pattern" is just another way to speed up the process of familiarising yourself with some code.

The other case where they are useful is when designing a solution to a common problem and identifying that a certain design pattern can be used. That takes out a lot of the work of designing a solution as a pretty solid solution is already defined. Plus the act of learning design patterns is a great exercise for improving as a programming.

I'm going to be starting a series of posts today on design patterns. Each will go through a design pattern in detail, giving a UML diagram where applicable, at least one code example and real-world examples of where it is useful. The first will be on the lazy-loading pattern, a very useful and commonly used pattern.

Google Drive is not yet enabled for your Google Apps domain

I woke up this morning, started playing with my phone only to see that Google Drive has been released! I've been waiting for quite some time, having abandoned SugarSync a few weeks ago as I stopped using it a while ago due to what I felt was not the greatest integration with all my devices.

 

Not so fast! It is not enabled for my domain yet. So I went and investigated how to turn it on. Everything looked find with Docs and Drive settings. The problem was in my Google Apps domain settings, I was not on the Rapid Release track and I did not have new services set to automatic.

According to the official Google Drive transition notes, it looks like I may not be able to get to use Drive for another 5 weeks. So... Set your Google Apps domain to the rapid release track!

SASS: Syntactically Awesome Stylesheets

SASS stands for Syntactically Awesome Stylesheets, yes, I'm quite a fan of the name. It provides us with a much simpler and more elegant way of defining CSS, allowing the creation of more modular and manageable stylesheets. SASS has two flavours; SASS-style and SCSS-style, the basic difference being that SASS-style uses indentation to separate code-blocks instead of curly braces. The examples used in this post will be using the SCSS-style.

Several years ago, I was playing around with CSS thinking how great it would be if CSS was able to define variables. The help it would be just having the ability to define the colours of a site so you don't have random hex values peppered throughout your stylesheet would be huge. This problem is what instantly drew me to SASS.