Stretching the native Droid APIs for IBM i
As I dive deeper into creating Android applications, I’m finding that most applications to date are geared toward home users versus business users—games, utilities, music players and entertainment. That has led me to think of how the IBM i community could approach this limited-real-estate device with applications that have business purposes. I have many ideas in the queue, and one of them is to find a way to easily deploy applications to the Droid.
The traditional approach of developing client-side applications, whether Droid or desktop, is to create hard-coded screen definitions occupied with data by making requests to the server, maybe using SQL, and then the client determines where to put the received data. This is many times necessary on the Droid for applications that have a lot of graphics or specialty UI components. But what if the UI components needed by an application consist only of text fields, buttons, labels, dropdowns, lists of data, etc.? If we can determine a pattern of needed UI components, we can start developing more generic client code and start moving more processing, like controller logic and screen definition, back to the server.
This article introduces my latest small-scale open-source project called DynaDroid4i. DynaDroid4i is a small, generic program that runs on the Droid device and has a fairly simple premise. It aims to accomplish three tasks:
- Communicate with IBM i to receive the next screen definition
- Dynamically render the screen definition to the client device using the native UI components
- Act on UI component events (i.e., button press) and send that event and corresponding screen field data back to the server for processing
Really, in the end, the goal is to have little hard-coded functionality on the device and instead have the server side tell the client what to do. This means we can have a very generic code base on the device that doesn't need to be redeployed each time there’s an application change. Instead you’d only need to redeploy when you wanted to add new types of UI features (i.e., add GoogleMaps as a UI feature or provide the capability to turn on the collection of GPS coordinates remotely).