Big Trak 2022
Command-N-Control Application - Remote contol app for Big Trak
As a remote controller we chose to use android along with a custom built application.
I started
testing with a generic bluetooth IOT app available on the marketplace and then expanded from there
to custom application development. It has been several years since I last played with android, so I
took this opportunity to switch from their older eclipse + SWT plugin stack to the new android studio.
With this effort I used android studio bumblebee (2021.1.1 patch 1).
Amazingly enough it was not that complicated to come up with a pretty reasonable app. The more complex component of the build was dealing with bluetooth , which provided 3 interesting challanges.
- Bluetooth infrastructure access.
I found out that there are multiple steps to utilizing dangerious APIs. And this has changed recently to accomodate the modern security policy of granting the least required access. Previously an app simply had to declare the access it required. Now the developer must implement a callback structure where by they notify the user access is required. Then the application flow continues only if access is granted. The new steps are well documented - but oddly such a feature is not really baked into the privledge structure -or- the APIs. It is left up to the developer to have to implement when required. Honestly there might not be a better way to go with this. None the less it just makes things a bit more messy code wise. So developers - beware!
- MVC for scrolling lists.
It took a bit of time to deal with how android deals with the UI inflating associated with a scrolling container view. Though just a simple callback interface , it takes up a bit of time to set up your MVC model and associated adaptor to work with your specific UI control.
- Waiting dialogues.
While there is once again good documentation availble, I found that the google UI standards and APIs have changed. Multiple times. So interestingly enough I stuggled with pop-up dialogues a bit. First off there are 2 ways to implement them. And within that I found it difficult to determine when the UI artifact components where built in conjunction with inflation. This is particularily true as I run the blue tooth connectivity on background threads, thus I update the dialoge text and status on a UI thread. And additionally the dialoge is constructed in the activity construction method, but then show once you hit a UI click event. The document is well written out on the overall android architecture. But understanding how and when the UI elements are inflated out and made available took a bit of trial and error in more complex scenarios.
App Launcher on a Galaxy 21
The applicaiton requests the proper use access to make user of Bluetooth
The start screen lists bound bluetooth devices
Connectectivity delays provide normal wait indicators.
Connection errors are visually indicated on the display.
When successfully connecting the app connects then requests current operation mode details.
The IOT device is designed to operate in either Local keyboard control mode or Remote access
mode. To transition to remote access click the Remote button to request access. (Remote access can be locked out,
thus it is possible for remote access requests to fail).
Additional screens for special operations
System Information display
LED Color selection screen
|
