-
Handling portrait/landscape switch in Android
When you develop an Android application, you will notice that when the user changes the orientation of the device, the UI framework will recreate the current screen layout with the corresponding UI objects. The framework calls these methods of the current activity: onPause, onStop, onDestroy, and then onCreate, onStart, onResume to display the activity again.
The onCreate method of the activity retrieves the data it displays from a database and populates the input fields with the private populateFields method.
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
/* UI setup here */
Uri itemUri = getIntent().getData();
if (newRecord) {
customer = new Customer();
} else {
customer = retrieveCustomer(itemUri);
}
populateFields(customer);
}
When the user switches orientation, the Android framework will destroy this activity and call onCreate again, which will retrieve the data and populate the input fields. The result is that the user will lose entered data, because this input fields will contain what the activity retrieved from the database.
A solution is to store the entered data in the database in the onPause method:
protected void onResume() {
copyFromInput(customer);
if (newRecord) {
saveCustomer(customer);
} else {
updateCustomer(customer);
}
super.onResume();
}
This solution mostly works and also takes care of automatic saving the entered data when the user uses the "home" button. This may also surprise the user, since the data is saved without the user explicitly asking to save it.
A better solution is to use the savedInstanceState parameter that the Android framework passes into the onCreate method. This parameter is null when the user navigates to the activity. When the user changes orientation of the Android device, the framework destroys the activity after saving the contents of the input fields in a Bundle object. When the framework recreates the activity after an orientation change, the savedInstanceState parameter is not null and contains all the data that your application would want save during this change.
The Android framework already automatically saves and restores the contents of the input fields, so your application does not need to do this. The thing that your application needs to be aware of is that it should only set the contents of the input fields when the savedInstanceState parameter is null.
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
/* UI setup here */
Uri itemUri = getIntent().getData();
if (newRecord) {
customer = new Customer();
} else {
customer = retrieveCustomer(itemUri);
}
if (savedInstanceState == null) {
populateFields(fragment);
}
}
-
ID design
We often take the IDs that we use in databases and applications for granted. As long as we can identify a data record with a unique number, everything is great. Recently, I ran into an interesting problem in an existing application. The ID that was used has this format:
ABBBCCC
A = last digit of year
BBB = day number of the year
CCC = sequence number
For example, you could get on 2 february 2009 this ID: 9033012. This would be the twelveth data record of the day.
More digits
Sometimes, the application would generate more than 1000 data records on a day and run out of numbers. In that case the application just add digits to get something like this:
ABBBCCCDDD
A = last digit of year
BBB = day number of the year
CCCDDD = sequence number with additional digits
Example: 9003123456
Perhaps you can sense some trouble here...
Decade trouble
Obviously, you will run into problems after 10 years of using this application. It makes you wonder if the designers of this application have learned anything from the Y2K problems, is storage space really this precious that you cannot spare another 3 bytes?
Length confusion
The fact that the system adds another 3 digits is pretty confusing. Technically, the ID is still unique and valid. Normally we add digits in the front of the number, not in the back of the number. This makes it impossible to sort these IDs in a meaningful way.
For example, an ID created on january 1 (9001123456) could have a higher value than an ID created on january 2 (9002001).
Number interpretation
After the year 2010 started, the IDs suddenly started with a "0", like 0003123456 and in some subsystems, this ID is interpreted as a number, which would make it 3123456. Suddenly this ID can collide with an already existing ID from the year 2003.
ID should have no content
When the engineers were trying to solve this problem, they wanted to change the ID generator to just use an Oracle sequence and do away with the year/day nonsense. Because the system has grown rather large and complex over the year, changing the ID generation may cause more problems, because no one is sure that the contents of the ID is not interpreted in same way. It could be that a part of the system is making use of the fact that the ID contains the year and day number.
Conclusion
As you can see, designing an ID can be tricky. Lessons learned:
- if you use a year, please use the full year, do not try to save a little bit of storage, it might cost a lot of money later on
- avoid meaningful content in the ID to prevent "clever" people from exploiting this, otherwise you can never change the way an ID is generated
- allocate enough digits in the ID, the application may live much longer than you think
- keep it simple, use a sequence generator
-
Using a Syslog appender in log4j
The log4j framework has several appenders and one of them is the SyslogAppender. This appender lets you append log messages to syslog, a popular logging service on Unix and Linux. To use this appender, just add this to your log4j.xml configuration file:
<appender name="syslog" class="org.apache.log4j.net.SyslogAppender">
<param name="Facility" value="USER"/>
<param name="SyslogHost" value="localhost"/>
<param name="Threshold" value="WARN"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{MMM dd HH:mm:ss} MYAPP: %-5p %m%n"/>
</layout>
</appender>
You can use the usual log4j API to log messages:
public class AppWithStandardLogger {
private static final Logger logger = Logger.getLogger(AppWithStandardLogger.class);
public void someMethod() {
try {
// ...
} catch (ConnectionException e) {
logger.fatal("#Failed to connect to database", e);
}
}
}
Severity level mapping
If you use logger.fatal(), the standard log4j syslog appender will log this message with the highest syslog severity, which is level 0, "emerg". This level is usually reserved for the most urgent operating system related messages and on most Unix systems will print the message on the terminal session of every logged in user.
For most applications, this is probably not what you want. If an application encounters a fatal error, it should log the message as a lower level like "critical", level 2. You can do this by implementing an appender which overrides the "append" method:
import org.apache.log4j.Level;
import org.apache.log4j.spi.LoggingEvent;
/**
* Appender that fixes level mapping to syslog.
*/
public class SyslogAppender extends org.apache.log4j.net.SyslogAppender {
@Override
public void append(LoggingEvent event) {
Level log4jLevel = event.getLevel();
Level newLevel = null;
if (log4jLevel.equals(Level.FATAL)) {
newLevel = SyslogLevel.FATAL;
} else {
newLevel = event.getLevel();
}
LoggingEvent newLoggingEvent = new LoggingEvent(
event.getFQNOfLoggerClass(), event.getLogger(), event.getTimeStamp(), newLevel,
event.getMessage(), event.getThreadName(), event.getThrowableInformation(),
event.getNDC(), event.getLocationInformation(), event.getProperties());
super.append(newLoggingEvent);
}
/**
* Fix for level mapping - log4j "fatal" is mapped to syslog "critical".
*/
public static class SyslogLevel extends Level {
private static final long serialVersionUID = 1L;
public static final Level FATAL = new SyslogLevel(FATAL_INT, "FATAL", 2);
protected SyslogLevel(int level, String levelStr, int syslogEquivalent) {
super(level, levelStr, syslogEquivalent);
}
}
}
This custom appender will map the log4j "fatal" messages to syslog "critical" (level 2) severity.
Stack traces
With log4j you can also log the stack trace when you pass the exception as extra parameter. In my work the syslog system will pass the messages through to Tivoli and this monitoring system should not receive stack traces.
With a custom log4j PatternLayout, we can filter out stack traces by overriding the ignoresThrowable() method:
import org.apache.log4j.PatternLayout;
/**
* Layout that prevents stack traces to be logged.
*/
public class NoStackTracePatternLayout extends PatternLayout {
@Override
public boolean ignoresThrowable() {
return false;
}
}
Putting it together
To use both the custom Appender and Layout, use this configuration:
<appender name="syslog" class="net.kazed.log4j.SyslogAppender">
<param name="Facility" value="USER"/>
<param name="SyslogHost" value="localhost"/>
<param name="Threshold" value="WARN"/>
<layout class="net.kazed.log4j.NoStackTracePatternLayout">
<param name="ConversionPattern" value="%d{MMM dd HH:mm:ss} MYAPP: %-5p %m%n"/>
</layout>
</appender>
The code is unchanged, we only changed the configuration.
Using a named syslog logger
If you want to have control over what and how the application logs to the log file and syslog, you could configure a separate logger with a name:
<logger name="monitoring">
<level value="WARN" />
<appender-ref ref="syslog" />
</logger>
In the code, you refer to the "monitoring" logger and you can log a different message to the monitoring system:
public class AppWithNamedLogger {
private static final Logger logger = Logger.getLogger(AppWithNamedLogger.class);
private static final Logger monitorLogger = Logger.getLogger("monitoring");
public void someMethod() {
try {
throw new ConnectionException();
// ...
} catch (ConnectionException e) {
logger.fatal("Failed to connect to database", e);
monitorLogger.error("Failure to connect to database");
}
}
}
As you can see, we must change the code and add a second logger and use this to log explicitly to the monitoring system.
Conclusion
When logging to a monitoring system you can avoid changes to the source code by changing the configuration and add the monitoring logger. The standard syslog appender implementation maps the log4j fatal to syslog emerg, which level is too high for most Unix/Linux installations. A custom appender can fix this mapping. To avoid logging stack traces, you can implement custom Layout.
With a named logger you can log special messages explicitly to the monitoring system. This requires changing the code.
-
Use Enumeration instead of Constant
Using Enumeration instead of Constant
I think we all regularly use integer or String status codes or other magic numbers in our Java code. And we probably also define (static final) constants to make these constants known to the users of our code. While this works fine for small projects, I noticed, when working on larger scale project, that I spent a considerable amount of time trying to find which constants I needed.
In many applications I encounter, this kind of API for a service is quite common:
public static final String DOCUMENT_TYPE_TEXT = "text";
public static final String DOCUMENT_TYPE_SPREADSHEET = "spreadsheet";
List findDocuments(String documentType);
In the above API, it is pretty obvious that I should use the listed constants as the documentType parameter. However, I have seen many cases where the constants are defined in some other place and sometimes an archeology expedition was needed to find the correct values to use. I also have the freedom to pass any String that I didn't get from a constant and just hardcoded. Because of this freedom, the service must check if the passed in documentType parameter is valid (who knows what
the user passes to the service).
To make the API more watertight, we could require the user to supply a constant of a class that we define ourselves:
List findDocuments(DocumentType documentType);
This is the DocumentType class:
public class DocumentType {
public static final DocumentType TEXT = new DocumentType("text");
public static final DocumentType SPREADSHEET = new DocumentType("spreadsheet");
private String name;
private DocumentType(String name) {
this.name= name;
}
public String getName() {
return name;
}
}
Apache common lang EnumIn the example above we still need to implement the equals() and hashCode() methods to make it possible to check which documentType the user passed to the service. The easy way is to subclass from the Apache common lang Enum class, this superclass implements the boring stuff (equals, hashCode, compareTo, getName): import org.apache.commons.lang.enums.Enum;
public class DocumentType extends Enum {
public static final DocumentType TEXT = new DocumentType("text");
public static final DocumentType SPREADSHEET = new DocumentType("spreadsheet");
private DocumentType(String name) {
super(name);
}
}
This solution works well if you're stuck with Java 1.4. However, if you work on a project that runs on Java 5 or later, you should consider the build-in enum types.
Migrate to Java 5 enumThe Java language designers have added the enum type in Java 5 to make it easier to define a type-safe constant. The DocumentType enumeration becomes very simple:
public enum DocumentType {
TEXT,
SPREADSHEET;
}
The code of our service runs unchanged, since the equals method of an enum behaves the same way. In the case you need to interface with legacy code that gets a string from a database or property file to create the corresponding constant, you can add a String as private member of the enum:
public enum DocumentType {
TEXT("text"),
SPREADSHEET("spreadsheet");
private final String name;
DocumentType(String name) {
this.name = name;
}
public String getName() {
return name;
}
}
ConclusionUsing strong types instead of Strings or integers has these advantages:
- the interface of your objects is much clearer and less ambiguous,
- you get code completion in your IDE (no need to "hunt for constants"),
- easier refactoring by your IDE,
- type safety - your client cannot supply invalid String or integer constants.
-
Spring bean configuration validation
If you enthousiastically use Spring like me and dutifully inject every dependency in your beans with Spring's XML configuration, you have probably encountered the situation that you forgot to inject a property and received a NullPointerException from an unexpected place in your code. Wouldn't it be nice to check the configuration of your bean after it is instantiated?
Your bean could implement the InitializingBean interface, which would cause the Spring application context to call the afterPropertiesSet method after your bean is instantiated and injected with dependencies. This would make your bean directly dependent on Spring and you probably would not want that.
Attribute "init-method"
A better solution is to call a method of your bean that validates its own configuration with the "init-method" attribute of the bean element in the application context XML:
<bean id="bean1" class="net.kazed.spring.config.validator.ExampleBean1" init-method="validateConfiguration">
<property name="bean2" ref="bean2"/>
<property name="bean3" ref="bean3"/>
</bean>
public void validateConfiguration() {
DependencyAssert.notNull(bean2, "bean2");
DependencyAssert.notNull(bean3, "bean3");
}
The Spring container will call the "validateConfiguration" method after your bean, in which you can check if all required dependencies are injected. The only thing is that you should not forget to add the "init-method" attribute.
BeanPostProcessor
Since our goal was to catch configuration mistakes, this solution just is not good enough. Fortunately, you can create a post-processor for the Spring container that will examine every created bean after instantiation and dependency injection. By implementing a BeanPostProcessor, you can invoke the validateConfiguration method. To make it nice and intuitive, we can create an interface ValidatableConfiguration with the validateConfiguration method.
Interface:
public interface ValidatableConfiguration {
/**
* Validate the configuration of the object.
*/
void validateConfiguration();
}
ValidatingBeanProcessor:
public class ValidatingBeanProcessor implements BeanPostProcessor {
public Object postProcessBeforeInitialization(Object bean, String beanName)
throws BeansException {
return bean;
}
public Object postProcessAfterInitialization(Object bean, String beanName)
throws BeansException {
if (bean instanceof ValidatableConfiguration) {
try {
((ValidatableConfiguration) bean).validateConfiguration();
} catch (DependencyNullException e) {
throw new ConfigurationValidationException("Configuration of bean '" + beanName
+ "' failed - " + e.getMessage(), e);
}
}
return bean;
}
}
We just declare the ValidatingBeanProcessor once in the application context, and the container will use it for every created bean:
<bean id="beanValidator" class="net.kazed.spring.config.validator.ValidatingBeanProcessor">
The nice thing is that we only have to make the bean implement the ValidatableConfiguration interface and it will automatically be used to validate the bean whenever you declare it in the application context.
Advantages:
- Intuitive design - implement interface and it will be validated
- No special configuration (except from the one ValidatingBeanProcessor)
- Validation is done only once and during instantiation of the application context - it will fail early
- Error message is descriptive - no more puzzling NullPointerException
Constructor injection
Traditionally, the Spring team favored setter injection because of more readable configuration. Spring has always also supported constructor injection and recently this has received more attention in the Spring community (see Alef's blog). Constructor injection makes validation incredibly simple: just validate in the constructor.
public ExampleBean1(ExampleBean2 bean2, ExampleBean3 bean3) {
super();
DependencyAssert.notNull(bean2, "bean2");
DependencyAssert.notNull(bean3, "bean3");
this.bean2 = bean2;
this.bean3 = bean3;
}
<bean id="bean1c" class="net.kazed.spring.config.validator.ExampleBean1">
<constructor-arg ref="bean2"/>
<constructor-arg ref="bean3"/>
</bean>
As you can see, constructor injection is a bit harder to read because the arguments are nameless and depend on the order.
Conclusion
I would prefer to use constructor injection and use (or combine with) setter injection if some dependencies are optional. The BeanPostProcessor is very useful because it is non-obtrusive and automatically validates the configuration of a bean when it implements an interface that you define yourself and can be a logical part of your domain model.
Retrieve here the source code of these examples.
|
