Omelette, Snow & Godot
On Sunday
after a miserably wet and then heavily snowy walk through Victoria
Park to sample
Mr
Cyrus Todiwala’s excellent food at Park
Café, in this case a fantastic Algerian omelette; the first ever
omelette I have had that was genuinely uplifting I worked through a
bit of the Godot 2
documentation and tutorials, continuing to be amazed by the quality
of the engine and what it can do.
By the way, there’s
an excellent recipe from Katie Loves Cooking here
if you want to try it.
Cowbell
Monday started with a decision to abandon bringing the existing production code for Cowbell into line with the code base for my other apps as the more modern code has moved on to far and it would take too much effort to update. I decided to do a rewrite cloning off from my latest Travelling Santa Problem code base.runtime
Once the initial version of my running app runtime is released, I’ll be following a roadmap of features which I think will make it appeal to a wide range of runners and non-runners alike. This roadmap will include an Open Street Map capability and to that end I’ve been building OSM VM servers and proving integration with osmDroid.It’s a while since I’d worked on that area so a fair bit of time was spent updating the virtual machines. I’ll post something more on my planned initial infrastructure solution for that at a later date.
Whilst ensuring that map tiles were still served up properly to the Android client, I noticed that the map view would render correctly as it always has, then it would suddenly collapse down to a small section of the map. This area of the code has not changed for a long time so this behaviour was a puzzle.
I also noticed that the distance calculations were not updating and on one emulator the landing screen was failing to render completely. This was not going well. The TNG phrase “Bridge, we have a new problem” came to mind. It would render on the first launch after a fresh install, then nothing.
Clearing the head by taking a break
I am not fond of too many moving pieces on a project, so this was unsettling. I must admit that this day I really thought I should jack it all in. It was a tough day, but I was inspired by listening to “The Life Scientific” with Jim Al-Khalili and the fascinating Eugenia Cheng. Taking a break, listening to the programme whilst doing the dishes gave me the time to clear my head and dive back in.The missing landing screen issue may have turned out to have been solved by following this advice from Stack Overflow. I handle all my screen navigation by modifying view visibility and switching from View.INVISIBLE to View.GONE seemed to do the trick. I’m hoping this change may also clear up the map view collapsing issue.
Playing nice with threads
I went for a short run in the afternoon to clear my head again and see how the app was behaving in the real world. This short test showed that the distance run view continued to show zero metres run (sometimes) and I noticed that my battery was was (sometimes) being drained at a rapid rate.It turned out that I was not seeing any fresh points being returned from the database for the distance calculation to work on and I suspected this was a thread starvation issue.
I spotted that I was probably spanking the database and updating the internal data model too often, so the updates were backed off to be every five seconds and the various pieces could now get a chance to run.
Location, Location, Location
The next weird problem, which had me stumped for a while was around handling GPS permissions and the enabling of the device location service.Previously in Android, use of the location permission could just be stated declaratively in the manifest, but now things are a bit tighter and the user needs to be asked to grant the permission.
Android also has an API which will check if granting of a permission also requires a rationale to be presented to the user explaining the reason for the permission.
All of this is laudable and should over time help clean up the Play Store of overly personal data hungry apps. As some of you will know I implement a Cookie Consent Popup in my apps which is a legal requirement for EU originated apps, but I have only ever seen one other app be compliant in this area.
Location permission handling is split up into two parts. The first is getting the user to grant access to the device location, this is where the rationale dialog comes in. The second is the enablement of the location service on the device itself. This is where my weird bug came in.
The weird bug was preceded by a classic schoolboy error as evidenced in the screenshot below of the code before and after. Apparently exclamation marks are important in Java! What an idiot!
The runtime app uses an unbound service to receive the device location from the network and GPS and then broadcast it on to the runtime Android client. I need to handle the case when the service is running and the particular location provider is disabled.
If I detect that the device’s location service is off, I display a dialog to the user and give them the option to go to the location settings. This is started in a separate activity, the user does their thing and then the user returns to the runtime app and goes about their business.
The problem was, the dialog was not being dismissed. It took me ages to figure out what was happening, but not before I had panicked and adorned the code with various guarding conditions, dismissed the dialog in different ways etc.
I even followed the trail of this red herring when I spotted an error on my Marshmallow emulator, but not any other.
01-25 06:26:11.674 E/Surface: getSlotFromBufferLocked: unknown buffer: 01-25 06:26:11.676 onClick goToSettingsButton
It turns out there’s a bug in this version of Marshmallow (6.0.1). I burned a bit more time on that.
The penny dropped when I added this line of debug logging in.
01-25 08:01:40.188 D/runtime: ask user to explicitly enable location in settings
01-25 08:01:40.548 D/runtime: ask user to explicitly enable location in settings
01-25 08:01:40.557 D/runtime: ask user to explicitly enable location in settings
The dialog was dismissing perfectly…..only to reveal another instance of the dialog immediately behind. What a twit I am! AtomicBoolean guarding added so we only get one dialog instance and we were on our way again.
Wet, Wet, Wet
My next test was to check the accuracy of a run with an HTC One and S6 running runtime side by side. It was a damp day and the first part of the run went well.Then, the heavens opened and there was no way I could keep the rain off both of the phones. I have a pretty good cover for the S6, the Spigen Tough Armor which has been an excellent case for the Galaxy and really helps with the grip as well. The S6 naked is like holding a wet mackerel in your hand, it just wants to get away and fall.
The water must have ingressed into the exposed USB port, headphones port and the volume down control as the screen started to be unresponsive, then started randomly launching apps, Samsung VR seemed to be the main one, giving me a rainbow coloured screen and frenetically switching between apps.
I could not get the phone shut down and got home as soon as possible to get it dried off. It could not have been more that a drop of two of rain that may have got inside, but it was enough.
Only afterwards did I find out that the S6 does not apparently have an IP rating as they wanted it to look sleek and cool more than they wanted it to be durable. This could be an expensive brick and one of my main development devices was now dead.
This was not a good week at all, wishing I was lucky.
No comments:
Post a Comment