id: 161 View:category
Tutorials  Architecture
The About Process

The ViewModel - your single source of truth

Android developers will have heard about the not-so-quiet revolution introduced at Google I/O 2018 in the form of "JetPack". This is an awesome set of tools, software components and just plain know-how which Google put together to let everyone use the best-practice they've evolved into using themselves. Sure, you can continue with your current frameworks and libraries, it's just that now, zillions of the wheels you might be tempted to reinvent are all laid out for you, and in a way that makes using them a really smart choice.

Jetpack covers UI navigation, tasks, db etc and you can read more about it here. What caught my attention was the way an old problem I've covered before can be tackled, and since you don't need an oracle to see where languages on Android are headed, I chose Kotlin rather than Java. The new killer component is called the ViewModel, and it's purpose it to hold non-UI data which lives independently from the usual app lifecycle. Even better - it can run methods in this new "outside the Activity" place, which means we have a new way to run background tasks. ViewModel predates JetPack, but is considered one of it's central components now.

What's presented here is a way to keep the UI up to date even when the app is backgrounded. There are plenty of ViewModel tutorials around, such as here, here and here, so I'll skim over the basics and focus on the backgrounded UI part, which needs some care to get right.

The source for this project is available on GitHub, and if you just want to run it, allow unknown sources on your Android device and click here.

Tutorials  Build  Gradle
The About Process

How about that?

Here's the third in a series covering some handy tools which an Android developer can wire into their build system. Ideally, this would be right when the project is started, but adding to an existing one shouldn't be too difficult either.

This one's focused on something we're all familiar with. Pretty much every app needs some way inside the app to identify itself further to the user, and the usual way is an About box.  A basic one might just show the version number, but more sophisticated ones can vary according to the kind of build it relates to, for example debug or release. There are plenty of other areas it's useful to cover too, for example does this build expire? Where can the user report bugs? Who wrote it? Even functionality, such as a "Rate us" link, can be added as boilerplate then tweaked later. Or your logo, cutely being animated ;-)

When you've done this a few times too many (!) you realise there ought to be a way to automate most of this,  and a skeleton one could be used so the developer can, ahem, flesh out the apps info later with most of the basics being dealt with already.

The source for this project is available on GitHub, and if you just want to run the app, allow unknown sources on your Android device and click here.

Tutorials  Build  Gradle
The Versioning Process

Where did that APK come from?

Welcome to the second in a short series covering how to give the Android build process a little boost from the get-go.

Once an APK is built and distributed, developers know they can kiss goodbye to controlling where it ends up. This can be a problem with testing, maintenance etc, and without further care such as clear versioning identification in the app itself, make tracing bugs harder. For example, if every released APK was just called MyApp.apk, how can you tell the one released this morning from the one released last month?

Versioning systems such as Subversion, Git etc support these id's, so it's possible to match up a particular check in with the files needed to create that APK. 

What's described here is a way to automatically add those version details to the produced APK file itself, so you'll end up with MyApp-debug-beta-1.1.0-368-dev.apk or whatever. The filename comes from a combination of the build variant name, the id in the version system and the source machine (eg. a CI build, or a local developer, "dev") which created it. The example uses subversion as the CM.

This project is available on GitHub.

Tutorials  Build  Gradle
The Signing Process

Release early, release often

This is the first in a short series collecting together a few techniques for enhancing the build process for Android. It's aimed any anyone starting a project who wants a little more productivity than the default startup wizards in Android Studio (3.1) offers.

Sometimes it can be useful to see how release builds measure up early on in a project's development.

This might be to keep an eye on the final APK size, to see what performance is like without the debug code or to make pre-releases available to testers, etc. Android Studio (3.1) does a great job of setting up the builds for new projects in debug, but the variant for release isn't really there from the get-go. This is most likely because everyone's signing process is different.

Sure, when you try to run in release mode you're prompted for all the signing credentials, which is OK for occasional signed builds. However, a solid, repeatable signing system, which works unaltered with automated building tools such as Jenkins, is useful to slot into the dev process early on.

The full project presented here is available on GitHub.

Tutorials  Android Things

Android Things Development

When Googles IoT platform, Android Things was launched, it caused some rethinking for time-served Android developers. 

This was necessary in order to adapt to all the anticipated hardware applications it will be used for, and it meant many familar features had to be removed. The most radical of these was the default UI, since the UI is now optional. This doesn't mean there isn't one, it just means you have to roll your own entirely. Of course you do this using the standard Android View framework you're used to in its entirety, but by default, the system supplies nothing. That means there's no status bar, no navigation bar, no back button etc - and your device has no home screen.

The idea with Android Things is you're creating a hardware applicance. Typically, this runs only one app and it's this app which starts up when your device is booted, That's the production scenario which is the one your end user expects. For development, this can be a little restrictive. You can certainly install many different apps onto Android Things devices, and developers often do this to try multiple versions of their apps, run small self-contained test apps or measure performance variants of the same one, for example. This is cumbersome without a home screen or some kind of launcher, because each has to be built and installed fresh so it "wins" in the boot race.

Tutorials  UI  Layout
Beautiful Animations with ContraintLayout

Minimal coding required

ConstraintLayout seems to be the hot new thing nowadays. Flattening your view hierarchy, improving performance, supporting arbitrary bounding rules — it promises to fix all of the shortcomings of some previous layout files (*cough* I’m looking at you RelativeLayout *cough*) and more. But there is one other benefit of ConstraintLayout that most people are unaware of and the official documentation curiously doesn’t mention anything about: performing cool animations on your ConstraintLayout views with very little code.


I’m going to assume that you know the basics of ConstraintLayout (e.g. you know what is app:layout_constraintLeft_toLeftOf and its relatives). Most of the tutorials on ConstraintLayout focus on using the newly improved Android Studio layout design panel where you can drag/drop/visualize the various constraints. For the purposes of animations, it’s also good to take a peek at the generated XML to get a better understanding of the various constraint attributes so you know how to manipulate them.

Full article