Connecting Android to IBM i
This is the fourth and final installment in my series on getting started with Android and IBM i. “Create an Android Development Environment” showed you how to install the Android Software Development Kit (SDK) and emulator. “Building Your Android Development Environment” introduced the Android application framework through a simple business-style version of Hello World. “Taking Advantage of Android OS” showed how to use styles to simplify your UI definitions and also introduced the QuickContactBadge, one of the built-in widgets that Android helpfully provides to application developers. We took advantage of it to create a simple application that accessed the contacts capabilities of the phone, and could actually make a call or send an email. However, the actual data was hardcoded into the application; this last article will fix that little flaw.
Where We Left Off
Take a look at Figure 1 to refresh your memory of where we left off. I split the main.xml file apart, moving most of the formatting information such as size, positioning and color into a separate file called styles.xml. Once that was done, it required only a relatively few lines of codes in both the UI definition and the business logic to add a widget called a QuickContactBadge. This new widget provided an easy-to-use programmatic interface to the phone’s contact system; with just a little effort I was able to call up the user’s contact information for a specific sales rep and then let the phone (and the user) do the rest. The right-hand image in Figure 1 is the native Android contact application, not something I had to write. Let the phone do what the phone is best at!
If you remember, we addressed this issue the last time. Clearly the list ought to be variable in length. In fact, it’d be nice if it wasn’t limited to the real estate of the phone, and was instead somehow scrollable. Also, I’m not happy with the lack of visual feedback; I’d like the line that I click to be highlighted. The good news is that those capabilities are available within the Android UI design framework. Let’s get to work.
The changes really aren’t that extensive, and you can see the results in Figure 2. The original main.xml had four hardcoded rows in the table, one for the headings and three nearly identical ones to represent the detail. I removed the three detail rows from main.xml and instead created a small tablerow.xml file with only one TableRow widget in it. We’ll see how that affects the Java code in a moment, but clearly it further reduces the amount of code in the UI definition. In fact, even though there are fewer total lines I was even able to add some called a ScrollView; this widget will provide scrolling to our application. You may also notice one other thing: I removed nearly all of the android:id attributes. These are names that can be used to access individual widgets within the UI. In my opinion, unless you actually access the widget programmatically, it doesn’t need an ID. And so, I’ve only associated IDs with those widgets that will be directly accessed by the Java code.
Splitting the UI into multiple files has one potentially negative side effect that I haven’t figured out how to avoid. If you take a look at Figure 3, you’ll see the WYSIWYG display for the new main.xml. As you can see, it still has headings but it no longer displays any data. That’s because we pulled out the detail rows and created a separate UI “snippet” in the tablerow.xml file. At this time, there’s no way to tell the WYSIWYG designer that it should “include” another XML file in its display. Instead, you’re going to have to design the UI snippets individually and then take responsibility to make sure your snippets will work together properly. The benefits, though, far outweigh the drawbacks, as we’ll see.
Let’s review the new code. I’m going to do this in two steps, starting with the initialization code that builds the UI. This code is shown in Figure 4 and except for the first line, which gets the array of orders, it’s all new code. First, I get a reference to the table layout using findViewById. Java programmers will note that I save that in a class variable (named tl) so that I only have to get it once; subsequent code doesn’t have to execute the find statement again. Next, I create an instance of an Android object called a LayoutInflater. While the name is a little odd, my guess is that the developers mean that the object inflates the XML in a UI layout document into the actual UI widgets that appear on the device. I then spin through the array of orders, building a table row for each one. I set each column of the row from one of the columns of the array (this code is actually very similar to the original code). Finally, I add the newly inflated and populated row to the table layout. Very snazzy! And after adding a few more lines to my getOrders() function (just to create more data lines), when I run the new application, I get the screen shown in Figure 5.
You can barely see the scroll bar on the right, but it will let you scroll through the remaining orders. And I’d now be able to click on one of them and the contact badge would work as it did in the old program. However, I wanted to make one last change to the UI before we headed off to the server side. When I have a selectable list, I like to have some visual feedback to tell me which line I’ve selected and I usually do that by changing the background color of the line as a way of highlighting it. It’s quite easy to do that in the Android UI.
All I’ve done is create a little loop to run through all of the rows in the table and clear the background (by setting the color to 0). After that’s done, I set the color of the background to light blue. Figure 7 shows the result when I click a row.
comments powered by