storm-gen in Maven Central Repository!

Storm-gen is an open source library created by David M. Chandler, or more exactly an Annotation Processor Tool that allows you to easily create and use SQLite databases on Android in the simplest and effortless way ever, by using simple annotations.

I personally love so much the simplicity of this project that I started to contribute by bringing it lately to maven so we could put the two jars into Maven Central Repository, and it finally happened, yay!

Here’s how to use storm-gen into your Android Studio project, short story:

Enjoy!

Introduction to stORM

I always felt jealous of the iOS devs for having a tool like CoreData to manage databases really easily and we, Android developers, didn’t have. Our only choices were:

  1. Write our own DatabaseHelpers and type that boring SQL code ourselves
  2. Use an ORM like ORMLite (runtime annotations) which has an overhead on our app size and on runtime execution (annotations were really slow on Android < 3.0).
  3. Use an ORM like greenDAO which does not uses annotations thus is faster than ORMLite but you still add a jar to your project, and then your models need to extend the right classes (which can be a pain in the ass if your object hierarchy is already defined for instance).

And that was it.

It’s a bird? It’s a plane? No, it’s stORM!

Recently, a new library and tool called stORM was created by David Chandler, a googler.

stORM is based on the Annotation Processing Tool (APT) which lets you create annotations and then process them and do whatever you want with the result like generating code directly in your project!

So by using stORM annotations (storm-api.jar), stORM will generate (storm-apt.jar) for you the necessary helpers + daos classes!

The stORM « getting started » tutorial is quite easy and I suggest you to try it. It’s a little weird to add a jar into a place we never usually add stuff but it’s worth it. Here’s where storm-apt jar will be added:

Capture d’écran 2013-01-21 à 21.45.09

Honestly, I don’t like when too much magic is going on into my project. That’s why I changed the APT generated folder from « .apt_generated » to « apt » (if you do so, don’t forget to add « apt/ » in your ignored file list of your repository unless you like bad practices):

Capture d’écran 2013-01-21 à 21.49.37

 After following the tutorial you can see the generated classes by the tool in the apt source folder:

Capture d’écran 2013-01-21 à 21.53.51

Then I can easily use PlaceDAO where I need to, like in a loader!

The only issue that occurred to me is that I usually implement Serializable on my entities/models to pass them to activities or services or fragments by Intent/Bundle but stORM tries to process every field and expects to find the right accessors for that field unless it is marked as transient.

Here’s the Serializable « stORM compatible » entity:

And if you’re more a fond of Parcelable the same applies to the CREATOR field:

 

Conclusion

stORM is not yet finished as it doesn’t (yet) support relations but it’s already generating the necessary helper classes with the minimum footprint on your app. Grandiose!

Introduction to Google Android Maps V2

I always need a new project or a use case to try out a new library or SDK. As I wanted to test the new  Google Maps Android API v2, and as I’m using a lot a nice map based website, why not building an android version of it?

The first thing you need to know is that you won’t import directly any maps.jar anymore in your project, but you’ll actually import an Android Library project called Google Play Services SDK.

Google Play Services,

As discussed here and here, and as I use fragments everywhere and also obviously ActionBarSherlock, I put in place a SherlockMapFragment to be extended by your fragments.

If you want to bring a simple refresh action item, use refresh-action-provider (explanation here) so here’s a RefreshMapFragment which extends SherlockMapFragment (that’s what I’m doing in my app).

Back to Maps v2 now. After setting a key (from Google API Console) and the right permissions into the Android manifest, you’ll want to extend SherlockMapFragment (or RefreshMapFragment) and add this fragment into your layout:

You can see that the whole centering map and stuff is done by XML. It could be done in code too.

In this case my model object is a « Category » which contains a list of « Place » (latitude, longitude, title, ..) that I’m going to place on the map. The fragment is pretty simple (coupled with a loader):

