Last but not least - the app for the mouse robot (part 4 of 4)

Looking for some context on the robot? Here are: part 1, part 2, and part 3 of the series!

We are creating a simple app - one that uses a seekbar to set the position of the backend using the "setpos" function. The code for the entire thing can be found on my github, at https://github.com/nirsoffer/RobotController/ - and this blogpost will serve as a documentation for how it's done and why it was done that way.

I used the basic wizard of Android Studio to create a Fullscreen Activity app, and populated it. Download Android Studio here.

This being my first ever Android app, I probably messed it up to no end, but it functions and is a good starter. Don't take my coding practices as sound, though.  I haven't been coding professionally for nearly a decade.

There are three key files (at least at the time of writing this blog post):

FullscreenActivity.java: Initializes activities, request queue, and ParticleIORequestor - change this line:

 

final ParticleIORequestor pioreq = new ParticleIORequestor(getApplicationContext(),
new ResponseListen(), 
new ErrorListen(), 
"your device id here", 
"your token here", 
"setpos");  

to contain your token and your device ID from the Particle.IO builder. Without this - things won't work.

FullscreenActivity.java initializes a seekbar in the middle, and a 3 button radiogroup (left, center, right) at the bottom. These are meant as a quick shortcut to setting the seekbar to 0, 50, and 100.

The seekbar ends up calling the "turn" function in the ParticleIORequestor.

Speaking of:

ParticleIORequestor.java: is the "secret sauce" of the app; it's what ends up sending requests to the backend. It's heavily reliant on Volley to send these requests. At its core, it:

1. Initializes a singleton request queue object.
2. Enables sending requests through turn(int).

turn(int): cancels ALL pending requests (as an exercise to the reader, ask yourself why), and inputs a new one in. The callback functions for onResponse and onError are set in FullscreenActivity. Is it ugly? Yes, but I didn't want to bother with more complicated patterns, and the response and error callbacks needed access to the UI context. If you have more elegant ways of doing that, please let me know.

The tricky GoogleFu here is the POST request, which is poorly documented by Volley developers. The trick is to override getParams and getHeaders. I would have used a JsonRequest object rather than a StringRequest, but I suspect strongly that JsonRequest gets the POST parameters wrong and encodes them into a JSON document into the data portion of the HTTP request. I was too lazy to sniff and verify, but StringRequest works fine too.

SingletonRequestQueue.java: is an auxiliary class nearly copied verbatim from the Volley docs designed to supply a singleton request queue so there is only one.


there you have it - any questions? Post in the comments below!