App Development

Android Development Tidbits // No. 4

Welcome to the fourth post in the Android Development Tidbit series! If you missed last week’s tidbits, you can catch up on them here.

Tidbit One

SQLite has limits to most operations you might perform. They’re outlined here. One, in particular, that I’ve hit is #9 - the max in SQL variables. During a database upgrade, we wanted to change a certain value for certain elements. This was improperly done by getting the complete list of items to update and then updating the value for all of them in one go. Unfortunately, the limit on items is 999 by default, so this crashed in the field. Instead, these requests should have been batched. For fun, the resulting query looked like this when done incorrectly:

Too many SQL variables (code 1): while compiling:
UPDATE items SET my_field =? WHERE id 

- Tidbit Contributor, Charlie Fairchild

Tidbit Two

This tidbit is a bit of a throwback, so there might be checks for this in Android now, but a long time ago I was developing a game that really lagged whenever the user touched the screen. I measured everything that was going on and found there was very little information available at the time to help me figure out how to fix it. Eventually, I found this discussion which led to the fix. It turns out that the Android OS will fire touch events as fast as you can consume them. For my game, I was saving off the touch data and using the raw data later to figure out where the user touched the screen. This meant there was almost no processing done when a touch event was passed through. All I had to do was introduce a Thread.Sleep() for ~20ms in the onTouch method. - Tidbit Contributor, Charlie Fairchild

Tidbit Three

If you have a view that should not be pressable if it’s drawn over (think click-jacking) then you can use this flag: setFilterTouchesWhenObscured.

- Tidbit Contributor, Charlie Fairchild

Tidbit Four

ContentLoadingProgressBar is a thing.

* ContentLoadingProgressBar implements a ProgressBar that waits a minimum time to be
* dismissed before showing. Once visible, the progress bar will be visible for
* a minimum amount of time to avoid "flashes" in the UI when an event could take
* a largely variable time to complete (from none, to a user perceivable amount)

- Tidbit Contributor, Jossay Jacobo

Tidbit Five

Github has protected branches and you should use them to prevent people from accidentally causing a bit of git-related mess. You can prevent people from deleting branches and force pushing to branches. You can also make sure that changes to those branches have to pass certain checks. - Tidbit Contributor, Evan Tatarka

Moving from Monolith to Microservices Architecture

When a client decides to move from a monolith platform to microservice architecture,...

Read the article