Tags: android

You may have seen this in several blogs: you can buy an unlocked Android development phone at the Google Android market place.

If you are like me, in a country where the T-mobile G1 is not for sale yet, and would like to test your Android application on a real device, you can now have one. The development phone can be shipped to: the United States, Germany, Japan, India, France, United Kingdom, Taiwan, Spain, Australia, Poland, Switzerland, Austria, Hungary, Netherlands, Sweden, Finland, Singapore and Canada.

Keep in mind that the price of $399 does not include shipping and custom duties. These shipping/customs/import charges are:

I just ordered mine and should arrive here in the Netherlands in 5 to 10 days. Finally I can test my NextAction Android application.

---

Add this page to your favorite Social Bookmarking websites

Tags: framework | java | jsf

Recently, I am working on a portal project at a bank and the framework that is used is Struts (version 1.x). Having used JSF for a few years now, I find Struts delightfully straightforward use and difficult to maintain. I got this portlet project dropped on my plate and find it difficult to find out where the data used by the JSPs comes from.

A typical Struts JSP gets the data from the request or session, which is just like a Map that can contains any arbitrary Java object (the session is supposed to hold only Serializable objects, although many programmers do not always follow this rule). This makes the request and session behave like a bag of global variables that get their contents set somewhere in some Action. You can track down request scoped attributes, since they can only be set by the immediate action, and since session scope attributes live as long as the session, almost any action that could have added it to the session. Also, these Action objects contain only one execute method, which promotes a procedural style of programming. Maybe this is why I sometimes see so many static methods in the project.

---

Add this page to your favorite Social Bookmarking websites

Tags: java | persistence | spring

Automatically generated ID's are very handy, since you don't have to create the ID yourself and don't need a second roundtrip to the database as you would when you use a sequence

Example

CREATE TABLE AUTHOR (
  ID BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY,
  NAME VARCHAR(100) NOT NULL,
  PRIMARY KEY(ID));

CREATE TABLE BOOK (
  ID BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY,
  TITLE VARCHAR(100) NOT NULL,
  AUTHOR_ID BIGINT NOT NULL,
  PRIMARY KEY(ID));

When you insert a new book into the database, it will generate the ID automatically. However, when you need to insert multiple records with foreign key relations, like a author and a book record, where the author_id is the generated id of the author record, you need to determine the generated id.

---

Add this page to your favorite Social Bookmarking websites

Normally I do not bother testing setters and getters, they are usually too boring to expect any bugs lurking in there. I recently started working on a project that requires a test coverage of at least 75%, and I realized that to reach this percentage with classes that have relatively many setters/getters and only a little bit of other code, I wanted to test the setters and getters.

Also, these setters and getters may contains trivial but nasty bugs that should be tested. It has happened (some years ago) that I incorrectly implemented a setter this way:

public void setName(String name) {
    name = name;
}

I know, it's a pretty stupid mistake and still quite easy to make.

I created an automatic testing helper that will go through all methods of a class and if it detects a setter, invokes it with an appropriate test value and checks it by invoking the corresponding getter (if it exists). The return value of the getter should be the same as the value passed to the setter.

---

Add this page to your favorite Social Bookmarking websites