Google Maps API Keys on Android

For any Android devices with the Google APIs add-on installed, there is a very convenient way to integrate Google Maps with your application: the MapView. Using this view allows an app developer to create custom interfaces using other components rather than just launching the built-in Google Maps application via an intent. Needless to say, it is a very powerful feature that can be added with minimal effort.

To use this feature, however, one has to register for an application key from Google. Normally, this would be a reasonable request. In this day and age of mash-ups and public APIs, registering for keys is the status quo. What differs here is that the public-key fingerprint of certificate used to sign the application must be submitted in order to get the key. The key is generated using this fingerprint as a seed for the key generation and will only work when deployed in an app signed by that same certificate. At first glance, this too is perfectly reasonable. The annoyance comes when one realizes that a different certificate is used to sign your application for development/debugging than is used for production release (which is the default behavior for the Android Development Toolkit). If 2 different certificates are used, two different keys are needed and, since the key is embedded in the layout file that uses the MapView, one must have two different build configurations - one that uses the debug key and another that uses the release key in the layout file.

This leaves one with little recourse but to either use the production certificate during development/debug, manually change the key in the layout file before doing a build, or use a tool like ANT or Maven to swap in the right version of the file at build time based on a profile. I was planing on configuring Maven for this project using an open-source Maven ADK plug-in at some point anyway, looks like I have another reason to do so.

Android Optimization

Since the Android platform uses the Java programming language and, at a high level, seems to support a large portion of the language, it is easy to forget that one is still developing for an embedded device. I am, by no means, an expert -- in fact, this is my first foray into the world of embedded programming but there is no harm in outlining the little bit I've learned if it has a slight chance at helping someone else. This is the first platform on which I've really had to think of "micro" level optimizations (rather than macro, algorithmic optimization). It definitely adds another dimension to the analysis one must undertake when attempting to solve a problem.

To understand the best way in which to write Android programs, one first must understand a bit about the virtual machine at the heart of the system: The Dalvik VM. I won't go into details about the internals of the VM, but suffice it to say that the fact that it is made to run on devices with limited memory and CPUs, the compiler makes some choices in bytecode generation that differ from those that would be made by Sun's compiler.

In starting development on my Android project, I came across this page on the developer resources site. While the page listed a number of things that I would not have even thought of -- the way in which enhanced for loops, for example, result in the implicit allocation of an Iterator -- I was glad that the first bullet point was "Optimize Judiciously." This advice is probably the most important on the page. They even goes as far as including one of my favorite quotes on the subject:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
—Donald E. Knuth

The dangers of premature optimization are by no means limited to the realm of embedded programming (though they may be even more precarious since some of the optimizations done in this space may seem odd to developers accustomed to working in the desktop world) and I've seen them derail or over-complicate a number of projects in the past. Maintainability and understandability are just as important as correctness when writing software.

Pontificating aside, here is the process I am taking with respect to optimization:

1. Devise the most efficient algorithm for the logic I'm performing: this is no different than I would do on any other platform (just because you have more resources doesn't mean your software should use all of them).

2. Make the "easy" optimizations the first time around: this includes things like declaring variables using concrete classes rather than interfaces, only using the enhanced for loop when an iterator would be needed anyway, etc

3. Make the code as simple and clean as possible: again, this is no different than any other platform

4. Refactor often: this is probably the most important step. At this point, I've refactored so much of the application that I've basically rewritten it twice over. After each refactoring round, the code is cleaner, more efficient and more maintainable. I have paid special attention to the view portion of the code as small changes there can have a huge impact on performance.

There is nothing novel about the approach outlined above. My only point in calling it out is that the sequence is important. I don't start the refactoring phase until I'm sure that the algorithm is correct and the code implementing the logic is as simple as it can be. This helps keep things maintainable. I also endeavor to keep my layers and object dependencies clean. Performance "optimization" is not an license to throw away decades of solid software design principles. Keeping the components well-defined an clean may seem like you're leaving a few more CPU cycles of performance gain on the table but, in the long run, one is probably still better off with quality code that (so long as it performs well enough -- and what "enough" is varies depending on the application) versus spaghetti code that uses the fewest possible CPU cycles.

Android Development

I have recently started programming for the Android platform. This post is the first in what I plan to be a series discussing my experience writing code for this environment. That being said, I'll jump right into it.

We chose the Android platform for our application because it offered a lot of capabilities that we could take advantage of right out of the box (camera for video/image capture, GPS for location-awareness, Wi-Fi and Bluetooth for fast data transfer, etc). The free/open nature of the platform was also appealing. At this point, I've implemented the core use cases for all those features and am now concentrating on improving the user experience, bug fixes, and overall polishing. So far, I have no regrets as I have not yet come across a use case I could not implement in a fairly straightforward manner.

