Android Number Picker

For my first open source release of code, I bring you an Android Compound Control. This particular custom control is a number picker with a repeat feature. This is a very basic control, but not one that is provided in the given pre-built control set. For those of you looking to easily fill that void, or perhaps learn how the auto-increment feature was implemented, I give you NumberPicker.

NumberPicker is an extension of LinearyLayout, and as such can be configured horizontally or vertically, shown above. The size of the elements is hard coded at this time, but by looking in the documentation it can be seen that it is very easily changed. Here is an example of using a vertically configured version of this element in an XML layout:


There are two particular elements of this control I’d like to talk about. Firstly, is implementing the repeat feature. My first instinct when developing this was to spawn a thread to periodically change the value as long as a user held one of the buttons. I quickly learned that this wasn’t possible by simply spawning a Thread, as only the GUI thread can make changes to the GUI. Further reading in the Android manual led me to the use of Handler to schedule the changes.

Whenever a button is long pressed, a flag is set, and a new Runnable, RepetetiveUpdater, is posted to the Handler. This new RepetetiveUpdater will check if a flag is set, and increment or decrement the value appropriately, and then post a new RepetetiveUpdater to the Handler with a delay of 50 ms. Once the user releases the button, an OnTouchListener checks if the the last touch action was the release of the active button and disables the flag originally set when the long click first occurred.

The second thing I’d like to point out is how the parsing occurs for the EditText value from String to Integer. Much to my surprised, one utilizing a hardware keyboard can force non-numeric characters into an EditText that is configured to be numeric.

There are two issues with this; we don’t want to crash trying to parse something that’s not an Integer, and we don’t want to have our number go up and away if a new line gets through. To mitigate these issues, whenever a key is pressed, an OnKeyListener will save the current valid value that was in place before the user pressed a key, attempt to parse the new text as is, and if it fails, restore the edit text to the last valid value. In this way, whenever a invalid key is pressed, the user doesn’t even notice.

I hope that there will be some utility to some one by me releasing NumberPicker under the BSD license. If you have any questions feel free to voice them in the Comments.

UPDATE: I’ve created a sample Eclipse project that may help you work out implementation details: NumberPickerExample

Path Determination for Unidirectional Graph Searching

Graph search algorithms are classic coding and thinking exercises for computer science students. Two particular algorithms most students will experience are Breadth First Search (BFS) and Depth First Search (DFS). The pervasiveness of these algorithms in education will often lead to them being used as a gauge of a programmers knowledge and analytical abilities.

Once a programmer finishes their schooling, it’s important for them to constantly be updating their skill base to stay relevant in an ever changing industry. In addition to staying up to date as new technologies emerge, it’s also important to stay sharp on their existing skills. When a pancake told me that a graph should be implement as bidirectional to determine the path once a target is found using a graph search algorithm, I couldn’t confidently argue that it could be done using a unidirectional graph. I thought this would be a great opportunity for me to brush on on my BFS and DFS by actually implementing them.

Before continuing, Wikipedia has great articles for those unfamiliar with BFS, DFS, or general graph theory.

I won’t go into detail on my particular implementation of the actual search algorithms, which were done in Java. The main focus of this exercise was to show that you could retrieve the complete path using BFS or DFS on a unidirectional graph.

Both search algorithms have to protect against traversing cycles. Doing so prevents the algorithm from literally running in circles. To protect against cycles the algorithms keep a list of nodes they’ve already visited. This list can also be used to compute the path for unidirectional graphs once the target is found.

Here is my implementation. The list of nodes passed into the function has the start node at the beginning, followed by every node checked before the target was found, and lastly the target. I’ll let the code and comments speak for the functionality.

Hopefully this can be as educational for readers as it has for me. Due to the pervasive nature of this problem as a test, I won’t be publishing any source beyond what is shown, and even then I’m keeping it as an image so it can’t be easily copy/pasted. My apologies for anyone looking to copy my code for honest purposes.

Diff’in Oracle via SQL

I was working on querying different data rows contained in two tables in an Oracle databse. null value comparisons tend to bite me in the ass now and again and today was one of those days.

Let’s say we have two tables, A and B, they both have a mandatory ID, and a column x, which allows for null values. I originally had the following query:

select *
from A, B
A.ID = B.ID and
A.x != B.x

What I really needed:

select *
from A, B
A.ID = B.ID and
( A.x != B.x or
( A.x is null and B.x is not null ) or
( A.x is not null and B.x is null ) )

I’m not entirely satisfied with this. It seems like there should be a better way, but I haven’t discovered a more desirable one yet. If you add more columns into the mix it gets even more complex.

First post from my phone!