Wednesday, April 15, 2009

Constant Interfaces

A constant interface is one that contains no methods, only static final fields, each declaring a constant. Below is an example:
public interface UniversalConstants {
//Speed of light in m/s
static final int SPEED_OF_LIGHT = 299792458;

//Newtonian constant of gravitation in m^3 * kg^-1 * s^-2
static final double GRAVITATION = 6.6742867e-11;
}

There were times in the past that I've used such interfaces in classes that needed the constants. This is a poor use of interfaces. An interface serves as a type that tells you what a class that implements that interface can do with an instance of it. There is nothing of this kind when using constant interfaces. How can we avoid this? (At least) In two ways. One, define the constants inside your class, if you feel that there is a strong relationship between those constants and you class. The other way is to use a utility class that cannot be instantiated, like below:
public final class UniversalConstants {
//Speed of light in m/s
public static final int SPEED_OF_LIGHT = 299792458;

//Newtonian constant of gravitation in m^3 * kg^-1 * s^-2
public static final double GRAVITATION = 6.6742867e-11;
}

When using these constants from within your own class, you can add a static import declaration and you're done!

Android 1.5 (Cupcake) Highlights

Android 1.5 introduces new and exciting features. Here are some that I find important:
  • Accelerometer-based application rotations
  • Faster Camera start-up and image capture
  • Much faster acquisition of GPS location (powered by SUPL AGPS)
  • Smoother page scrolling in Browser
  • Video recording and playback
  • Bluetooth: stereo bluetooth support (A2DP and AVCRP profiles), auto-pairing, improved handsfree experience
  • Browser: copy 'n paste in browser, search within a page
  • Framework for easier background/UI thread interaction
  • Raw audio recording and playback APIs
  • Support for using speech recognition libraries via Intent
  • LocationManager - Applications can get location change updates via Intent
  • Broadcast Intent for app update install succeeded - for smoother app upgrade experience
For a complete list of features, visit the android developers web page.

Sunday, March 22, 2009

Breaking information hiding in Java

Information hiding is one key feature of Java in particular, and OO in general. It is not to be confused with encapsulation, since you can bundle data with your methods and not hide it at all. Even though these two (information hiding and encapsulation) are different, they are usually used together by making the attributes of your class private data members and providing getter (accessor) and setter (mutator) methods to them. Having said that, let us look at an example:

public class InformationHiding {
   private Position position;

   public InformationHiding(double latitude, double longitude)
      throws IllegalArgumentException {
      //make sure you have proper values for latitude and longitude
      if (latitude >= -90 && latitude <=90 && longitude >= -180 && longitude <= 180) {
         throw new IllegalArgumentException();
      }
      position = new Position(latitude, longitude);
   }

   public Position getPosition() {
      return position;
   }
}

Can you spot the problem with this code (beside the lack of synchronization)? Let's see how we can break the check for proper values of latitude and longitude:

InformationHiding inf = new InformationHiding(45, 120);
Position pos = inf.getPosition();
pos.latitude = -100; //illegal value
pos.longitude = 240; //illegal value

How can that be? We did make the position data member private? The problem is that we returned a reference to that member. This is a common mistake. Even when you generate the getter method from inside our IDE (i.e. Eclipse), it returns a reference to the attribute, rather than a copy to it. How can we fix this? Easy, just return a copy of the data member:

public Position getPosition() {
   return new Position(position.latitude, position.longitude);
}

That's it! You could have used the clone method to make a copy of the object, but then some changes need to be made, like not implementing clone by using the constructor.

There are some cases when we do not need to return a copy of the data, namely when we deal with immutable objects (like Strings and the wrapper classes).

Thursday, March 19, 2009

Android 1.1 and iPhone 3.0

If you want a feature-by-feature comparison of Android and iPhone, read the Android Versus iPhone 3.0 article by lifehacker. Do remember that Android is only in its 1.1 release, while iPhone has seen its 3.0 version. Even though iPhone has more available features, let us not forget that Android is open source.

Sunday, March 15, 2009

Smartphone sales numbers

According to a Gartner report, smartphones sales grow by almost 14% compared to 2007. What is encouraging are the news regarding Android-based smartphones:

"Sales of Linux-based smartphones were up by 19 per cent year-over-year, mainly through Android-based smartphones being available through T-Mobile during the fourth quarter of 2008."

I expect this number to grow with upcoming Android-based smartphone models.

Thursday, February 12, 2009

Top 25 Most Dangerous Programming Errors

SANS Institute came out with a top 25 most dangerous programming errors, errors which can lead to serious security breaches.

"... experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale."

Tuesday, February 10, 2009

Android Presentation

Today I did a presentation to a group of students on Android, basically an overview of the platform. If you are interested, you can find the presentation here. Any comments are welcomed!