It has been a while since Rainy Days got an update, but now the new version is available to all.

Rainy Days 3 is a complete rewrite of the app that I started in 2009. Things are moving pretty fast in Android so maintaining the old code base for the app became harder and harder, so I decided to start fresh.

The new version features a new design on all devices, Google Maps version 2 (with vector maps) and improved images when zoomed in. Over the last couple of weeks, some of you have already tried the new version in beta or as an early update. The feedback I got from that is incorporated in this update, and of course I will be improving Rainy Days over time.

I hope you enjoy the new version! Feedback is very welcome, just send me an email (see the app listing for that).

My Gradle plugin to support annotation processors in Android Gradle builds & Android Studio, android-apt, got another update! Version 1.2 now also supports library projects. This version requires the android plugin version 0.7 or up, since that version supports a new API that I use in the plugin. So upgrade your Android Gradle builds and generate some code :)

I’ve also recently set up a Google+ Community for Cupboard, where we can have a friendly discussion about anything related to Cupboard, like feature requests, issues or general questions. Feel free to join, I’m really curious and exciting to hear how Cupboard is used in the wild!

This plugin helps supporting annotation processors in Android Studio. See this post: https://plus.google.com/102164807080986038267/posts/7Wr3FcdNVxR for more info.This release fixes a minor bug that occured when you did not apply the android plugin to your project, but more importantly it’s now possible to pass extra configuration arguments to the annotation processor, which is something that the popular Android Annotations library needs. The project site has an example on how to configure annotation processor parameters.Thanks to +Thomas Bruyelle for sending the PR and testing the final implementation of this feature!It should be live on Maven Central shortly.

Next up is making the plugin use a new API that has been introduced with the Android Gradle plugin.#androiddev#gradle

I just pushed another minor update to Cupboard! Cupboard now supports limiting the result set (through the SQL LIMIT clause) and distinct queries if you need them. There’s also a new variant for bulk put’s that takes a Collection, which might come in handy if you are getting your entities from services like Parse.comTo learn more about Cupboard visit https://bitbucket.org/qbusict/cupboardAdditionally I’ve setup a community for Cupboard for questions and discussion here: https://plus.google.com/communities/102678039256081927502
It’s spanking brand new, so nothing is there yet, but feel free to join and discuss anything with regards to Cupboard if you like.#androiddev

Here’s a small Gradle plugin that helps out if you have a project that includes an annotation processor. There are two use cases for this plugin:1. You have a processor that has a compiler part and an api part, you don’t want to get the compiler in your app. For this purpose the plugin sets up an apt configuration.
2. Your annotation processor produces source which you want to reference in Android Studio. By default these kinds of projects build fine in Android Studio, but the generated source isn’t on any source path in Android Studio so you might get errors there. The plugin will add the generated source to a source set so that AS will recognize it. This is also true for the first case btw; if the processor generates source, it will be added to the source set for the current flavor.

I just released a new version of Cupboard that adds support for Enum types and fixes a bug where private fields would not be persisted, in the case you prefer “normal” POJO’s with getters and setters. It should arrive in Maven Central shortly. For more info on Cupboard, refer to the project site at https://bitbucket.org/qbusict/cupboard

A while ago, I built a form based app with lots of input fields and all the things that come with that, like validation and error messages.

In one of the situations, if a section is invalid, the field labels should turn red. Easy right? Here’s the example layout:

And a naive way to switch the label colors when there’s an error:

But this is kinda ugly. We need to get “not-error” color from each component, store it, switch the color to red and if the error is fixed, restore the colors again. There’s too much code that deals with updating the view in here and it only gets worse if we add more labels.

Using selectors

You’ve probably worked with selectors before. In this particular case we’ll be using a ColorStateList selector to change the color of the TextView. First, here’s the selector:

This is just like any other ColorStateList xml. You place it in the res/color/ folder of your project. This selector has one thing extra though: the app namespace and the app:state_error state. In effect this selector says:

If the state is error the color used is color_error as defined in color.xml

If the state is pressed, for example if the TextView is clickable and you click on it, the color used is color_pressed

By default the color is default_color

By know you probably see where I’m going…If we can change the state of the TextView to app:state_error then the color should be set by the Android framework to the color_error that is defined. But how do we do that?

First we have to actually define the new state in res/values/attrs.xml:

Then we should actually apply that state. We can do that in two ways:

Extend TextView

Extend the LinearLayout containing the TextViews

In this case we’ll extend the LinearLayout like this:

This code should be easy to follow. We add an extra property mError to keep track of the error state. At line 3 a constant is defined containing an array of states that are set when mError is true. Then it’s just a matter of overriding onCreateDrawableState() which takes an int called extraSpace. Since potentially we’d like to add one extra state if the mError flag is set, the code calls super.onCreateDrawableState() with extraSpace + 1. Then, depending on the mError flag the error state is added to the list of states.

The final layout using this new component looks like this:

Things to notice in this layout:

In stead of LinearLayout, ErrorStateLinearLayout is used as the main container

Each TextView has it’s textColor set to error_color which would be the color state selector

Now we can finally update the view when there’s an error like this:

Much cleaner code, less bugs, yay for us!

Conclusion

By leveraging core Android principles, in this case using selectors, we can simplify our code a lot. By moving things that are related to the view out to xml resources not only our code gets cleaner, but we could also use the resources system to customize the ui based on the device configuration.

For some reason, now that Android is moving to a Gradle based build system, there’s some discussion whether Maven is better than Gradle or vice versa. There’s what I like most from Gradle compared to Maven:

1. Fast builds. Run a build twice: 2nd time you’ll see only “UP-TO-DATE” if nothing changed.
2. Dependencies choice: Artifacts in a maven repo? Have a library as a jar in your project? No problem, you can mix and match. A big improvement IMHO over the “everything has to be in a repo” approach that Maven has. Don’t make me maven install things or force me to have a repository manager. It doesn’t always make sense to have one.
3. Flexible configuration. For example: if you have some common configuration that you’d like to do in every build file, you can easily create a script for it and include it. Another example: in a multi project setup, you can configure a project from the top level build file, which is very convenient if you are including third party code without a build.gradle through a subrepository / submodule.
4. No more heaps of XML.
5. Gradle wrapper. Just checkout the project, and run gradlew to build the project.