Mindful selection of constant values (for uniqueness)

(I ran into this issue when trying to grok the Android Bluetooth API, and thought it was worthy of a post.)

Say you have a value and need to know the name of the constant. For example, you are debugging some code, and things would be much more obvious if you could log the name of a state returned by a method getState(), not just its value:

1 2 3 4 5 6 7 8

// Possible device states public static final int STATE_IDLE = 0x00; public static final int STATE_STARTING = 0x01; public static final int STATE_RUNNING = 0x02; ... public int getState() { return mState; }

You could solve this with a lookup table. But if there are many constants, or the documentation is in the code, or new constants may be added later, or there are undocumented manufacturer additions, you can save a lot of code by using reflection to look up the names of the constants at runtime.

With reflection, you would obtain all the constants in the class, look for the constant whose value matches the one you got from getState(), and display the constant's name instead of its value.

But say that this code is also in the same class:

1 2 3 4 5 6 7

// Possible power settings public static final int POWER_OFF = 0x00; public static final int POWER_ON = 0x01; ... public int getPower() { return mPower; }

While it may make sense to represent power settings with a 0 and 1, the reuse of these values breaks our ability to uniquely discover a constant's name using reflection, because one value now maps to two constants.

One approach to ensure uniqueness is to use a higher order byte to encode the information that the constant represents. In this example, hex 0x0a00 is added to STATE_ constants, and 0x0b00 is added to POWER_ constants:

1 2 3 4 5 6

public final static int STATE_IDLE = 0x0a00; public final static int STATE_STARTING = 0x0a01; public final static int STATE_RUNNING = 0x0a02; public final static int DEVICE_OFF = 0x0b00; public final static int DEVICE_ON = 0x0b01;

Developers may not encounter the need for reflection in normal coding. But it can come in very handy during testing, or when you encounter a complex system like Bluetooth, and are trying to figure it out. There are going to be times where different constants must have the same value. But many times, values can be unique. Mindful consideration of constant values to permit discovery of their corresponding constant names through reflection may be appreciated by others who will eventually be interacting with your code.

Learning how Bluetooth works on Android, by using it

I picked up a really great LG Bluetooth headset at RadioShack during our local store's closeout. But I quickly found what a pain it was to switch between the headset and my car stereo and my home stereo. I decided to write an Android home screen widget to make this super easy (it's still in progress) but in doing that I had to learn how Bluetooth works.

My app requires me to keep on top of the status of each A2DP (media) and headset (phone call handling) device. Do I query the Bluetooth system for status on all of my devices from time to time? Or can I get notified reliably when a device's Bluetooth status changes?

It turns out that Bluetooth can give you updates when things change. And how is via Broadcast Intents.

I decided to write a small app that would receive Broadcast Intents and write them to logcat. This was easy: I created a BroadcastReceiver and advertised my desire to receive a number of Bluetooth-related Broadcast Intents in the app manifest. Then I could exercise the phone - turn Bluetooth on and off, scan for devices, pair, unpair, etc - and see what Bluetooth tells me.

There was one little problem. While the Bluetooth API documentation shows you the names of constants that are sent in the intents as extras, the intents actually contain just the values. So you have to dig through the API documentation or the source to figure out which constant name each value belongs to.

To address this I wrote the app to look up the values and return them. For some of the values I created a lookup table, but for others I used reflection. Reflection, actually, is quite useful, because it returns the names for *any* constant values - even undocumented ones - as long as they exist in the class on the device. It turns out that manufacturers add additional information to the intent, and this is one way you'll discover it. For example, I discovered that Samsung added EXTRA_GEARMANAGER_GEAR to the BluetoothDevice ACTION_FOUND intent that is sent when a device is found during discovery.

So, here's what you attach a Galaxy S4 to your development machine, run $ adb logcat -s BluetoothIntentLogger, go to the phone, run the app, go into the Bluetooth settings, scan for devices, while an LG Viper is advertising its presence:

There are five broadcast intents received. Two from BluetoothAdapter at the start and end signal the beginning and ending of the discovery process. In the middle, the LG Viper is discovered, and we learn a bit about it:

• It's a PHONE, and a SMART_PHONE to boot (we can use that info for choosing an icon!)
• It's an LG Viper (in my other app, I'll let the use store a different name.)
• It's (apparently) not Samsung Gear.
• It's pretty close by - it has a signal strength of -48 dBm.
• It doesn't support Bluetooth Low Energy.

In verbose mode, the app will show you the constant values and data types as well.

In playing with this app, I've found that when you turn on Bluetooth, you get a list of all devices that are currently paired to the device. That's perfect for populating my app for the first time. And the receipt of Broadcast Intents when things change will provide a timely trigger for the update of my widget.

Another thing I learned is that since Android 3.1, Broadcast Intents must be associated with a running process unless the sender designates otherwise (see the section on Launch Controls, in the 3.1 API notes.)

I considered displaying the log data in an Activity or send it to a pastebin, but that seems unnecessary, so logcat will remain the output mechanism for now.

Get BluetoothIntentLogger on Github

Samsung night vision camera's PAL/NTSC and normal/reverse video settings

Warning and disclaimer statement: Opening or modifying a device such as this will void its warranty and can create failure modes that lead to property damage, injury or death. We disclaim any warranties regarding the accuracy or reliability of this information, and will not accept liability for any injuries or damages that may result from the reader's use of this content. 

The placement of one resistor at time of manufacture puts this Samsung SDC-7340BCN into normal video mode, instead of a mirror mode such as that output by a backup camera. As opposed to conventional cameras, backup cameras output a mirror image so that what you see in the image is on the same side as it is on the vehicle. Many vehicle monitors accept composite video, which this camera outputs.

This night vision camera, found on deep discount at RadioShack, produces a clear image in low light.

Based on the resolution and packaging of the image sensor, it seems this particular camera uses a PixelPlus PC1099K image sensor. For a composite video camera, this sensor has a lot of pixels and produces a comparatively sharp image. Searching for "PC1099K" returns hits for many different cameras, which likely are similarly configured. The PC1099K is apparently designed to be used not only as a normal camera but also as a backup camera, and has features that allow the placement of guide lines over the video image.

The horizontal and vertical mirror modes are determined by applying a pull-up or pull-down resistor to certain pins on the image sensor. In this camera, the designers placed pads side by side, so that the placement of a resistor on one side would pull down the pin, and placement on the other would pull it up. This lets the manufacturer select the mirror and PAL/NTSC modes at manufacture simply through the placement and omission of resistors.

During manufacture, one pad is populated and the other is left open.