Flockin’ Droid

While ago, I was looking for some informations about the film Batman Returns and stumbled upon the flocking algorithm, developed by Craig Reynolds in the eighties.

It has been used for many applications, other than movie making: optimization tasks, data visualization, UAV flight strategies, modeling of humans’ opinion flow in social networks and many more.
Read more of this post


Take a rate, take a dialog!

Just made a small and quick component for Android.
It is a dialog that pop up after a certain number of day and app launches, to ask the user to rate the app in Google Play.
Eventually it can show a “More” button to display the other apps of the author in Google Play.



It is a subclass of DialogFragment and I also made a version with the Support Library (V4).

If you have any suggestions / opinions, please jot them down as comments in this post. 🙂

I tried to make this dialog to be easiest to use as possible.
So this post is also some sort of tutorial about using DialogFragment (or at least an attempt :-P).
It is open source, of course, with Apache License 2.0.

Please, use dialogs carefully, as they can worsen user experience.
Read this post of Juhani Lehtimäki for more.

In my opinion, a “rate me” feature can still be implemented in an app, as a part of an already existing view or existing dialog, as the About or the Changelog.
Read more of this post

The configuration bug

Fork me on GitHub

If you create a widget with a configuration activity, you may get a strange bug that involves unexpected creations of instances.
Read more of this post

Take your time – Widgets and AlarmManager

Fork me on GitHub

In our previous example, our widget is updated through two events: user’s tap and the updatePeriodMillis of the provider info file.
Using the xml file has two main disadvantages:

  1. Users cannot select the update interval.
  2. The minimum interval time is 30 minutes.

To overcome these problems, just use an AlarmManager to fire the updates.
Read more of this post

One update for widget

Fork me on GitHub

With the widget of my previous post, if we add more than one widget to our home screen and tap to one of them, all the widgets, all the instances, update themselves.
Also, when we tap “Ok” at the configuration Activity, all the widgets update, again.

This may be the exact behavior we wanted but what if we desire that only one instance, among multiple instances, updates at the click event and after a successful configuration?
Read more of this post

Android App Widgets and their Configuration

Fork me on GitHub

Recently, I tried to implement an Android App Widget with a Configuration Activity.

It didn’t went smoothly but I did learn something on the way.
I will expose what I could learn this time in three four posts: this first one with the bare minimum to make a working widget + configuration, a second one where I’ll describe my attempt to direct a click event to only one instance among several instances of the same widget, a second third one with an AlarmManager that trigs the updates and a third fourth and last one in which I will expose a known bug and my attempt to solve it.

The theory

An Android App Widget may have a Configuration Activity that launches when the user add the widget on the Home Screen. It is used to let the user customize some settings of the impending widget, like the color or what data to show.
It is not mandatory but it may comes in handy in many use cases.
Read more of this post

Post processing vs Post initialization

Sometimes it is useful to be able to modify an EObject right after its creation, in runtime.
With “modify” we can mean several things: change the metamodel of the model (adding for example a feature or an operation) or change the values of the model (setting the value of a given feature) or both.
For clarification I shall call the second case “post initialization” to differentiate it with the post processing step.

Read more of this post