At the risk of sounding like a Google Fanboy, I have to say that I really do enjoy working on the Android platform. The core reason is that Google really put a lot of thought/effort into the SDK and development tools. For Eclipse users, there is an Android Development Tools plug-in that makes building and debugging applications as simple as a single click. Additionally, since Android has gone through a fairly rapid evolution and there is a wide variety of devices running a number of different versions of the OS, the emulator provided with the SDK makes it simple to test different device configurations running differing platform versions. While emulators are great for initial debugging, there is no substitute for running on an actual device. Since the platform is designed to be open, deploying one's applications to a real device is as simple as turning on an option in the phone's settings menu, plugging it into your PC and clicking a button in Eclipse. Again, none of these things are groundbreaking, but having full IDE support makes it much easier to concentrate on the details of the application rather than the nuances of packaging.

That last point applies to a lot more than just Android. Whether it is IDE plug-ins or a life-cycle management tool like Maven, comprehensive tooling makes getting up and running on a project easy. I cannot overstate how much of a difference Maven has made on other projects, especially those with complex builds and many dependencies. That being said, I am planning on trying to integrate Maven with my Android builds using this plug-in shortly (for reasons I'll outline in a subsequent post).

Proper System Properties

In sandboxed programming platforms like .Net and Java, the developer is insulated from the details of the underlying machine upon which the code is running. At times, however, it is often useful to have more knowledge about the environment. One way to provide such information without introducing any machine-dependent code into the sandbox is via system properties. They can be implemented in a number of ways, but the most common is a set of name/value pairs that can be accessed via a core class in the language runtime. In java, one can get a list of all the system properties using System.getProperties().

The properties are not limited to those set by the language virtual machine; they can be extended to include any property the developer wants to set. Most languages provide a way to do this at virtual machine initialization or programmatically within the application code. Having system properties is a powerful tool and can enable code to handle certain conditions based on the capabilities of the underlying machine in an elegant way. With power, though, comes responsibility.

Some developers have been abusing this construct and using it as if were a container for global variables: instead of passing parameters into methods, a method will simply look up a value from the system properties. This is especially egregious when the property is not universally true from the system perspective. One such example is specifying a HTTP proxy. In Java, the default HttpConneciton class uses system properties to specify a proxy. In most cases, this is fine, but in some enterprise environments, the proxy server one must use depends on the address being accessed. If your program needs to access two addresses that use different proxies, then changing proxies involves updating the values in the system properties. Again, this is usually not a big problem, but if you have a multi-threaded program, this could cause a race condition unless one enforces the atomicity of the property update with the HTTP request. Depending on the application requirements, this may or may not be an acceptable answer.

While there is not much one can do about the proxy issue (outside of using some other library to make HTTP requests), developers can prevent imposing similar limitations on their own code. Since it is impossible to anticipate every way in which code may be used and it is equally impossible to know every possible system configuration, the use of system properties that do not actually describe the system upon which the code is executing should be avoided.

Threads & Exceptions

In this age of multi-core processors, being able to write efficient and correct multi-threaded programs is becoming increasingly important. Unfortunately, however, writing such programs is not a trivial task. Deadlocks, race conditions, and thread starvation are among the myriad pitfalls that could break one's programs. Complicating matters further are “legacy” (for lack of a better term) third-party libraries that may or may not be thread-safe.Errors due to threading issues are among the worst class of bugs: the elusive Heisenbug. The use of a good profiler tool is essential in tracking down and eradicating bugs like this.

Just as important as knowing how to avoid writing code subject to deadlocks and race conditions is knowing how your programming environment responds to bugs that occur in child threads. In the Java programming language, for example, one's program could find itself in an unexpected state due to an uncaught exception in a child thread. When one is running a single-threaded program and an uncaught exception occurs the system will exit and print the exception's stack trace to standard error. Not graceful, but also not a very subtle error condition. When an uncaught exception occurs in a child thread, however, the flow of control is as follows:

1. The JVM checks the UncaughtExceptionHandler of the Thread object. This is null by default. If you wish to specify your own handler, you must call the setUncaughtExceptionHandler method on the thread instance (usually before starting its execution). Setting this handler only applies to the thread instance upon which you installed the handler (not descendant threads).
2. If the thread does not have an UncaughtExceptionHandler, then the ThreadGroup is checed to see if it has a handler of its own.


3. If the thread's ThreadGroup does not provide a handler, then the default handler is invoked. Unless the programmer changes it (by calling the static Thread.setDefaultUncaughtExceptionHandler method) the default handler simply prints the exception's stack trace to standard error.

The Java API documentation contains a very important warning for those programmers who want to provide their own default UncaughtExceptionHandler:

The default uncaught exception handler should not usually defer to the thread's ThreadGroup object, as that could cause infinite recursion.

When developing code that has any potential for reuse in other applications, one has a responsibility to take threading considerations into account. If it is decided that a method or class will not be thread-safe, then it is the developer's responsibility to clearly document this limitation in both the in-code documentation (i.e. JavaDoc) and any other API/Development guides.

Oracle RAC Load Balancing

Relational databases play a central role in many software systems. In many enterprises, Oracle is the RDBMS of choice. Among those, many mission-critical systems make use of Oracle's Real Application Cluster (RAC), a load-balanced multi-node database that can handle failures of individual nodes without causing an outage. This article provides a decent summary of RAC.

While RAC has many features and advantages (as well as trade-offs), that isn't why this post is here. It is here because the way in which the Java ODBC driver establishes a connection to the RAC is worth understanding in the event that one suspects a connectivity issue between the client code and the database server.

For a Java developer, using RAC is very similar to any other Oracle database. Usually, the only indication that you're using a RAC is the contents of your connect string. It typically lists a number of database server addresses in an ADDRESS_LIST element. For the purposes of illustrating the discussion, an example may be helpful:

jdbc:oracle:thin:@(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = dbserver1.somedomain.com)(PORT = 12345))(ADDRESS = (PROTOCOL = TCP)(HOST = dbserver2.somedomain.com)(PORT = 12345))(LOAD_BALANCE = yes)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = dbServiceName.somedomain.com) ) )

