Thursday, December 29, 2011

Anonymous Classes

(Or more things I should have learned in college)

One of the things that always tripped me up when I was working on open-source projects in High School was seeing what looked to me to be very strange formatting of code. It would be a jumble of parentheses and curly-braces, and it wouldn't make sense to me. Worse yet, I couldn't find a pattern to try to associate this formatting with. So I just skipped it and modified what I knew.

In College, I took a programming language course where we explored the more "exotic" languages. We got to lisp and lambda functions and once I learned about those, I had all the knowledge needed to understand the weird syntax.

It wasn't until I got into android programming that I saw funny looking code again.and then it all made sense. Here's an example:

searchBtn.setOnClickListener(new OnClickListener() {

public void onClick(View v) {


This threw me for a loop -- method calls are usually in the form of
          object.method(arg1, arg2, ...);
Why was there a new in there?
What's with all the curly braces?
Why wasn't the method call finished before all this new junk was put in?

Well, While I was pondering these things, it all just sort of clicked. It was an Anonymous Class.

What are Anonymous Classes?
Anonymous classes are classes that have no explicit name. As a result they are only used once.

Why Would you use one?
Because you're lazy er...because there are cases where you only need a class only to satisfy a parameter of a function. These are most useful for callbacks. Doing GUI programming, or interfacing with some type of input device, you'll see them often.

How to interpret/use one
Well lets start off with the example above. Lets look at it's method signature:
void setOnClickListener(View.OnClickListener l) ;
That's pretty straightforward, it's a function that takes one argument of type OnClickListener.
Lets look at the OnClickListener class. It's an interface. That means that you can't call a instance of that class, it can only be implemented in a class which defines all it's abstract methods. In this case, setOnClickListerner needs an instance of a OnClickListener class so that it knows what to do when clicked. Here's what you can't do:
      OnClickListener bob = new OnClickListener();
That won't compile because it has an  abstract method, onClick(View v), which needs to be defined. So we can write a class that implements the OnClickListener
class anOnClickListernerForTheStartButtonOnTheMainActivity implements View.OnClickListener {
    onClick(View v)
//In another file
anOnClickListernerForTheStartButtonOnTheMainActivity bob = new anOnClickListernerForTheStartButtonOnTheMainActivity();
But that gets cumbersome, so we do as the first example above does and use anonymous classes.

Hopefully this helps someone else understand the beauty of Anonymous Classes

Tuesday, December 27, 2011

GUIs? How Do They Work?

So I've been around a computer for most of my life and I've seen some pretty bad designs (cue guy here), but one thing that has interest me is GUI design. I've spent 4 years in college and only had about 1 class where a GUI was required. Granted, computer science isn't about GUI programming but still, I was ill prepared to start designing programs that other people would be using.
When I started to program for android, I was a little taken aback by the XML approach to GUI programming that I had to use and searched for something that would give me a more Visual C++ type feel that I was use to in college. I found some (java warning) but I couldn't get it to do exactly what I wanted so I dug into the XML and got it under control -- but what to do with it? How should I design my app to be most usable? These are the questions I have to answer to make my app successful.

Looking back there have been some interesting Human Interface Guidelines (HIG) that have been used to try to steer people in the right direction in terms of how the look and feel of an application should be. One that comes to mind is one from the GNOME HIG. It suggested that Buttons shouldn't be labeled "OK" and "Cancel" but instead use verbs to clarify what the user is about to do.
Some people see this as putting a bounding box on their creativity and prefer to create their own way of doing things or making an app "skinnable" which I think is horrible. It breaks consistency with everything else and a lot of the time it leaves the default butt-ugly with the excuse "If they don't like it, they can change it".


I don't wanna take time to find and change a skin just because you wanted to make your app extendable. Pick intelligent defaults is all I'm saying.

Another thing you have to think about these days is making an interface that is usable on many different devices. between androidx86, Chinese tablets, and car makers, you can never be sure where your app will be deployed and how it will look. Luckily the android sdk makes the experience a bit more predictable by allowing multiple versions of resources to be uploaded and letting the device choose which one to display.  Also, you specify text fonts and layout sizes in em instead of cm or px. You can still use those units but they don't scale in to different size devices. There are a lot more guidelines on how to design your app on android and they can be found Here.

Looking at it all, it can be a bit overwhelming to try to get it all right at first, that's why I'm focusing on functionally first then I can devote all my time into usability

Monday, December 26, 2011


It's tough to stay motivated enough to see the product through to market. I look at my phone full of half completed apps, and it makes me sad.
I guess one of the reasons I don't continue is because it's such a pain to develop on my my computer. It has low ram so Eclipse crashes all the time, also I always have to futz with adb to get it to see my phone, don't even think about running the emulator -- that makes my computer go OOM everytime.

I will be getting a new computer soon and maybe then I'll be able to develop more -- I even have some more ideas of what to make. You'll hear more about those later.