Just call getMap() and you’re ready to add Markers on it. Another awesome feature that we didn’t have before (and that sucked a lot, for about two years) is that we can change completely on two different levels how the info window looks by creating a new InfoWindowAdpater and applying it on your map.

Using a loader, I’ll get the data as categories in onLoadFinished() and I’ll create Markers (with different icons thanks to BitmapDescriptorFactory.fromResource()) that will be added to the map:

The complete PlaceMapFragment can be found here.

The main problem I encountered is about OO: Marker class is final, which means we can’t extend those objects to add our own attributes or methods. 

This means I have to keep an HashMap of <Marker, Place> and pass it everywhere I need the related data of a Place when I have a Marker from a listener for instance. I really hope that when the API will be finalized (ah, ah..) the authors will let us extend their objects… the minimum acceptable would be to have an Object setTag() and Object getTag() methods like on Views!

An interesting and deeper look at this new SDK was done by Cyril Motier on his blog!

Some screenshots of PlaceMapFragment:

822+ elements showed on the map

822+ elements showed on the map

InfoWindowAdapter in action

InfoWindowAdapter in action

 

Google Maps Android API v2 + ActionBarSherlock

The new Google Maps Android API v2  looks like a big step ahead, but how can you use it with ActionBarSherlock ?

Simply add this class to your project (in any package you want, but I like to add it in the same as the other sherlock fragments: com.actionbarsherlock.app):

Then by extending this class, you can have both important methods:

  • getMap()
  • getSherlockActivity()

I guess Jake Wharton, the ActionBarSherlock library author, will update soon his Maps extension and add such a class into it.

Loading and Refreshing User Experience

There’s chances your app gets something from the Internet (or locally) at some point. A list of news, some images, etc. How do you provide a visual information to the user that something is going on?

Dialogs

Here we’ve got a progress dialog that pops up every time the app feels like it should load something.

I’ll tell you the truth: I don’t like dialogs. As a user they remind me a lot of those days when a ‘webmaster’ decided for me that it was time to see something he decided.

I hate loosing control of what I do and I get that feeling with dialogs. As a developer, the life cycle of a dialog was quite hard to manage properly but it got much easier last year with the DialogFragment class.

What annoys me the most with dialogs is when I cannot dismiss/cancel the damn thing. Everything is blocked till the app can load its stuff. When it takes too much time, I lose patience and I just want to press the back button! And then, nothing happens. That’s one of the worst user experience scenario ever: the user has no control and cannot do anything about it.

When the back button is pressed, the minimum would be to stop the loading task and dismiss the dialog. Please don’t use dialogs, or if your client really really wants it, at least make it cancelable.

Pull to refresh

pulltorefreshThis UI pattern comes from the Twitter iOS app, and is reproduced on Android.

It has been already discussed and debated many times in the Android Community.

My opinion on this is that it depends on the context and the use case. If you’re loading tweets or messages of a live event and your client insists, why not…

Hopefully there are libraries out there to easily add this UI pattern like Android-PullToRefresh (I didn’t try that library myself).

 

Embedded Progress/Loading View

Screenshot_2012-12-24-15-47-31

Right before a list of elements shows up, a progress view is shown, and when the loading is done the list of elements appears. As a user I like this behavior because I can still do whatever I want if the loading is too long (there’s nothing to do for this screen to be « cancelable »).

An easy way to do it is to use ListFragment (I’m not speaking about ListActvitiy because obvisouly everybody is using fragments now, right?) using its default layout (meaning not overriding onCreateView()). To be able to see that progress view in that default layout, set the adapter at the last moment, like when you have your data.

I usually like to provide my own layout for the ListFragment to provide a different progress view and also an empty view.

 Indeterminate Progress indicator

Another way to show a progress is to do it in the action bar, where you can show a progress bar within (almost) a simple call.

The user will know that something is going on and she can decide to wait until it’s finished or leave the app (maybe to check the connectivity).

On the bad side, you can’t really customize the look of that progress indicator. It’s kind of really big and has no right margin  so it looks stuck to the right side of the action bar.