There are two types of load balancing offered by the RAC: client-based load balancing and server-based load balancing. The system can be configured to use one, both or neither forms of load balancing.

The LOAD_BALANCE element in the connect string above specifies that the client code should perform its own load balancing. Essentially, this means that the client will randomly choose one of the servers from the ADDRESS_LIST whenever a connection is requested.

If server-based load balancing is enabled, a listener service provides automatic load distribution across all nodes in the RAC. The listener will use the query optimizer to determine which node in the RAC should service the request (based on their current workload, machine profiles and, in newer versions of Oracle, admin-specified rules).

If one were to use the connect string above and server-based load balancing were enabled, the sequence of events that would occur when a call to DriverManager.getConnection(...) is invoked are:

• The driver selects dbserver2.somedomain.com (this choice was made at random by the driver) and issues a connection request.
  
• The listener on dbserver2.somedomain.com determines that the most under taxed node in the RAC is dbserver3.somedomain.com and returns it to the client. NOTE: this assumes that the RAC has 3 nodes. It is important to note that all the nodes do NOT need to be included in the connect string... the nodes in the ADDRESS_LIST simply indicate which nodes the client will balance its initial "getConnection" requests against
  
• The client will attempt to establish a connection to dbserver3.somedomain.com.
  

Sudo Voodoo

The Unix sudo command can be quite useful when one needs to give another user access to a select group of commands that need to be run as a certain user without having to give up the password for that user account. The easiest way to do this is to edit the sudoers file (usually in /etc/sudoers). The file allows an administrator to configure a list of commands that a user can execute as another user without a password. The policy file follows a fairly simple context-free grammer (defined quite concisely in the man page for sudoers). There are a few things to keep in mind when editing the sudoers file:

• You must edit the file using the visudo command as root
• When defining a command, you must use the fully qualified path to the command. The system will report a syntax error if you attempt to save the sudoers file with a command that does not start with a /character. This makes sense when one condiders that the whole point of the command is to run something as another user. That being the case, the system can make no guarantees as to what the working directory will be when running the command so requiring the absolute path is a reasonable constraint.
• The command(s) defined in the sudoers file must exactly match the command to be run.

Here is an example of a simple sudoers configuration:

Cmnd_Alias SOME_COMMANDS = /home/somedir/command1.sh,/home/somedir/command2.sh

user1 ALL=(ALL) NOPASSWD: SOME_COMMANDS

The first line sets up a "command alias" or a list of commands specified using their absolute path with each command separated by a comma. If you needed to pass a comma into a command as an argument, for example, it would need to be escaped using the backslash character.

The next line tells the system that the user user1 is allowed to run any of the commands listed in SOME_COMMANDS as any other user without having to specify a password.

Once you've installed these lines in the sudoers policy file, the user1 user can log in and execute sudo -u user2/home/somedir/command1.sh to run the command1.sh script as user2 without ever having to provide user2's credentials.

For a full treatment of how to configure sudo policies, the man pages are the best resource.