55 articles Tag android

Rainy Days 3 is here

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).

Check out Rainy Days in the Play Store

Droidcon UK Cupboard talk

I did a talk on Cupboard at the excellent Droidcon UK conference this year. The talk was recorded and published at Skills Matter. The talk outlines some of the history and goals of Cupboard and shows a few examples of using the library from different contexts. You can checkout the video from this link: http://skillsmatter.com/podcast/os-mobile-server/simple-persistence-with-cupboard

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!

Cupboard v1.0.4

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

Minor update to Cupboard

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

Embedded Link

qbusict / cupboard
The simple way to persist objects in an Android SQLite database.

Cupboard slides from Droidcon UK

I presented on Cupboard at the Droidcon UK barcamp, if you are curious, you can find the slides of that talk here: https://docs.google.com/presentation/d/1giCUSlDwdG2ghbbuHBvrL-gqfnw0Q3RSlTBOCVmouPQ/pub

Example of custom states in Android components

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:

  1. Extend TextView
  2. 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 android:duplicateParentState=”true” meaning that the TextView will inherit any states from the parent view group.
  • 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.

PS: ViewGroup has android:addStatesFromChildren which is equally useful!

Comment on this post on Google+

Manage Android state with bundles @Frozen

This morning this post showed up in my stream by +Philippe Breault. About the caveats when treating the Application object as global state.

Although the advice that he gives, don’t store stuff in the Application object, is sane the example doesn’t really illustrate the problem. His argument is that when the activity is recreated, the application is recreated and therefore the state is lost. While this is true, the real issue is that the GreetLoudlyActivity from his example isn’t saving any state, which it should.

Luckily, this is easy to fix! A little while ago I wrote bundles, a set of two annotation processors for Android. The @Frozen annotation makes it easier to save and restore state in Activities and Fragments. So let’s fix the GreetLoudlyActivity:

If you don’t want to use custom code for it, this is how you would do it without @Frozen:

Remember, there’s a setting in the development settings section of your phone (ICS or up) to test for these kinds of bugs. It’s the “don’t keep activities” option.

Introducing Cupboard: simple persistance for Android

Today I’d like to introduce you to a new library that I’ve been building and using at Qbus in various apps for over a year called Cupboard.

Cupboard is what I’d like to call simple persistence for Android. Most non-trivial apps need some kind of persistance, most likely using a SQLiteDatabase. There are already many libraries and frameworks like ORMLite that are populair choices, but after evaluating most popular options we decided to take a different path.

Background

Basically, I built Cupboard out of frustration with the available options. I don’t like frameworks that take over my code: require me to extend an interface for models or force me in to a global DAO / EntityManager kind of approach. I needed something that I could easily integrate with what Android already gives me. Things like SQLiteDatabase, Cursor, ContentValues. I especially needed something that could work in multiple contexts: passing data from/to a ContentProvider from an Activity for example. None of the options I looked at totally satisfied me in that regard.

For Cupboard I set out to achieve the following goals:

  • Persistence of Java Objects, no more ContentValues and Cursor.getColumnIndex()
  • Simple and lightweight
  • Not a framework, but a library, like syntactic sugar.
  • Integrate with core Android classes without any hassle

Let’s also mention what Cupboard isn’t: it isn’t a full fledged ORM solution. For example: while you can hold references to other entities, the relational aspect isn’t managed by Cupboard. This makes things simpler and we haven’t missed it in our apps so far.

How does it look?

An entity is a very simple object, with their field names corresponding to the columns of the table they are stored in. Remember, field access is fast in Android.

public class Person {
 public Long _id;
 public String name;
 public int age
}

Here’s a line of code from a CursorAdapter to bind to a Person object from a cursor

Person person = cupboard().withCursor(cursor).get(Person.class);

Here’s how you’d get a person with id 12 from a SQLiteDatabase:

Person person = cupboard().withDatabase(db).get(Person.class, 12L);

Or using a ContentProvider:

Uri uri = ... // the uri to Person object we want to get
Person person = cupboard().withContext(mContext).get(uri, Person.class);

Note that the cupboard() function is just a helper; it holds the Cupboard instance that knows about your entities. You could inject the instance if you are using a dependency injection framework.

The Cupboard instance doesn’t hold on to your database, it doesn’t manage anything. So if you would need to interact with the cursor in the first case, or the database in the latter case, no problem! Pass in a different database? Sure!

Using Cupboard

Cupboard is Open Source software, Apache Licensed like most Android libraries. You can get it at the project site. Check out the documentation to get started or look at the sample project. You can add it to your project as a simple jar. There’s a pre build jar on the project site as well. The jar includes the source for easy debugging.

I’m curious if you think this is useful to you too. Let me know on Google+ or Twitter!

Bundles 1.0.2

Minor update to bundles, my annotation processor for Android source code to help constructing fragments and saving state.
I’ve been sprinkling these annotations in my existing projects and fixed a few small issues.
  • The generated FragmentBuilders now get a newFragment() method useful if you want to construct a fragment with only required arguments
  • The required args are sorted now, so that the builders are consistent when you add, remove or recompile the source class ;)

You can get it here: https://bitbucket.org/hvisser/bundles or from github here: https://github.com/hvisser/bundles

View this post on Google+

Android Fragment builder annotation

Since annotation processing is the new hip thing to do, I thought I’d jump on the bandwagon ;) Yesterday I wrote two annotation processors to make my life simpler. It doesn’t have a spiffy name like +Jake Whartons butterknife, but hey, you can’t have it all.

The first one deals with Fragment instantiation and arguments. As you might be aware, a Fragment needs to be instantiated with a Bundle to pass the arguments. That usually leads to a static newInstance method where you marshal the passed arguments into the arguments bundle, instantiate the Fragment and set the bundle on it. Using the @Arguments annotation, this process is a lot easier. You just annotate your fields and from that information a <YourFragment>Builder class is generated. The builder can be used to construct the fragment in a type safe way, and it has a static method to “inject” the arguments into the fragment at your convenience.

The second annotation is @Frozen. This annotation generates a <YourClass>State helper class that will save the fields annotated with @Frozen to a bundle or set the fields on your target object. This is very useful in onSaveInstanceState and OnCreate etc.

The code and jar download is on bitbucket here: https://bitbucket.org/hvisser/bundles and is in the public domain. It’s not yet field tested, so be aware that there might still be some subtle bugs. Yes I’m just throwing it out there, hoping that it’s useful to you.

View this post on Google+