In some cases, some elements in the action bar could « move » (like a spinner) if there’s not enough space for that indicator.

The view itself feels a little too empty as well, right?

What if we want to provide an action item to refresh the data by an user action?

Indeterminate Progress indicator + Action Item + Loading view

Screenshot_2012-12-24-16-36-18 hidden2We could put an simple ActionItem in the action bar and trigger the refresh in onOptionsItemMenuSelected(). It really depends on the use case, but isn’t it strange to have two different kind of indicators at the same time in the action bar, one being the indeterminate progress indicator and the other one the action item?

Not to mention the implementation: you’ll need to manage the fact that the user is clicking on the action item when the loader/task is still running…

This user experience is not the greatest but at least the user has full control and is notified by the indeterminate progress indicator and the loading view in the middle of the list.

But how can we do better than that?

Refresh Action Provider + Loading view

Screenshot_2012-12-24-17-36-56Screenshot_2012-12-24-17-37-01

Let’s merge the ProgressBar and the ActionItem into a special action item!

This pattern is used by many of the Google apps: the action bar contains a refresh button and when it’s triggered the action item is changed to a ProgressBar. When the load is finished, the button comes back.

A good way to put whatever you want in the action bar aside with your other action items is to implement an ActionProvider. In our case, we’re going to switch between a button and a ProgressBar depending on the state of our loading.

RefreshActionProvider is an android project library to re-use easily this special refresh action item. Plus, there’s a convenient RefreshableListFragment to be extended by your fragments. Try the sample app or fork the project!

Conclusion

There are different ways to show a progress/loading view and to provide a refresh action item, but at the end, it really depends on your use case. The most important thing is to be consistent across your app screens and to really think about the usability of your app.

 

 

Droidcon London 2012

Since I became a developer, I’ve had the opportunity to attend several conferences, of which Droidcon London was a definite favorite, along with Google I/O 2012, of course!

From the social networking point of view, I met Nick Butcher and Rich Hyndman (from the Android Relation Team) and they’re really cool. The fact they were there made me feel like Google supported this event and it made it even more special. I also discussed a little bit with the talented designer Marie Schweiz which is really active into the Android community.

It was the first time I could see Mark Murphy (CommonsWare) « in real life » so I didn’t want to miss his talk (about NFC and beaming). I’m sure his name sounds familiar to you as we all came across of at least one of his numerous examples on Github.

Within his talk Cyril Mottier explained us his point of view on the « Fly in app menu », mainly asking developers to not succumb to the hype it generated lately and to really think about the use cases and the other navigation alternatives. I totally agree with Cyril even if the temptation to put that cool menu came into my mind for the theutlimateandroidlibrary.com android app. But no, there’s no need for it there. Yet.

Chiu-Ki Chan made an awesome talk about custom views and how we should think more about it and that we actually have more possibilities than we can think of. In about two years of Android development I only did one custom view but I definitely want to write more of those. The main use case I usually encounter is when I want to reuse some xml and java code (for the logic side), thus a View/Viewgroup doesn’t feel like the appropriate place to put this. I think a fragment would be better but it has some limitations (not anymore! Since the release of Android 4.2, fragmentception is now possible!).

About fragments, Corey Leigh Latislaw reminded us to use those from the beginning of a project. I think she sent us an important message: Every project should be done with fragments by default now. If you want to be able one day to easily extend your app with different layouts on different screen sizes (tablets, tvs, ..) it’s the only way to go.

Another interesting talk was « Android layouts » by Mark Allison that put in evidence the importance of every kind of layout and when and how to use them.

Like in every conference there’s always a stand with some technical books that you want to buy. I asked for Juhani Lehtimäki‘s book, Smashing Android UI and it arrived later on the first day so I got my own copy, yay! The second day all the copies of that book were already sold!

I can’t wait to see the other talks. It will all be soon available online.

I left the place full of great vibes and a lot of motivation, and I already bought my ticket to Droidcon London 2013!