Piwaï.info

Square Cash - you owe me money!

2013-10-17T00:00:00+00:00

This week, Square introduced Square Cash, a new service that lets you send money to your friends through email.

To use it, just send your friend an email with the amount in the subject and Cc cash@square.com.

That’s it, you don’t need to install any new app, go through a painful signup process, or use a specific email provider.

It’s free, simple, secure.

Here is a trick I’d like to share with you: you can make it even simpler for friends who owe you money by sending them a mailto link. Then, they just need to click on the link to open their favorite email app and send that worthy email.

<a href="mailto:your@email.com?subject=$1&amp;cc=cash@square.com">Send me money!</a>

Send me money! »

I think that’s a pretty cool way to collect money from your friends :) .

Side note: as of now, Square Cash only works in the US.

Comments

Transparency with JPEGs done right

2013-04-23T00:00:00+00:00

A few months ago, Square published a great article on Transparency with JPEGs on Android. It’s definitely worth reading! Just don’t use the provided code yet :) .

Romain Guy suggested in the comments that you can do this in a much more efficient and simpler way, either by using a BitmapShader or by playing with Porter-Duff blending modes.

Using a bitmap shader is great for dynamic masks. To apply a static mask to a bitmap loaded from a JPEG, Porter-Duff is the way to go, as we will see in this article.

Principle

We just need to load the bitmap, and then draw the mask on top of it with the right Porter-Duff mode.

Here is what the Android documentation has to say about the different modes:

ADD Saturate(S + D)
CLEAR [0, 0]
DARKEN [Sa + Da - SaDa, Sc(1 - Da) + Dc*(1 - Sa) + min(Sc, Dc)]
DST [Da, Dc]
DST_ATOP [Sa, Sa * Dc + Sc * (1 - Da)]
DST_IN [Sa * Da, Sa * Dc]
DST_OUT [Da * (1 - Sa), Dc * (1 - Sa)]
DST_OVER [Sa + (1 - Sa)Da, Rc = Dc + (1 - Da)Sc]
LIGHTEN [Sa + Da - SaDa, Sc(1 - Da) + Dc*(1 - Sa) + max(Sc, Dc)]
MULTIPLY [Sa * Da, Sc * Dc]
OVERLAY
SCREEN [Sa + Da - Sa * Da, Sc + Dc - Sc * Dc]
SRC [Sa, Sc]
SRC_ATOP [Da, Sc * Da + (1 - Sa) * Dc]
SRC_IN [Sa * Da, Sc * Da]
SRC_OUT [Sa * (1 - Da), Sc * (1 - Da)]
SRC_OVER [Sa + (1 - Sa)Da, Rc = Sc + (1 - Sa)Dc]
XOR [Sa + Da - 2 * Sa * Da, Sc * (1 - Da) + (1 - Sa) * Dc]

Crystal clear! Hopefully the Xfermodes example in the API Demos demonstrates what the different modes do:

The yellow circle is the destination bitmap and the blue rectangle is the source bitmap. The destination is drawn normally, then the source is drawn on top of that using the given Porter-Duff mode.

To apply the alpha mask, we will therefore use DST_IN.

Applying the mask

Let’s say we have a nice JPEG:

And a PNG that we want to use as a mask:

First, we load the bitmap:

BitmapFactory.Options options = new BitmapFactory.Options();
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
  // Starting with Honeycomb, we can load the bitmap as mutable.
  options.inMutable = true;
}
// We could also use ARGB_4444, but not RGB_565 (we need an alpha layer).
options.inPreferredConfig = Bitmap.Config.ARGB_8888;
Resources res = getResources();
Bitmap source = BitmapFactory.decodeResource(res, R.drawable.golden_gate, options);
Bitmap bitmap;
if (source.isMutable()) {
  bitmap = source;
} else {
  bitmap = source.copy(Bitmap.Config.ARGB_8888, true);
  source.recycle();
}
// The bitmap is opaque, we need to enable alpha compositing.
bitmap.setHasAlpha(true);

Next we draw the mask on the bitmap with a canvas, using the DST_IN Porter-Duff mode:

Canvas canvas = new Canvas(bitmap);
Bitmap mask = BitmapFactory.decodeResource(res, R.drawable.troll_face);
Paint paint = new Paint();
paint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.DST_IN));
canvas.drawBitmap(mask, 0, 0, paint);
// We do not need the mask bitmap anymore.
mask.recycle();

Finally we just use the bitmap:

ImageView trollFace = (ImageView) findViewById(R.id.troll_face);
trollFace.setImageBitmap(bitmap);

Result

There you go, Troll Face Golden Gate!

Here is a helper method to do this all at once:

public static Bitmap getMaskedBitmap(Resources res, int sourceResId, int maskResId) {
  BitmapFactory.Options options = new BitmapFactory.Options();
  if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
    options.inMutable = true;
  }
  options.inPreferredConfig = Bitmap.Config.ARGB_8888;
  Bitmap source = BitmapFactory.decodeResource(res, sourceResId, options);
  Bitmap bitmap;
  if (source.isMutable()) {
    bitmap = source;
  } else {
    bitmap = source.copy(Bitmap.Config.ARGB_8888, true);
    source.recycle();
  }
  bitmap.setHasAlpha(true);
  Canvas canvas = new Canvas(bitmap);
  Bitmap mask = BitmapFactory.decodeResource(res, maskResId);
  Paint paint = new Paint();
  paint.setXfermode(new PorterDuffXfermode(PorterDuff.Mode.DST_IN));
  canvas.drawBitmap(mask, 0, 0, paint);
  mask.recycle();
  return bitmap;
}

Update

If you want to understand Porter-Duff blending modes in details, you should read this great article: Porter/Duff Compositing and Blend Modes (special thanks to Cyril Mottier for the link).

Comments

DreamingInDroids

Brilliant! Thanks for the pictures demonstrating the different Porter-Duff modes! I had been wondering about them for a long time!

Casey

Very useful! I’m writing a children’s puzzle app and this is a quick and easy way to create a base (ie. a square with the puzzle shape cut out of it) for the puzzle with an interesting texture. Thanks =)

Chathead Basics

2013-04-14T00:00:00+00:00

Facebook recently released a new feature in Facebook Messenger: Chatheads.

I was surprised that chatheads could be drawn on top of any app. Here is a quick explanation of how it works.

No Activity?

At first you may think it’s a trick with a transparent activity. Let’s see:

$ adb shell dumpsys activity
Running activities (most recent first):
  TaskRecord{42b03c38 #2 A com.android.launcher U 0}
    Run #0: ActivityRecord{42adf3f8 u0 com.android.launcher/com.android.launcher2.Launcher}

No activity! And that’s because Messenger uses a service:

$ adb shell dumpsys activity services
ACTIVITY MANAGER SERVICES (dumpsys activity services)
* ServiceRecord{43242ae0 u0 com.facebook.orca/.chatheads.ChatHeadService}
  intent={act=com.facebook.orca.chatheads.ACTION_HIDE_CHATHEADS cmp=com.facebook.orca/.chatheads.ChatHeadService}
  packageName=com.facebook.orca
  processName=com.facebook.orca
  baseDir=/data/app/com.facebook.orca-1.apk
  dataDir=/data/data/com.facebook.orca
  app=ProcessRecord{42a11228 32622:com.facebook.orca/u0a10126}
  createTime=-9m19s542ms lastActivity=-3m20s499ms
  executingStart=-3m20s499ms restartTime=-9m19s542ms
  startRequested=true stopIfKilled=false callStart=true lastStartId=65

Principle

It’s simple: just add a view to a Window.

As you probably know, an Activity has a Window instance. Dialogs also have their own dedicated Window. Even Services can have Window: InputMethodService uses a Window to receive touch events and draw a keyboard on top of another Window, and DreamService is used to create screensavers.

Permission

To open a new window in which you will draw the chathead, you need the SYSTEM_ALERT_WINDOW permission.

Allows an application to open windows using the type TYPE_SYSTEM_ALERT, shown on top of all other applications. Very few applications should use this permission; these windows are intended for system-level interaction with the user.

<uses-permission android:name="android.permission.SYSTEM_ALERT_WINDOW"/>

This is what your users will see when installing the app:

Android Head

Now that you have the right permission, you just need to call WindowManager#addView() with the view and the corresponding layout params:

public class ChatHeadService extends Service {

  private WindowManager windowManager;
  private ImageView chatHead;

  @Override public IBinder onBind(Intent intent) {
    // Not used
    return null;
  }

  @Override public void onCreate() {
    super.onCreate();

    windowManager = (WindowManager) getSystemService(WINDOW_SERVICE);

    chatHead = new ImageView(this);
    chatHead.setImageResource(R.drawable.android_head);

    WindowManager.LayoutParams params = new WindowManager.LayoutParams(
        WindowManager.LayoutParams.WRAP_CONTENT,
        WindowManager.LayoutParams.WRAP_CONTENT,
        WindowManager.LayoutParams.TYPE_PHONE,
        WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE,
        PixelFormat.TRANSLUCENT);

    params.gravity = Gravity.TOP | Gravity.LEFT;
    params.x = 0;
    params.y = 100;

    windowManager.addView(chatHead, params);
  }

  @Override
  public void onDestroy() {
    super.onDestroy();
    if (chatHead != null) windowManager.removeView(chatHead);
  }
}

Don’t forget to start the service somehow:

startService(new Intent(context, ChatHeadService.class));

Drag the head

You can now interact with the view. For example, here is a quick hack to drag the Android head around:

chatHead.setOnTouchListener(new View.OnTouchListener() {
  private int initialX;
  private int initialY;
  private float initialTouchX;
  private float initialTouchY;

  @Override public boolean onTouch(View v, MotionEvent event) {
    switch (event.getAction()) {
      case MotionEvent.ACTION_DOWN:
        initialX = params.x;
        initialY = params.y;
        initialTouchX = event.getRawX();
        initialTouchY = event.getRawY();
        return true;
      case MotionEvent.ACTION_UP:
        return true;
      case MotionEvent.ACTION_MOVE:
        params.x = initialX + (int) (event.getRawX() - initialTouchX);
        params.y = initialY + (int) (event.getRawY() - initialTouchY);
        windowManager.updateViewLayout(chatHead, params);
        return true;
    }
    return false;
  }
});

Conclusion

Prior to Facebook Chatheads, this trick was already used by some apps. A few examples:

Display a side app launcher
Take screenshots
Draw notes over apps
Reduce the screen brightness

This feature is nice, but remember that with great power comes great responsibility.

Please take care of your user pixels.

Comments

hidden-markov

Does this imply that Facebook Chatheads (or any application with SYSTEM_ALERT_WINDOW permission) is able to conduct keylogging and take screenshots at arbitrary time?

kvgr

Great tutorial! Is there a way to display image only in launcher? When some activity is started, the icon should disapear. I thing there may be two ways:

parameter for WindowManager
detecting running app But I wasnt lucky to find the solution…

pickledolives

Your tutorial is missing the point, that you need to register your service in the Android manifest file under the application tab.

Android String Placeholders

2013-01-10T00:00:00+00:00

This article reviews different ways to create dynamic translatable strings in Android.

Quick reminder

In Android, message strings are extracted to XML files, and the system loads the resources corresponding to the current configuration.

res/values/strings.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="sexy_button_title">Click me, I'm famous!</string>
</resources>

res/values-fr/strings.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="sexy_button_title">Cliquez-moi, parce que je le vaux bien !</string>
</resources>

Resources resources = context.getResources();
String sexyButtonTitle = resources.getString(R.string.sexy_button_title);

Formatting strings

Let’s say we want to display a dynamic string, such as Player Foo - Score: 42.

We may be tempted to implement that quickly with String.format().

Wrong

<string name="score_format">Player %s - Score: %d</string>

Resources resources = context.getResources();
String scoreString = String.format(resources.getString(R.string.score_format), player, score);

You will get a compile time error message on the <string /> definition.

Error

Multiple substitutions specified in non-positional format; did you mean to add the formatted="false" attribute?

This error message is misleading, because one may believe that using formatted="false" is the way to go.

Still Wrong

<string name="score_format" formatted="false">Player %s - Score: %d</string>

Although the error message now disappears, the real solution is to use a positional format.

Right

<string name="score_format">Player %1$s - Score: %2$d</string>

When translating strings, the word order will change. For instance, Name: John Smith in English becomes Nom : Smith John in French.

Resources resources = context.getResources();
String scoreString = String.format(resources.getString(R.string.name), firstname, lastname);

res/values/strings.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="name">Name: %1$s %2$s</string>
</resources>

res/values-fr/strings.xml

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="name">Nom : %2$s %1$s</string>
</resources>

Using positional format prevents translation mistakes.

getString()

Did you know that instead of String.format(), you can use an overloaded version of getString() that handles formatting?

Resources resources = context.getResources();
String scoreString = resources.getString(R.string.score_format, player, score);

Is that stricly equivalent to the previous code? Let’s look at the Android source!

public class Resources {

    // …

    public String getString(int id, Object... formatArgs) throws NotFoundException {
        String raw = getString(id);
        return String.format(mConfiguration.locale, raw, formatArgs);
    }
}

Almost the same, except that we are using the resource configuration locale, whereas we were previously using the default locale.

public final class String implements Serializable, Comparable<String>, CharSequence {

    // …

    public static String format(String format, Object... args) {
        return format(Locale.getDefault(), format, args);
    }
}

Locale.getDefault() is usually equal to mConfiguration.locale, so this won’t really be a problem until you start messing with the default locale.

By the way, you probably know that getString() is also available on Context.

String scoreString = context.getString(R.string.score_format, player, score);

What’s the difference? None. It just delegates to Resources.

public abstract class Context {

    // …

    public final String getString(int resId, Object... formatArgs) {
        return getResources().getString(resId, formatArgs);
    }
}

If someone knows the story behind this weird shortcut method, let me know. For now, I’ll just assume this is a consequence of Drunk Driven Development.

Professional Translation

Your users deserve better than Google translate. XML resource files should be translated by a professional translator.

This translator will know nothing about your app internals. Therefore, it may be really hard to find out what those %1$s cryptic signs mean.

<string name="score_format">Player %1$s - Score: %2$d</string>

You can use comments to help the translator.

<!-- %1$s is the player nickname and %2$d is the player score -->
<string name="score_format">Player %1$s - Score: %2$d</string>

By the way, if you need excellent quality software translation, I know someone that’s been translating software for more than 25 years. Yes, he is my father :) .

Using placeholders

Another interesting approach is to use named placeholders instead of format specifiers.

I won’t discuss which syntax is better for this kind of problem, let’s just pick a simple one: {placeholder}.

<string name="score_format">Player {nickname} - Score: {score}</string>

I find this much more readable! Now, you’ll need an API to transform that format to the final string.

TagFormat scoreFormat = TagFormat.from(getString(R.string.score_format));
scoreFormat.with("nickname", player);
scoreFormat.with("score", score);
String scoreString = scoreFormat.format();

Implementing this API is fairly straightforward.

public class TagFormat {

	public static TagFormat from(String format) {
		return new TagFormat(format);
	}

	private final String format;
	private final Map<String, Object> tags = new LinkedHashMap<String, Object>();

	private TagFormat(String format) {
		this.format = format;
	}

	public TagFormat with(String key, Object value) {
		tags.put("\\{" + key + "\\}", value);
		return this;
	}

	public String format() {
		String formatted = format;
		for (Entry<String, Object> tag : tags.entrySet()) {
			// bottleneck, creating temporary String objects!
			formatted = formatted.replaceAll(tag.getKey(), tag.getValue().toString());
		}
		return formatted;
	}
}

This is just an example implementation, I’ll leave a better one to you as an exercice. An interesting point here is that with() returns this, so you can use it as a fluid API.

String scoreString = TagFormat.from(getString(R.string.score_format))
  .with("nickname", player)
  .with("score", score)
  .format();

Conclusion

I shamelessly stole this {placeholder} idea from Eric Burke, and thought it was worth sharing.

Of course, you may already use Java libraries that can do this. If you are aware of a good one that does a decent job, let me know!

Comments

Android Adapter Good Practices

2012-12-27T00:00:00+00:00

In Android, the standard way to display a list of items is to use ListView together with a ListAdapter. The ListView draws the currently shown items, and the ListAdapter provides the ListView with the View corresponding to each item.

The aim is to create only the necessary number of views to fill the screen, and reuse these views as soon as they disappear.

This article will explain various ListAdapter patterns and good practices.

ArrayAdapter sucks

Let’s say you want to display a list of BananaPhone that can be updated.

Some Android tutorials advise using an ArrayAdapter, because it is supposedly easier. This couldn’t be any less true.

ArrayAdapter has many limitations, which limits its use in real world apps.

An ArrayAdapter:

Can only display text.
Forces you to provide a list of CharSequence items or to rely on the toString() method of the given items.
Requires that you provide a layout resource that contains only a TextView, or that you provide a textViewResourceId that corresponds to the TextView id in the layout hierarchy.
Uses a lock to enable updates from background threads. This lock cannot be acquired to implement external atomic operations.

According to the Javadoc:

Don’t do this!

To use something other than TextViews for the array display, for instance, ImageViews, or to have some of data besides toString() results fill the views, override getView(int,android.view.View,android.view.ViewGroup) to return the type of view you want.

If you read the source, you’ll realize that ArrayAdapter is designed to deal with a lot of use cases which you probably do not care about.

BaseAdapter rocks

In most apps, it’s actually a lot simpler to implement your own BaseAdapter:

public class BananaPhoneAdapter extends BaseAdapter {

	private List<BananaPhone> bananaPhones = Collections.emptyList();

	private final Context context;

	// the context is needed to inflate views in getView()
	public BananaPhoneAdapter(Context context) {
		this.context = context;
	}

	public void updateBananas(List<BananaPhone> bananaPhones) {
		this.bananaPhones = bananaPhones;
		notifyDataSetChanged();
	}

	@Override
	public int getCount() {
		return bananaPhones.size();
	}

	// getItem(int) in Adapter returns Object but we can override
	// it to BananaPhone thanks to Java return type covariance
	@Override
	public BananaPhone getItem(int position) {
		return bananaPhones.get(position);
	}

	// getItemId() is often useless, I think this should be the default
	// implementation in BaseAdapter
	@Override
	public long getItemId(int position) {
		return position;
	}

	@Override
	public View getView(int position, View convertView, ViewGroup parent) {
      // Let's look at that later
	}

}

Thread safety

I mentioned that the ArrayAdapter uses a lock to ensure thread safety. That’s fine, but there is an even better way: get rid of threading. Make sure your adapter is used only from one thread, the Main thread.

You can easily enforce that with a fail fast strategy:

public void updateBananas(List<BananaPhone> bananaPhones) {
	ThreadPreconditions.checkOnMainThread();
	this.bananaPhones = bananaPhones;
	notifyDataSetChanged();
}

Here is an example implementation:

public class ThreadPreconditions {
	public static void checkOnMainThread() {
		if (BuildConfig.DEBUG) {
			if (Thread.currentThread() != Looper.getMainLooper().getThread()) {
				throw new IllegalStateException("This method should be called from the Main Thread");
			}
		}
	}
}

getView() recycling

A naive implementation of getView() could be:

@Override
public View getView(int position, View convertView, ViewGroup parent) {

	View rootView = LayoutInflater.from(context)
	  .inflate(R.layout.banana_phone, parent, false);

	ImageView bananaView = (ImageView) rootView.findViewById(R.id.banana);
	TextView phoneView = (TextView) rootView.findViewById(R.id.phone);

	BananaPhone bananaPhone = getItem(position);
	phoneView.setText(bananaPhone.getPhone());
	bananaView.setImageResource(bananaPhone.getBanana());

	return rootView;
}

However, ListView recycles the views that are not shown any more, and gives them back through convertView. Let’s take advantage of this:

@Override
public View getView(int position, View convertView, ViewGroup parent) {

	if (convertView == null) {
		convertView = LayoutInflater.from(context)
		  .inflate(R.layout.banana_phone, parent, false);
	}

	ImageView bananaView = (ImageView) convertView.findViewById(R.id.banana);
	TextView phoneView = (TextView) convertView.findViewById(R.id.phone);

	BananaPhone bananaPhone = getItem(position);
	phoneView.setText(bananaPhone.getPhone());
	bananaView.setImageResource(bananaPhone.getBanana());

	return convertView;
}

findViewById() mi amor

There is still one subtle problem with getView(): each time it is called, it retrieves bananaView and phoneView through findViewById().

How does findViewById() work exactly ? Here is a simplified version:

public View findViewById(int id) {
	if (this.id == id) {
		return this;
	}
	for(View child : children) {
		View view = child.findViewById(id);
		if (view != null) {
			return view;
		}
	}
	return null;
}

As you can see, findViewById() navigates through the whole view hierarchy until it finds the requested view, each time you call it.

Whether or not this is a problem is up to you. If your ListView scrolls fine even on crap devices, don’t bother optimizing. Otherwise, start traceview and measure how much time is spent in findViewById().

ViewHolder Pattern

The ViewHolder Pattern is a well known pattern to limit the number of calls to findViewById(). The idea is that you call it once, then store the child view references in a ViewHolder instance that will be associated with the convertView thanks to View.setTag().

private static class ViewHolder {
	public final ImageView bananaView;
	public final TextView phoneView;

	public ViewHolder(ImageView bananaView, TextView phoneView) {
		this.bananaView = bananaView;
		this.phoneView = phoneView;
	}
}

@Override
public View getView(int position, View convertView, ViewGroup parent) {

	ImageView bananaView;
	TextView phoneView;
	if (convertView == null) {
		convertView = LayoutInflater.from(context)
		  .inflate(R.layout.banana_phone, parent, false);
		bananaView = (ImageView) convertView.findViewById(R.id.banana);
		phoneView = (TextView) convertView.findViewById(R.id.phone);
		convertView.setTag(new ViewHolder(bananaView, phoneView));
	} else {
		ViewHolder viewHolder = (ViewHolder) convertView.getTag();
		bananaView = viewHolder.bananaView;
		phoneView = viewHolder.phoneView;
	}

	BananaPhone bananaPhone = getItem(position);
	phoneView.setText(bananaPhone.getPhone());
	bananaView.setImageResource(bananaPhone.getBanana());

	return convertView;
}

Tag with id

Here is an alternative to the ViewHolder Pattern that you can start using with Android 4.0 (API level 15). Do not use it prior to ICS (more on this below).

Since Android 1.6, there is an overloaded version of View.setTag(int, Object) that takes an int key. The key => tag association is stored in a SparseArray that belongs to the view. A key lookup is basically a binary search in an array containing the sorted keys.

By the way, the SparseArray javadoc says that it is intended to be more efficient than using a HashMap to map Integers to Objects. The intent is nice, but that is quite a vague assertion. Is it more efficient in terms of space? runtime? Less GC? Under which conditions? Why does it need key ordering? E.g it could have been a hashtable implementation with int keys.

Notice how we reuse the view ids as tag keys:

@Override
public View getView(int position, View convertView, ViewGroup parent) {

	ImageView bananaView;
	TextView phoneView;
	if (convertView == null) {
		convertView = LayoutInflater.from(context)
		  .inflate(R.layout.banana_phone, parent, false);
		bananaView = (ImageView) convertView.findViewById(R.id.banana);
		phoneView = (TextView) convertView.findViewById(R.id.phone);
		convertView.setTag(R.id.banana, bananaView);
		convertView.setTag(R.id.phone, phoneView);
	} else {
		bananaView = (ImageView) convertView.getTag(R.id.banana);
		phoneView = (TextView) convertView.getTag(R.id.phone);
	}

	BananaPhone bananaPhone = getItem(position);
	phoneView.setText(bananaPhone.getPhone());
	bananaView.setImageResource(bananaPhone.getBanana());

	return convertView;
}

As mentioned before, although the API is available since Android 1.6, you shouldn’t use it prior to Android 4.0, because the implementation wasn’t a per-view SparseArray.

View.setTag(int, Object) clearly wasn’t designed with the ViewHolder Pattern in mind. The key => tag association was stored in a static WeakHashMap using the View object as the key. A WeakHashMap stores weak references to its keys. The idea was that as soon as a view wasn’t referenced anywhere else then in the WeakHashMap, the entry could be garbage collected. However, if the value of a WeakHashMap entry contains a hard reference to its key (the view), it will never be garbage collected, and you’ll get a memory leak. More on this here, also see the issue.

Custom item ViewGroup

There is a third way that provides better decoupling. The idea is to create a custom ViewGroup, e.g. BananaPhoneView, for each item. BananaPhoneView will keep the references to it child views. BananaPhoneView is now responsible for updating bananaView and phoneView.

@Override
public View getView(int position, View convertView, ViewGroup parent) {
	BananaPhoneView bananaPhoneView;
	if (convertView == null) {
		bananaPhoneView = (BananaPhoneView) LayoutInflater.from(context)
		  .inflate(R.layout.banana_phone, parent, false);
	} else {
		bananaPhoneView = (BananaPhoneView) convertView;
	}

	BananaPhone bananaPhone = getItem(position);

	bananaPhoneView.update(bananaPhone);

	return bananaPhoneView;
}

Custom item view

Your performance measurements may tell you that you spend too much time going through the view hierarchy when measuring and drawing. You can flatten your view hierarchy by combining components, or by creating a custom view that draws the whole item manually. That’s how the mail list in Gmail works.

If you haven’t already, take at look at Android Performance Case Study.

Conclusion

Adapters in Android are frightening at first, but when you get to know them, they are actually quite friendly beasts. The best way to get there is to read the Android source, as well as other apps source, such as GitHub Android, White House for Android, or ioshed.

Many thanks to Frank Harper, Eric Bottard and Joan Zapata for reviewing this article.

Update

Benoît Lubek suggested another solution on Google+.

The idea is to reproduce the View.setTag(int, Object) ICS+ behavior as an external API, relying on View.setTag(Object):

public class ViewHolder {
    // I added a generic return type to reduce the casting noise in client code
	@SuppressWarnings("unchecked")
	public static <T extends View> T get(View view, int id) {
		SparseArray<View> viewHolder = (SparseArray<View>) view.getTag();
		if (viewHolder == null) {
			viewHolder = new SparseArray<View>();
			view.setTag(viewHolder);
		}
		View childView = viewHolder.get(id);
		if (childView == null) {
			childView = view.findViewById(id);
			viewHolder.put(id, childView);
		}
		return (T) childView;
	}
}

This solution is elegant, and the code looks even simpler:

@Override
public View getView(int position, View convertView, ViewGroup parent) {

	if (convertView == null) {
		convertView = LayoutInflater.from(context)
		  .inflate(R.layout.banana_phone, parent, false);
	}

	ImageView bananaView = ViewHolder.get(convertView, R.id.banana);
	TextView phoneView = ViewHolder.get(convertView, R.id.phone);

	BananaPhone bananaPhone = getItem(position);
	phoneView.setText(bananaPhone.getPhone());
	bananaView.setImageResource(bananaPhone.getBanana());

	return convertView;
}

I really like this approach!

Comments

hub

You explain a difficult thing in a simple way. Thank you very much.

James

Clear illustration of the choice of different adapters, very practical and very useful! Thanks!

Xiao

I was looking for a way to replace the entire list of items inside an ArrayAdapter without calling clear()/addAll() which generates garbage. This looks like a good solution (referring to the updateBananas() function).

imherolddev

I have done a lot of research, written different adapters, duct taped and glued some together, and now that I come back to revisit ListView, I find your post! I hope to see a comparison between RecylerView and the ViewHolders you have described here. However, the BaseAdapter example has me excited to write my next Adapter, which should be far more complex than what I have done to date… Thank you for your write up here! I will be sure to share with my circles.

robertoallende

Great article, you’ve saved my day. Thank you very much!

Mário Valney

I really loved your article. Great explanation! I confess I started with another approach, but when I read your article I just changed everything because it’s much more elegant!

Happy Birthday AndroidAnnotations!

2012-12-22T00:00:00+00:00

Two years ago, I created AndroidAnnotations.

Lesson n°1: think before writing your first commit message

Time to take a look back at the last two years!

Warning!

This article contains trivia, useless statistics, and too much me and I.
You have been warned.

@Background

I started writing Android apps in 2009. I came from the Java/JEE world, in which you can find tons of frameworks and good practices. Android didn’t feel right: my whole codebase was tied to the Activity class, and I didn’t find the code to be much readable and maintainable.

I wanted to decouple my code components using IoC & Dependency Injection, so I tried a few things:

Spring IoC, which relied on JDK classes not available in Android, and crashed.
Creating the dependency graph manually, in code. Worked great, until the dependency graph became too big and hard to maintain.
Creating a small DI container that didn’t rely on reflection. It wasn’t typesafe though, and it required tons of anonymous classes.

Then I discovered RoboGuice, started using it and contributing. I really liked that you could inject Android specific components such as views and resource. This isn’t really dependency injection, but it still makes your code much more readable. The bad part though was the performance hit on startup, because RoboGuice relied on reflection.

On the 14th of december 2010, Olivier Croisier presented the Annotation Processors at the ParisJUG. A few days later, AndroidAnnotations was born.

The name AndroidAnnotations comes from the AndroidAnnotationProcessor class that handles the annotation processing.

The focus in AndroidAnnotations has never really been about dependency injection, but rather about creating annotations to simplify your code and make your life easier, at compile time. It started with view injection, then event binding (based on GWT @UiHandler), resource injection, simplified threading…

@Timeline

December 2010 First commit
January 2011 First external code contribution
April 2011 Release of the 2.0 version
August 2011 Roy Clarkson mentions AndroidAnnotations on the SpringSource Blog
September 2011 eBusiness Information becomes the official sponsor
October 2011 Matthias Kaeppler mentions AndroidAnnotations at DroidCon London 2011
January 2012 Migration from Google Code to GitHub
April 2012 Talk at Devoxx France
October 2012 Talk at Devoxx

@RandomStats

953 commits and more than 35000 lines of code
124 Pull Requests
15 code contributors
More than 400 apps on Google Play (source)
89 members on the mailing list
36 StackOverflow questions
319 @AndAnnotations followers
355 followers & 419 +1 on Google+
654 stargazers & 101 forks on GitHub

@Future

AndroidAnnotations will continue to concentrate on simplifying your Android code with compile time code generation. I think Android developers should be able to pickup their frameworks of choice and use them all together.

Here is a sample project that uses Dagger for dependency injection, AndroidAnnotations for boilerplate removal, and Otto as an event bus.

Let’s see what happens over the next two years!

Comments

Renaming the Android Manifest package

2012-12-20T00:00:00+00:00

I recently needed to be able to change the package name of an app at build time. This is a common need when you have a paid and a free version of an app. It’s also useful if you want to be able to install multiple versions of an app on your phone, such as a “dev” and a “stable” build.

One way to do it is to transform the whole project as a library project, and then create one final project for each version, that depends on the library project.

Aapt magic

There is another way: aapt has a --rename-manifest-package parameter that rewrites the package name of the binary AndroidManifest.xml file in the final APK.

Here is what aapt help says:

   --rename-manifest-package
       Rewrite the manifest so that its package name is the package name
       given here.  Relative class names (for example .Foo) will be
       changed to absolute names with the old package so that the code
       does not need to change.

The great advantage is that your code won’t change, the R class stays identical.

Ant

Since r17, this option is available in the aapt Ant task, through the manifestpackage attribute. You’ll need to override the -package-resources target, copied from the SDK build.xml:

<target name="-package-resources" depends="-crunch">
  <do-only-if-not-library elseText="Library project: do not package resources..." >
    <aapt executable="${aapt}"
     manifestpackage="com.my.package"
    >
...
    </aapt>
  </do-only-if-not-library>
</target>

Maven

The android:apk goal of the android-maven-plugin has a renameManifestPackage parameter.

One last thing

If you load some resource ids at runtime, you may need to update your code.

I used to do this:

String packageName = context.getPackageName();
Resources res = context.getResources();
int id = res.getIdentifier("my_drawable", "drawable", packageName);

This usually works great, especially in library projects where you do not know the package name.

However, the problem here is that the resources were processed before the package name was finally updated. So packageName is wrong.

It’s easy to fix though, by retrieving the package name of another resource with Resources.getResourcePackageName().

Let’s create a resource id dedicated to that purpose, for example in res/values/ids.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources xmlns:android="http://schemas.android.com/apk/res/android">
    <item name="used_for_package_name_retrieval" type="id"/>
</resources>

And now we get the right package:

Resources res = context.getResources();
String packageName = res.getResourcePackageName(R.id.used_for_package_name_retrieval);
int id = res.getIdentifier("some_drawable", "drawable", packageName);

Conclusion

This tip helps creating different versions of the same app.

As you can see on this screenshot, the package name can then be set as a build parameter, to create parameterized builds in Jenkins.

Comments

Blog meets Monster Octocat

2012-12-19T00:00:00+00:00

I initially created this blog on Wordpress.com, mostly because I didn’t want to invest any time in maintaining it.

I’ve been using GitHub and Markdown on an everyday basis ever since. I got bored of Wordpress, therefore I decided to migrate this blog to Jekyll, using the built-in GitHub support.

This means I can write my articles in Markdown with Mou, and just commit and push to publish an article.

Even better, anyone can now improve this article with a pull request. I really like this!

Jekyll generates static html pages. What about comments? Most Jekyll hosted blogs use external javascript services to dynamically include comments at the end of their blog posts. This doesn’t feel right to me, because I think comments ought to be part of the content they are linked to.

That’s why comments are now part of the source of the post. All you need to do is click here, edit the post on GitHub and add your comments at the end.

## [Piwaï](http://piwai.info)
Hello!

Let’s see if that’s something you are able to do ;-) .

By the way, I also started writing in English, trying to reach a broader audience and practice my writing. Let me know if you find weird french looking sentences.

Comments

gnupat

Great idea, I can’t wait to see how the PR driven comments are going :D .

By the way, am I doing this right?

Aurélien

It’s turtles all the way down ! And the comment button is displayed twice at the end of your post.

Piwaï

Turns out, all comments pull request are located at the same position so this leads to merge conflicts (easy to fix though). Comments is displayed twice on purpose, as you can see now that there are actual comments. Maybe I should remove the first one.

Paris Android Dev Lab

2011-11-06T20:03:59+00:00

Introduction

Un Android Developer Labs (ADL) s’est déroulé à Paris jeudi 27 et vendredi 28 octobre 2011, traitant de l’optimisation des applications Android pour les tablettes.

J’ai eu la chance d’être invité à cet évènement ; j’en ai donc profité pour prendre des notes afin de pouvoir retranscrire le déroulement de cette journée (l’ADL du vendredi).

Apéro Android

Avant tout, laissez-moi vous parler de l’apéro Android. Sachant que les places pour l’ADL étaient limitées, le Paris Android User Group (PAUG) a organisé un apéro Android le jeudi soir, pour permettre à tous de discuter et de rencontrer les Android Developer Advocates.

Les Googlers sont très ouverts et abordables, et nous avons passé une soirée sympatique, en partie aux frais de FrAndroid. Je vous conseille vivement ce type de rencontre ; c’est un bon moyen d’apprendre et de rencontrer des gens intéressants tout en passant un bon moment.

Au cours de la soirée, j’ai eu le plaisir de constater que deux Android Developer Advocates (Nick Butcher et Richard Hyndman) connaissaient AndroidAnnotations, suite au talk de Matthias Kaeppler à la DroidCon 2011.

L’ADL

Le programme de la journée était le suivant :

Introduction aux tablettes
Quoi de neuf dans Ice Cream Sandwich
Android Market pour développeurs
Développer pour téléphones et tablettes
Codelab

J’ai pris des notes du mieux possible ; j’espère que vous me saurez gré des lacunes éventuelles et de la faible mise en forme.

Introduction aux tablettes

Cette présentation fut consacrée aux spécificités liées à Honeycomb et au développement pour tablettes.

Notez qu’Honeycomb est uniquement orienté tablette : l’équipe Android n’avait pas le temps de réaliser un OS pour téléphones en parallèle.

System bar

Auparavant, les informations système et les notifications étaient situées dans une barre en haut de l’écran.

Désormais, cette barre se situe en bas de l’écran, et contient en outre les boutons de navigation. Cela permet de se débarrasser des boutons physiques, qui étaient mal placés lorsque l’on passait en mode paysage.

Les notifications sont désormais accessibles sans couvrir totalement l’écran, de même qu’un certain nombre de réglages et informations bien pratiques.

Cette barre peut distraire l’attention visuelle lorsque vous souhaitez une expérience immersive. Il est possible de la cacher en utilisant le code suivant :

mView.setSystemUiVisibility(View.STATUS_BAR_HIDDEN)

Note : je me demande bien pourquoi cette méthode n’est pas statique et appartient à View ; si vous avez une idée, n’hésitez pas à commenter.

Dans le screenshot suivant, comme vous le voyez, la barre ne disparaît pas totalement. Elle devient noire, mais les icônes sont remplacés par des points gris toujours cliquables.

Note : ce screenshot montre le dernier niveau de Wind-up Knight, un jeu sympa qui est un bon exemple de l’efficacité du paiement in-app (la preuve, je n’ai pas résisté et ce fût l’occasion de réaliser mon premier paiement in-app).

Action bar

Vous souvenez-vous d’Android 1.X, où la barre de titre occupait une place énorme qui ne servait à rien ?

Autant utiliser cet espace !

C’est le principe de l’action bar. Celle-ci comporte tout d’abord une icône cliquable qui permet de retourner à tout moment à l’écran d’accueil.Elle affiche ensuite des éléments liés à la navigation, et pour finir des icônes d’action.

Cette action bar n’est pas nécessairement un composant Android, il s’agit plutôt d’un design pattern de UI, que toute application Android digne de ce nom devrait respecter.

Le projet ActionBarCompat, disponible dans les samples depuis ADT 14, met à disposition tout le code et les ressources nécessaires à la création d’une action bar fonctionnant sur toutes les versions d’Android.

ActionBarCompat sur mon Nexus One (Gingerbread)

Les menu items dans l’Options Menu peuvent être rendus disponibles dans les boutons d’action. Il suffit juste d’ajouter l’attribut suivant aux items dans votre menu.xml :

    android:showAsAction="ifRoom|withText";

Les fragments

Sans trop rentrer dans les détails : les fragments sont des composants de UI, réutilisables. L’utilisation de Fragment permet de repenser la UI, il ne suffit plus de se contenter d’avoir un design fluide qui s’élargit par rapport à la taille de l’écran, il faut organiser les fragments différents suivant l’écran et la place disponible.

Pour être tout à fait honnête, je ne suis qu’à moitié convaincu par ce nouveau système de fragment. Le principe reste proche de celui des activités : il s’agit d’un controller, chargé d’orchestrer le code métier lié à un assemblage de composants graphiques (des View).

En soit, ce n’est pas une mauvaise idée. Par contre, on se retrouve encore avec un modèle par héritage, comme pour les activités. Tout fragment doit hériter de Fragment. Il existe un ListFragment, un XXXFragment, etc, qui tous héritent de Fragment.

Le problème, c’est que dès lors que l’on souhaite factoriser du code commun à plusieurs Fragments, il va falloir recréer une sous classe pour chacun des types de Fragment. AbstractCustomFragment, AbstractCustomListFragment, etc. Et évidemment, si deux frameworks s’amusent à créer leurs propres fragments à étendre, il devient compliqué de les combiner.

Pour faire un parallèle, j’ai l’impression que l’équipe Android persiste à proposer des servlets, quand il serait bien plus utile de proposer des controllers Spring.

A bien y réfléchir, une Activity et un Fragment ont ceci de commun qu’ils répondent à des évènements (principe des callbacks type onCreate()), qu’ils renvoient des éléments de configuration (e.g. getLastNonConfigurationInstance()), et qu’ils fournissent des helpers (getLoaderManager(), getPreferences(), etc).

Pour moi, ces différentes responsabilités devraient appartenir à différents composants.

Les Loaders

Les Loaders sont un nouveau moyen pour récupérer des données en tâche de fond, en gérant convenablement les problématiques liées au cycle de vie des composants Android.

Samsung loader, by A1C Beatrice Cassetty, U.S. Air Force (public domain)

C’est une alternative très intéressante à l’AsyncTask, qui malgré plusieurs bonnes idées souffre de quelques problèmes :

Pas de gestion du cycle de vie (activité mise en pause, détruite définitivement, détruite mais pour raison de changement de configuration, etc)
Pas facile à utiliser : le paramètre générique PARAM n’est pas vraiment utile (en plus, c’est une vararg, quelle horreur !), il n’y a pas de gestion des exceptions.

A noter qu’un des premiers risques avec les AsyncTask, c’est d’en faire des classes anonymes et de leaker des références vers leur outer class, qui est bien souvent une activité.

Et pour simplifier votre code de gestion des Threads sur Android, pourquoi ne pas essayer @Background et @UiThread sur AndroidAnnotations ?

hardwareAccelerated

Pensez à activer le flag suivant dans votre manifest :

android:hardwareAccelerated="true"

Cela permet de bénéficier de l’accélération matérielle pour le rendering, gratos. Il est désactivé par défaut car certaines implémentations dessinant via des canvas peuvent ralentir ou faire crasher votre appli.

Ce n’est normalement pas le cas des composants standards. Comment décider s’il faut l’utiliser ? C’est simple :

Activez hardwareAccelerated
Testez votre application sur Honeycomb. Si elle ne plante pas, c’est bon, vous pouvez dormir tranquille!

Renderscript

Renderscript est une nouvelle API C permettant de faire du 3D rendering haute performance. Nouvelle… pas tant que ça! Si j’ai bonne mémoire, Romain Guy nous présentait déjà Renderscript au précédent Android Dev Lab, il y a de cela deux ans. Bon, il est vrai que l’API n’a probablement plus rien à voir (initialement, ça n’était même pas du C), seul le concept reste identique.

Les applications Google Books et YouTube utilisent renderscript : Google Books pour tourner les pages, et YouTube pour l’écran avec toutes les vidéos visibles en même temps.

Développement pour tablettes, quelques règles simples

Mesurer en dp plutôt qu’en pixels
Utiliser des layouts extensibles
Centraliser les dimensions dans dimens.xml, de façon à pouvoir les overrider grâce au mécanisme de ressources
Supporter le mode paysage et ne pas bloquer en mode portrait. N’oubliez pas que la manière d’utiliser une tablette est essentiellement en paysage. Beaucoup d’application ont un écran de chargement de l’application en portrait, ce n’est pas très malin !

Mettre à jour votre application pour Honeycomb

Ajoutez des graphiques pour les hautes résolutions (xhdpi)
Utilisez des fragments, même pour les anciennes versions d’Android (grâce à la compatibility library)
N’oubliez pas d’ajouter <uses-sdk android:targetSdkVersion="14" /> dans votre manifest, notamment pour bénéficier automatique de la nouvelle Action bar sur Honeycomb

Voilà qui conclu la première moitié de ce compte rendu sur l’Android Dev Lab, je vous conterai la fin de cette journée lors du prochain article.

Edit: en fait, il n’y a jamais eu de prochain article :)

Comments

Frank Harper (@franklinharper)

Tout à fait d’accord quand tu soulignes la pénibilité de sous classer chacun des types de Fragment/Activity! J’espérais qu’une solution plus élégante allait apparaître avec Android 4.0.

Pour activer l’Action bar un targetSdkVersion=”11″ devrait suffire; mais si on peut tester avec ICS pourquoi pas aller directement en targetSdkVersion=”14″!

Coup de balai : déblayer les branches d'un repo Git

2011-10-30T23:30:34+00:00

Comme je vous l’indiquais dans un précédent article, chez Siine, nous hébergeons nos projets sur GitHub, et chaque User Story fait l’objet d’une branche dédiée.

Lorsqu’une branche qui a fait l’objet d’une pull request est validée, elle est mergée sur la branche d’intégration. Nous n’avons cependant pas pris l’habitude de supprimer ces branches une fois mergées. Je pense que nous aurions probablement du les supprimer au fur et à mesure, car nous nous retrouvons aujourd’hui avec de nombreuses branches mergées, qui ne servent à rien et qui polluent nos repository.

Branches konary by Krzysztof

Notez que GitHub conserve l’historique des pull request même quand les branches sont supprimées. Je ne vois vraiment aucune raison de conserver des branches mergées. Et vous ?

Quoi qu’il en soit, il est tout à fait possible de corriger cela, en quelques commandes Git bien senties.

On récupère toutes les données du repository remote

git fetch --all

On supprime de notre repository local toutes les branches remote qui n’existent plus

git remote prune origin

Valor prune by Glysiak

On compte toutes les **branches remote mergées **:

git branch -r --merged origin/integration | wc -l

Le paramètre -r signifie remote, et --merged origin/integration permet de lister les branches mergées dans origin/integration.

Vous l’aurez noté, wc -l est une commande Unix permettant de compter le nombre de lignes du flux d’entrée. Ainsi, on pourrait l’utiliser pour compter le nombre de branches du repository remote :

git branch -r | wc -l

Il n’y a plus qu’à supprimer les branches mergées :

# Supprimer la branche sur le remote
git push origin :my_branch
# Et supprimer la branche qui la track en local
git branch -d my_branch

Notez aussi que GitHub met à disposition ce listing sans avoir à entrer une seule ligne de commande, en cliquant sur Branches.

Pour finir : si lister les branches mergées permet de faire le ménage, à l’inverse il peut être intéressant de prendre connaissance des branches non mergées, car il se peut que certaines d’entre elles aient été oubliées et soient à l’abandon. Pour cela, rien de plus simple :

git branch -r --no-merged origin/integration

Comments

Dvins

Salut Piwai ! Cet historique des branches supprimées est-il propre à Github ou est-ce inclus de base dans Git ? J’utilise Git depuis peu (ASI = SVN comme tu le sais) et je commence en effet à me retrouver avec un tas de branches mergées qui polluent le dépôt ! Merci d’avance !

Piwaï

Salut Dvins!

Github conserve l’historique des “pull request”, pas des “branches supprimées”. Il n’y a pas de notion “d’historique des branches supprimées” dans git. Les branches, tout comme les tags, sont de simples marqueurs sur un graphe, qui identifient des commits particuliers.

Supprimer une branche, c’est supprimer un marqueur, ni plus ni moins .

Par ailleurs, effectivement, les commandes que je donne ici sont des commandes Git, et donc fonctionnent sur n’importe quel repo git.

Sexy dialogs, huhu

2011-10-23T20:58:00+00:00

Introduction

On reproche souvent aux applications Android d’être… moches. Et ce serait la faute du framework Android, qui fournirait des composants qui n’ont pas la Apple sexy touch. Peut-être est-ce le cas, mais faudrait voir à ne pas être trop paresseux.

Prenons le cas des boîtes de dialogue. A priori, il n’y a rien de plus ennuyeux, et rien ne ressemble plus à une boîte de dialogue… qu’une autre boîte de dialogue. Sauf si vous décidez de changer leur style graphique, ce qui risque d’une part de perdre vos utilisateurs, et d’autre part de vous demander du boulot.

Je vous propose d’aborder quelques techniques simples pour donner un peu de vie à vos boîtes de dialogues, sans trop vous fatiguer.

Dialogue fadasse

Voici un exemple classique de boîte de dialogue :

new AlertDialog.Builder(this)
		.setMessage("Un message pas sexy")
		.setPositiveButton(android.R.string.ok, new DialogInterface.OnClickListener() {
			public void onClick(DialogInterface dialog, int which) {
				// Do something
			}
		})
		.show();

Je préfère créer et gérer manuellement mes boîtes de dialogue plutôt qu’utiliser showDialog() et onCreateDialog(), que je n’ai jamais réussi à utiliser correctement dès que les cas d’utilisation se corsent.

Une vue custom

Je vous propose de personnaliser le message affiché par notre boîte de dialogue. Plutôt que setMessage(), il suffit d’appeller setView(), qui prend en paramètre n’importe quel type de View.

Par exemple une TextView, définie ici dans un layout :

<?xml version="1.0" encoding="utf-8"?>
<TextView
    xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="fill_parent" 
    android:layout_height="wrap_content" 
    android:textSize="30sp"
    android:padding="20dp"
    />

Petit rappel, vos layouts xml n’ont aucune raison de commencer systématiquement par un LinearLayout ou un RelativeLayout.

Ensuite, il suffit de gonfler (inflate ;)) ce layout, et de le définir comme vue de la boîte de dialogue :

TextView messageView = (TextView) View.inflate(this, R.layout.dialog, null);
messageView.setText("Un message à peine plus sexy");

new AlertDialog.Builder(this) //
		.setView(messageView) //
		.setPositiveButton(android.R.string.ok, new DialogInterface.OnClickListener() {
			@Override
			public void onClick(DialogInterface dialog, int which) {
				// Do something
			}
		}) //
		.show();

Notez l’utilisation de View.inflate(), plutôt que LayoutInflater.from(context).inflate(), ou encore pire, ((LayoutInflater)context.getSystemService(Context.LAYOUT_INFLATER_SERVICE)).inflate()

Et voilà le travail :

Un peu de style

Dans un précédent article, nous avons découvert Html.fromHtml() qui se marie très bien avec une TextView. Mettons-le à profit :

TextView messageView = (TextView) View.inflate(this, R.layout.dialog, null);
CharSequence message = Html.fromHtml("I like <b>sexy</b> <font color=\"#42dd42\">turtles</font>!");
messageView.setText(message);

Évidemment, c’est mieux avec l’i18n, ajoutons donc une entrée à strings.xml :

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!-- ... -->
    <string name="dialog_message"><![CDATA[I like <b>sexy</b> <font color="#42dd42">turtles</font>!"]]></string>
</resources>

Et notre code devient :

CharSequence message = Html.fromHtml(getString(R.string.dialog_message));

Et avec une photo sexy ?

Saviez-vous que Html.fromHtml() supporte la balise img, et permet de charger des images locales, grâce à un ImageGetter ?

Ajoutons une image à notre message :

<?xml version="1.0" encoding="utf-8"?>
<resources>
    <!-- ... -->
    <string name="dialog_message"><![CDATA[I like <img src="turtle" /> <b>sexy</b> <font color=\"#42dd42\">turtles</font>!"]]></string>
</resources>

Ainsi que la ressource correspondante :

Il n’y a plus qu’à créer un ImageGetter qui sait charger un Drawable à partir de son nom de ressource :

ImageGetter imageGetter = new ImageGetter() {
	@Override
	public Drawable getDrawable(String source) {
		String name = source.replace("/", "");
		Resources resources = getResources();
		int drawableId = resources.getIdentifier(name, "drawable", getPackageName());
		if (drawableId != 0) {
			Drawable drawable = resources.getDrawable(drawableId);
			drawable.setBounds(0, 0, drawable.getIntrinsicWidth(), drawable.getIntrinsicHeight());
			return drawable;
		} else {
			return null;
		}
	}
};

CharSequence message = Html.fromHtml(getString(R.string.dialog_message), imageGetter, null);

Et le tour est joué :

turtle’s head by Betta.1

Conclusion

Ces quelques lignes de code permettent de rapidement mettre en avant les informations importantes au sein d’une boîte de dialogue, sans pour autant déstabiliser l’utilisateur.

Bien entendu, l’abus de boîte de dialogues est dangereux pour la santé mentale des utilisateurs, à afficher avec modération !

Comments

T'as mis à jour les specs ?

2011-10-14T20:49:18+00:00

Introduction

Il est généralement admis qu’utiliser un système de gestion de version (décentralisé de préférence) pour le code d’un projet est une bonne chose.

Mais qu’en est-il des documents de spécifications fonctionnelles et techniques ? Loin de l’approche monolithique du cycle en V, les adeptes des méthodes agiles ont à coeur de faire évoluer ces documents très fréquemment. D’aucuns pourraient penser que les posts-it de Scrum remplacent avantageusement tout document de spécification…

Archaeological post-it label by Evelyn Simak

Versionner les spécifications

N’oubliez pas, être agile ne constitue pas une excuse pour ne pas écrire de documentation. Pareil pour le design émergeant. Bien au contraire, il est d’autant plus important de consigner et conserver le savoir fonctionnel et technique.

Steacie Science and Engineering Library at York University, by Raysonho@Open Grid Scheduler

Vous qui posez un tag sur votre code dans votre système de gestion de version (VCS) lors d’une nouvelle release, êtes-vous capables de retrouver plus tard les spécifications fonctionnelles et techniques correspondant à cette release ?

Un moyen simple pour y parvenir est d’héberger ces documents dans le même VCS que le code. Ainsi, tout tag/branche contiendra automatiquement la bonne version des spécifications.

Diff de specs ?

Allons plus loin : un VCS n’a pas pour seul but de conserver l’historique d’un projet ; il permet aussi d’appréhender les changements réalisés, grâce aux outils de diff. C’est évidemment essentiel pour assembler le travail parallèle des différents développeurs, pour comprendre l’origine d’un bug, pour toute revue de code, etc.

Le problème des outils de diff est qu’ils fonctionnent très bien pour tout ce qui est textuel, et beaucoup moins bien lorsqu’ils ont affaire à des fichiers binaires. Malheureusement, les documents de spécifications sont bien souvent des fichiers Word ou LibreOffice, qui entrent dans cette catégorie.

Il existe pourtant un format textuel tout à fait adapté: Markdown. La syntaxe de ce langage est réellement accessible, même pour les membres non techniques de votre équipe :

# Titre du document
## Mon sous titre

Un paragraphe contenant un [lien absolu](http://www.google.com), un
[lien relatif](../autrePage), et une ![image](image.png).

* une liste à puces
* avec une sous liste
  * contenant un élément *en italique*
  * et un élément **en gras**

De plus, les documents Markdown peuvent aisément être visualisés en HTML ou PDF, si vous ne disposez pas d’un éditeur dédié. Il existe même des scripts pour convertir de l’ODT en Markdown.

Bref, vous n’avez aucune excuse valable ;-).

Retour d’expérience

Chez Siine, nous hébergeons nos projets sur GitHub, et chaque User Story fait l’objet d’une branche dédiée.

Les spécifications fonctionnelles et techniques relatives à une User Story sont écrites en Markdown, sur la branche dédiée à cette User Story.

Lorsque la User Story est prête à être intégrée sur la branche de développement, le développeur crée une pull request. Il suffit alors d’ouvrir l’onglet Diff de la pull request pour tout de suite identifier les changements fonctionnels et techniques introduits par cette User Story.

Diagrammes

Tous les fichiers binaires ne peuvent pas forcément être remplacés par des fichiers textuels ; c’est le cas des diagrammes techniques.

A moins que… en êtes-vous si sûr ?

websequencediagrams.com et yuml.me vous proposent d’exprimer le contenu de vos diagrammes sous forme de texte, et se chargent de générer l’image correspondante.

websequencediagrams

websequencediagrams permet de générer des diagrammes de séquence, et offre même le luxe de choisir le style utilisé.

UI->StuffManager: doSomeStuff()
note over StuffManager: HandlesStuff
activate StuffManager
StuffManager->DataStore:gimmeDaStuff()
activate DataStore
DataStore->StuffManager:
deactivate DataStore
StuffManager->DataStore:updateDaStuff()
activate DataStore
DataStore->StuffManager:
deactivate DataStore
StuffManager-->UI:
deactivate StuffManager

yUML

yUML permet de générer des diagrammes UML de classe, d’activité, et de cas d’utilisation.

[Activity]^[MyActivity]
[MyActivity]-[note: I like turtles!]
[Step]^[FirstStep]
[Step]^[SecondStep]
[Step]^[FinalStep]
[MyActivity]++->[StateHolder]
[MyActivity]++-*>[Step]
[FirstStep]+->[StateHolder]
[SecondStep]+->[StateHolder]

Connaissez-vous d’autres outils bien pratiques de ce type ?

Comments

Maxime Sinclair

Tout à fait en ligne avec ton article. Ce qu’il faut versionner, c’est le produit logiciel. Et le logiciel ce n’est pas juste du code, c’est aussi l’ensemble de la documentation associée (spécification, cahier de tests, manuel utilisateur,…).

Pour la documentation, il faut savoir que Word propose un mode différentiel où il affiche les différences sous la forme de marques de révision. Je me souviens que ceci marchait très bien avec TortoiseSVN. En ce qui concerne les diagrammes, il y a PlantUML qui supporte tous les diagrammes UML mais aussi les diagrammes Ditaa, qui est aussi disponible en mode cloud et, ce qui ne gâte rien, qui est open source. Allez, un petit sudoku pour conclure.

Piwaï

Merci Maxime pour le complément d’info, je ne connaissais pas ces deux derniers !

Roooh, j'ai encore oublié ma branche Git !

2011-10-09T08:15:31+00:00

Introduction

La startup pour laquelle je bosse depuis peu héberge son code source sur GitHub, et ça, c’est carrément cool.

En plus, nous sommes récemment passé d’un workflow old school (tout le monde commit comme des sauvages sur la même branche) à un workflow de type feature branching. Encore plus cool !

Le merge d’une feature branch sur la branche d’intégration ne se fait qu’après validation (revue de code et tests fonctionnels) par quelqu’un qui n’a pas développé la feature. Dans cette optique, les pull requests de GitHub se révèlent particulièrement pratiques.

Mais trêve de bavardage, venons-en à l’objet de cet article.

Roooh, j’ai encore oublié ma branche Git !

Avec le feature branching, on se retrouve à changer fréquemment de branche.

Du coup, j’ai tendance à ne plus savoir sur quelle branche je me trouve, ou encore à oublier le nom précis de la branche, et à taper git branch toutes les trois commandes.

Un membre de l’équipe nous a envoyé un script plutôt pratique, qui ajoute le nom de la branche en cours au prompt de votre terminal :

Le petit truc cool en plus, c’est que le nom s’affiche en rouge si vous avez des modifications locales (dirty working tree), et en vert dans le cas contraire.

Instructions à ajouter à votre fichier ~/.bashrc (ou ~/.profile sur Mac) :

# git branch name in prompt
c_red=`tput setaf 1`
c_green=`tput setaf 2`
c_sgr0=`tput sgr0`

parse_git_branch () {
  if git rev-parse --git-dir >/dev/null 2>&1
  then
          gitver=$(git branch 2>/dev/null| sed -n '/^\*/s/^\* //p')
  else
          return 0
  fi
  echo -e "($gitver) "
}

branch_color () {
        if git rev-parse --git-dir >/dev/null 2>&1
        then
                color=""
                if git diff --quiet 2>/dev/null >&2
                then
                        color="${c_green}"
                else
                        color=${c_red}
                fi
        else
                return 0
        fi
        echo -ne $color
}

PS1="\[\$(branch_color)\]\$(parse_git_branch)\[$(tput sgr0)\]$PS1"

Dans le même ordre d’idée, voici un article bien pratique pour disposer de l’autocomplétion des noms de branches.

À vous, partagez vos astuces ;-) !

Comments

Olivier Bazoud

Je préfère utiliser celui ci livré par Git, utiliser la variable __git_ps1 et en plus ça gère beaucoup plus de cas (modifications locales, fichier non trackes, stash, uptream, commit locaux, commits remote, …)

Dans mon ~/.bashrc:

if [ -f /etc/bash_completion.d/git ]; then
    . /etc/bash_completion.d/git
fi
GIT_PS1_SHOWDIRTYSTATE=true
GIT_PS1_SHOWSTASHSTATE=true
GIT_PS1_SHOWUNTRACKEDFILES=true
GIT_PS1_SHOWUPSTREAM="verbose"

PS1='\A [${debian_chroot:+($debian_chroot)}\[33[01;32m\]\u@\[33[0;33m\]\h\[33[00m\]]\[33[01;31m\]$(__git_ps1)\[33[00m\]% '

@obazoud

Piwaï

Merci Olivier, j’avais découvert bash_completion.d dans l’article cité plus haut, mais je n’avais pas testé la partie modification du PS1.

Je m’en vais essayer ça de ce pas !

PS : je me suis permis d’ajouter la coloration syntaxique à ton commentaire ;).

Sam Bessalah (@samklr)

Ou bien tu peux utiliser oh-my-zsh, qui prend en compte git nativement et t’averti dans quelle branche tu te trouves, etc .. En tout cas impossible d’utiliser le shell sans, pour moi.

Piwaï

@Olivier : après avoir testé, c’est effectivement pas mal mais il manque la couleur :).

@Sam : depuis le temps qu’un de mes potes me bassine avec ZSH, je crois que c’est l’occasion de tester :).

Sam Bessalah (@samklr)

Tu devrais, j’étais dubitatif moi aussi, mais là côté productivité on fais pas mieux. :)

Piwaï

Merci Sam, ça fait à peine 40 minutes, je sais que j’ai déjà switché définitivement vers ZSH :). oh-my-zsh est magique, et les themes dispos sont bien sympas :).

hugoch

Ah c’est assez niquel ! Merci pour l’astuce. A quand un article sur zsh du coup ?!

Piwaï

Oh, pas vraiment besoin d’un article, en gros ça marche comme bash mais en mieux, et il suffit de suivre les instructions du lien donné par @samklr pour démarrer ;).

Un peu de style dans la TextView

2011-10-01T11:00:41+00:00

Les designers qui définissent les écrans de votre application Android se sont fait plaisir, et vous ont demandé une mise en forme bien chiadée pour les textes de votre application.

Avant de vous jeter sur Photoshop pour créer des images correspondant au pixel près à ce qu’ils attendent, pourquoi ne pas garder votre bonne vieille TextView ?

Pour changer un peu des récents articles sur GWT, voici quelques petites astuces pour Android.

Tweak la police

Par défaut, Android ne propose que trois polices de caractères pour les TextView : monospace, sans et serif.

Toutefois, il est tout à fait possible d’utiliser votre police préférée, à condition de l’embarquer dans votre application.

Il suffit de copier la police dans le répertoire assets de votre projet Android, puis de la charger au Runtime :

@Override
protected void onCreate(Bundle savedInstanceState) {.
  super.onCreate(savedInstanceState);

  setContentView(R.layout.main);
  TextView myTextView = (TextView) findViewById(R.id.myTextView);

  Typeface myFont = Typeface.createFromAsset(getAssets(), "MyFont.otf");
  myTextView.setTypeface(myFont);
}

Il n’est pas possible de le faire directement dans votre fichier de layout, sauf en créant des composants alternatifs.

Stylé !

Votre texte doit comporter des morceaux en couleur, en italique… ; bref, il doit être mis en forme.

Avant d’envisager la création d’une TextView pour chaque morceau de texte différent, jetez un oeil à Spannable, et surtout à son cousin germain Html.

Html.fromHtml() retourne un Spanned, qui peut être utilisé pour définir le contenu d’une TextView.

Par exemple :

Spanned spanned = Html.fromHtml("Hello <b>World</b>!")
myTextView.setText(spanned);

Bien entendu, une String en dur dans le code, c’est moche (pas très i18n).

Pour y remédier, il suffit d’encadrer dans un CDATA le texte contenant le markup Html, au sein de vos fichiers de ressources.

Exemple de res/values/strings.xml :

<?xml version="1.0" encoding="utf-8"?>
<resources>
  <string name="styled_content"><![CDATA[I like turtles!<br />Hello <font color="#99cc33"><b>World</b></font>!]]></string>
</resources>

Malheureusement, vous ne pouvez pas utiliser ces ressources directement dans vos fichiers de layout ; il faut en passer par du code Java :

@Override
protected void onCreate(Bundle savedInstanceState) {.
  super.onCreate(savedInstanceState);

  setContentView(R.layout.main);
  TextView myTextView = (TextView) findViewById(R.id.myTextView);

  myTextView.setText(Html.fromHtml(getString(R.string.styled_content)));
}

Notez que le support du HTML reste limité (nombre de balises supportées, HTML mal formé, balises les unes dans les autres…)

Bonus

Linkify permet de créer des TextViews contenant des liens cliquables de toute sorte. A ce sujet, je vous recommande l’excellent article disponible sur la doc Android.
Quels liens entre design Web et design Android ? Un article tout récent sur le blog Android aborde le sujet.

Comments

Quand mamie craque du Wifi

2011-09-23T00:35:02+00:00

Imaginons que vous ayez besoin de craquer le mot de passe de votre propre réseau Wifi, protégé par une clé WEP. Je parle bien de votre propre réseau Wifi, car je suis sûr qu’il ne vous viendrait jamais à l’idée de craquer l’accès de votre voisin, sachant que c’est totalement illégal.

Craquer une clé WEP peut être l’affaire de quelques minutes, et pourtant, aujourd’hui encore, de très nombreux réseaux Wifi de particuliers sont protégés par WEP. Même le New York Times en parle. Faites passer le mot, il faut que cela change.

Les techniques pour y parvenir se sont considérablement améliorées ces dernières années. Parallèlement à ces techniques, c’est aussi leur facilité de mise en œuvre qui a formidablement évolué.

Aujourd’hui, quelques clics suffisent : même mamie peut craquer du Wifi, et c’est l’objet de cet article.

Mise en place

Matos

En termes de matériel, une carte Wifi suffit. La plupart des cartes conviennent et disposent aujourd’hui de drivers adaptés.

Vous obtiendrez de très bons résultats avec l’Alfa AWUS036H, a priori la carte la plus puissante du marché (1000mW). Attention par contre, il me semble qu’elle est interdite à la vente en France, effet micro onde garanti ;-).

OS

Les drivers patchés pour le crack Wifi sont essentiellement disponibles sous Linux. Plus précisément, la distribution Backtrack contient tout le nécessaire. Elle est disponible en Live CD et en Live USB.

Version mamie : vous trouvez une clé USB avec quelques gigas de libres ; vous suivez ce tutoriel ; vous branchez la clé USB ; et vous redémarrez pour booter sur la clé USB (cf. ce tutoriel > Modifier l’ordre de boot).

Backtrack démarre, se logue tout seul, et présente une ligne de commande une fois démarré.

Il suffit de taper startx pour lancer l’environnement graphique.

root@root:~# startx

Notez que le layout de clavier étant par défaut un qwerty, il vous faudra probablement taper stqrtx.

Une fois l’environnement graphique démarré, vous pouvez changer le layout de clavier dans System > Preferences > Keyboard > Layouts.

Wifite : à un clic du crack

Le plus dur est fait ! Il ne vous reste plus qu’à récupérer Wifite et le lancer.

Téléchargez le script python à cette adresse : http://wifite.googlecode.com/svn/trunk/wifite.py.

Rendez-le exécutable : chmod +x ; ou bien clic-droit sur le fichier, sélectionnez Properties > Permissions et cochez z Execute: Allow executing file as program.

Exécutez le script (double clic sur le fichier > Run).

Et hop, une bonne grosse interface à la clicouille :

Sélectionnez l’interface réseau à utiliser (en général, il n’y en a qu’une). Étant donné que l’on s’intéresse ici au WEP, vous pouvez sélectionner uniquement WEP dans encryption type.

De nombreux paramètres sont disponibles, mais pour mamie, il suffit de cliquer sur h4x0r 1t n40, et d’aller prendre une tisane.

Wifite se charge de tout, et note les mots de passe crackés dans le fichier log.txt créé à côté du script wifite.py.

Bingo !

Comments

Rémi

J’attendais avec impatience que quelqu’un fasse ce travail! Très intéressant en tout cas. Je me permets de m’abonner à ton flux RSS du coup.

Piwaï

Je t’y autorise avec plaisir

Bastien

C’est un peu dommage, du coup ça devient une boite noire à la IIS. On clique sur un bouton et ça fait tout, mais on sait pas vraiment ce que ça fait. Les plus intéressés devraient plutôt se tourner vers aerodump et cie, avec masse de tutos qui explique ce que ça fait, les différentes attaques etc.

Piwaï

Certes, mais Mamie n’en a rien à carrer de comprendre ce que ça fait ;-). Elle veut juste craquer son Wifi, elle est comme ça Mamie.

Les mains dans le cambUiBinder

2011-09-13T08:13:02+00:00

L’article précédent montrait comment faire de la coloration syntaxique en GWT.

Toujours pour Rockslide, je souhaitais pouvoir écrire le code à mettre en forme dans des templates UiBinder, plutôt que dans des Strings statiques portées par des classes Java.

Est-ce possible ? Comment y parvenir ? En creusant ces questions, j’ai réalisé que UiBinder possède de nombreuses facettes non documentées et qui méritent que l’on s’y attarde. Tour du propriétaire.

Widgets customs

Vous le savez probablement, il est possible d’inclure ses propres widgets GWT dans un template UiBinder.

Il suffit pour cela d’étendre la classe Widget. Prenons l’exemple d’un bouton ouvrant une fenêtre d’alerte :

public class AlertButton extends Button implements ClickHandler {

	public AlertButton() {
		addClickHandler(this);
	}

	@Override
	public void onClick(ClickEvent event) {
		Window.alert("I like turtles");
	}
}

Vous pouvez ensuite l’inclure dans vos templates UiBinder, en ajoutant un namespace correspondant au package de votre widget :

<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<g:FlowPanel>
		<custom:AlertButton />
	</g:FlowPanel>

</ui:UiBinder>

Un peu limité quand même…

Et avec des paramètres ?

Il y a mieux ! Vous pouvez tout à fait passer des paramètres à votre widget. Il suffit d’ajouter des paramètres de constructeur (donc obligatoires) ou des setters (donc facultatifs) à votre widget :

public class AlertButton extends Button implements ClickHandler {

	private final String msg;

	@UiConstructor
	public AlertButton(String msg) {
		this.msg = msg;
		addClickHandler(this);
	}

	@Override
	public void onClick(ClickEvent event) {
		Window.alert(msg);
	}
}

Notez la présence de @UiConstructor, nécessaire lorsque le constructeur par défaut n’est pas défini.

Puis d’utiliser les attributs correspondants dans vos templates UiBinder :

<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<g:FlowPanel>
		<custom:AlertButton msg="I like turtles" />
	</g:FlowPanel>

</ui:UiBinder>

Les attributs, ça pue ?

Si votre widget implémente HasText, vous pourrez alors définir ce texte directement au sein de la balise au lieu d’utiliser des attributs. Modifions AlertButton :

public class AlertButton extends Button implements ClickHandler, HasText {

	private String msg = "Default Message";

	public AlertButton() {
		addClickHandler(this);
	}

	@Override
	public void setText(String msg) {
		this.msg = msg;
	}

	@Override
	public void onClick(ClickEvent event) {
		Window.alert(msg);
	}

	@Override
	public void getText() {
		throw new UnsupportedOperationException();
	}
}

Notez que l’interface HasText impose d’implémenter getText(), mais cette méthode n’est pas nécessaire pour nos besoins.

C’est déjà plus sympa :

<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<g:FlowPanel>
		<custom:AlertButton>I like turtles</custom:AlertButton>
	</g:FlowPanel>

</ui:UiBinder>

Quid du HTML ?

Vous pouvez aussi inclure, au sein de vos widgets, du HTML défini dans votre template UiBinder, grâce à HasHTML.

Par exemple, supposons que je souhaite enrichir mon AlertButton pour afficher de belles popups, en utilisant une DialogBox :

public class AlertButton extends Button implements ClickHandler, HasHTML {

	private String html = "";

	private String title = "Default title";

	public AlertButton() {
		addClickHandler(this);
	}

	@Override
	public void setHTML(String html) {
		this.html = html;
	}

	@Override
	public void setTitle(final String title) {
		this.title = title;
	}

	@Override
	public void onClick(ClickEvent event) {
		DialogBox dialogBox = new DialogBox();
		dialogBox.setWidget(new HTML(html));
		dialogBox.setText(title);
		dialogBox.center();
	}

	@Override
	public void getText() {
		throw new UnsupportedOperationException();
	}

	@Override
	public void setText(String text) {
		throw new UnsupportedOperationException();
	}

	@Override
	public String getHTML() {
		throw new UnsupportedOperationException();
	}

}

La méthode setHTML() est appelée avec en paramètre le HTML sous forme de String.

Je peux désormais spécifier le contenu HTML de cette boîte de dialogue dans mon template UiBinder :

<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<g:FlowPanel>
		<custom:AlertButton title="I like turtles">
			<p>
				I <strong>really</strong> like turtles!<br />
				What about <em>you</em>?
			</p>
		</custom:AlertButton>
	</g:FlowPanel>

</ui:UiBinder>

  ?

Comment utiliser des entités HTML dans vos templates UiBinder ? Il suffit d’ajouter la DTD fournie par Google :

<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<g:FlowPanel>
		<custom:AlertButton title="I like turtles">
			<p>
				Turtles &gt; Dolphins!
			</p>
		</custom:AlertButton>
	</g:FlowPanel>

</ui:UiBinder>

Paramètres complexes

permet d’injecter un objet (créé via GWT.create()) dans votre template UiBinder.

Un exemple d’utilisation serait l’injection d’une Enum afin de paramétrer un widget.

Reprenons notre fenêtre d’alerte initiale :

public class AlertButton extends Button implements ClickHandler {

	private final Animal animal;

	@UiConstructor
	public AlertButton(Animal animal) {
		this.animal = animal;
		addClickHandler(this);
	}

	@Override
	public void onClick(ClickEvent event) {
		Window.alert("I like " + animal.toString());
	}
}

Animal est une simple Enum :

public Enum Animal {
  TURTLES, DOLPHINS;
}

Il ne reste plus qu’à utiliser l’Enum en question dans le template UiBinder :

<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>
	<ui:with field="animal" type="info.piwai.blog.Animal"/>

	<g:FlowPanel>
		<custom:AlertButton animal="{animal.TURTLES}" />
	</g:FlowPanel>

</ui:UiBinder>

Cerise sur le gateau, on bénéficie de l’autocomplétion : en tapant {animal.}, l’IDE propose TURTLES ou DOLPHINS !

Bon, et la coloration syntaxique alors ?

En combinant tout ce qui a été dit précédemment, il est possible d’écrire des exemples de code au sein de templates UiBinder, mis en forme par SyntaxHighlighter. On utilisera pour cela un widget implémentant HasHTML.

Avant de passer aux choses sérieuses, un rappel. Dans l’article précédent, nous utilisions le code suivant pour faire de la coloration syntaxique en GWT :

public void bindTextAreaCodeToHtml(TextArea textArea, HTML html) {
    JavaScriptObject brush = BrushFactory.newJavaBrush();
    String code = textArea.getValue();
    String htmlCode = SyntaxHighlighter.highlight(code, brush, false);
    html.setHTML(htmlCode);
}

Une précision : Le parseur UiBinder utilisé pour les widgets implémentant HasHTML ne garde pas les retours à la ligne, ce qui se révèle gênant lorsque son contenu est du code mis en forme. Pour contourner cela, on peut utiliser une balise <pre> dans le template UiBinder.

Trêve de suspens, voici le résultat :

public class Code extends Composite implements HasHTML {

	private JavaScriptObject brush = null;

	private HTML panel = new HTML();

	@UiConstructor
	public Code() {
		initWidget(panel);
	}

	public void setBrush(JavaScriptObject brush) {
		this.brush = brush;
	}

	@Override
	public void setHTML(String html) {
		// On supprime la balise <pre>
		final String code = html.replaceFirst("<pre>", "").replaceFirst("</pre>", "");
		Scheduler.get().scheduleDeferred(new ScheduledCommand() {
			@Override
			public void execute() {
				if (brush != null) {
					String codeAsHtml = SyntaxHighlighter.highlight(code, brush, false);
					panel.setHTML(codeAsHtml);
				}
			}
		});
	}

	@Override
	public void getText() {
		throw new UnsupportedOperationException();
	}

	@Override
	public void setText(String text) {
		throw new UnsupportedOperationException();
	}

	@Override
	public String getHTML() {
		throw new UnsupportedOperationException();
	}

}

Notez l’utilisation du Scheduler pour afficher le code immédiatement après la construction du widget. L’ordre de valorisation des attributs n’étant pas garanti, cela permet d’être sûr que la valeur du champ brush aura été préalablement injectée au moment de l’appel à SyntaxHighlighter.

On peut ensuite utiliser ce widget dans un template UiBinder classique :

<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder
    xmlns:ui='urn:ui:com.google.gwt.uibinder'
    xmlns:g='urn:import:com.google.gwt.user.client.ui'
    xmlns:custom='urn:import:info.piwai.blog.ui'
>

	<ui:with field="brushFactory" type="info.piwai.blog.BrushFactory"/>

	<g:FlowPanel>
		<custom:Code brush="{brushFactory.newJavaBrush}"><pre>
			public class Main {
				public static void main(String[] args) throws Exception {
					List&lt;String&gt; moto = Arrays.asList("I", "Like", "Turtles");
					System.out.println(moto);
				}
			}</pre>		
		</custom:Code>
	</g:FlowPanel>

</ui:UiBinder>

_Les caractères < et > doivent être échappés pour éviter qu’ils ne soient interprétés par UiBinder et ne conduisent à des erreurs de validation. Ainsi, au lieu de **List**, on écrit **List<String>**_

Edit : Merci @matboniface, j’avais au départ parlé d’échapper des entités HTML, ce qui n’a pas beaucoup de sens.

Conclusion

Cet article s’est révélé plus long que ce que j’avais en tête initialement ! J’espère qu’il vous aura fait découvrir des aspects intéressants et souvent méconnus de UiBinder.

N’hésitez pas à compléter ce billet avec vos trucs et astuces UiBinder en commentaire !

Vous pouvez aussi vous abonner au Flux RSS. Je me suis fixé comme objectif de publier un article par semaine, on verra si je tiens le rythme ;-) .

Comments

Nicolas François

Article sympa ! Bon allez, j’ai aussi un truc sympa qui n’est pas dans tes astuces. Admettons que j’utilise une api gwt externe, et que le composant que je souhaite insérer ne possède pas de constructeur par défaut. Je pourrais m’amuser à recompiler le code en ajoutant un @UiConstructeur mais c’est ch** à faire et coté maintenance un joli bordel. La solution est très simple : Je l’utilise l’air de rien dans le xml, mais dans le java, je le déclare de la façon suivante :

@UiField(provided=true)
MegaComponentOfTheDeath mcoth= new MegaComponentOfTheDeath(machin, bidule, truc);

Le provided indique que l’instanciation est fournie par le java.

Autre cas où c’est utile : Injection de ressources via GIN, le composant utilise un resource bundle qui est injecté dans le code java grace à gin.

@UiField(provided=true)
Resource res;

@Inject
public void setRes(Resource res){
  this.res = res;
}

Eric B. (@vvinnie)

Et pourquoi pas un petit enrobage en CDATA plutôt que de rendre les illisibles. D’ailleurs, question philosophique : et si les generics avaient mauvaise réputation seulement parce que les gens essaient d’en parler en html ? hum ?

Piwaï

“rendre les illisibles” => “rendre les < > illisibles” (les signes ont sautés de ton commentaire, vu que le HTML est activé )

Grumph. Je n’y avais pas pensé… ça a l’air de fonctionner, en tout cas ya aucune erreur de validation. A voir si CDATA préserve bien les retours à la ligne (comme ça plus besoin de <pre>), et comment ça se présente ensuite au runtime en terme de manipulation du DOM (=> que contient la string envoyée à setHTML ou setText ..)

Je testerai ça à l’occasion, mais si ça marche c’est plutôt génial, ça permet de simplifier à mort le code. Merci !

Piwaï

Je viens de vérifier : CDATA permet effectivement de ne plus échapper les chevrons. Par contre, avec UiBinder, il ne conserve pas les retours chariot. Il convient donc d’utiliser pre et CDATA en complément.

Coloration Syntaxique en GWT

2011-09-05T10:59:39+00:00

Vous connaissez peut-être Rockslide, qui permet de réaliser une présentation (des slides) en GWT.

Qui dit slides techniques dit exemples de code, et donc coloration syntaxique.

J’ai creusé un peu le sujet pour finalement retenir une solution.

Comment faire de la coloration syntaxique côté client, en GWT ?

Solutions disponibles

A ma connaissance, il n’existe pas de solution de coloration syntaxique spécifique à GWT, ce qui nous laisse trois options :

Implémenter une solution en GWT (c’est mort, je n’ai pas que ça à faire)
Trouver une solution en Java et adapter la partie graphique (fausse bonne idée)
Trouver une solution en Javascript et réaliser un binding GWT (ça, c’est dans mes cordes)

Un rapide tour d’horizon fait ressortir deux frameworks Javascript très utilisés pour la coloration syntaxique :

Les deux semblent maintenus, des releases récentes sont disponibles. Mon choix se porte sur SyntaxHighlighter, qui semble plus beau. C’est purement subjectif, mais je trouve que le code mis en couleur par highlight.js a un petit air vieillot.

gwt-syntaxhighlighter

Coup de bol : je tombe sur gwt-syntaxhighlighter, une intégration assez poussée de SyntaxHighlighter dans GWT.

Trop poussée, hélas :

gwt-syntaxhighlighter utilise des Generators, ce qui allonge le temps de compilation,
gwt-syntaxhighlighter comporte quelques bugs qui ne sont pas corrigés et qui sont difficiles à contourner,
la version de SyntaxHighlighter utilisée n’est pas à jour (les versions récentes apportent pourtant des évolutions intéressantes).

De plus, il s’avère que l’intégration de SyntaxHighlighter est relativement aisée, beaucoup plus simple que ce que tente de faire gwt-syntaxhighlighter.

Intégration GWT de SyntaxHighlighter

Charger les scripts et les CSS

Tout d’abord, il faut télécharger SyntaxHighlighter. Les dossiers scripts et styles contiennent tout ce dont vous aurez besoin.

Ces fichiers devront être inclus dans l’application GWT. Il existe différentes méthodes. J’ai choisi de créer un répertoire public au même niveau que le répertoire client, et d’y placer les répertoires scripts et styles.

Ensuite, il suffit de les ajouter au module (fichier .gwt.xml) :

<?xml version="1.0" encoding="UTF-8"?>
<module>

    <!-- La CSS de base pour SyntaxHighlighter -->
    <stylesheet src="styles/shCore.css"/>

    <!-- J'utilise le thème Eclipse (8 thèmes disponibles) -->
    <stylesheet src="styles/shThemeEclipse.css"/>

    <!-- Le javascript de base pour SyntaxHighlighter -->
    <script src="scripts/shCore.js"/>

    <!-- Les extensions pour les différents langages utilisés -->
    <script src="scripts/shBrushJava.js"/>
    <script src="scripts/shBrushXml.js"/>

    <!-- [...] -->
</module>

Go, Go, GO!

A l’origine, SyntaxHighlighter fonctionnait en parsant le DOM et en modifiant les nœuds marqués comme conteneurs de code. La dernière release propose une approche alternative, qui fonctionne indépendamment du DOM.

Le fonctionnement est simple : une fonction Javascript prend en entrée du code sous forme de String, et renvoie une String contenant le HTML pour afficher le code formaté.

Un brush (pinceau) est nécessaire pour colorer du code. Il existe en fait un brush par langage, et celui-ci définit les mots clés, la syntaxe, etc.

Il nous faut donc une fabrique de pinceaux :

public class BrushFactory {
    public native JavaScriptObject newJavaBrush() /*-{
        return new $wnd.SyntaxHighlighter.brushes.Java();
    }-*/;

    public native JavaScriptObject newXmlBrush() /*-{
        return new $wnd.SyntaxHighlighter.brushes.Xml();
    }-*/;
}

Voici le code JSNI utilisant SyntaxHighlighter pour transformer du code en html :

public class SyntaxHighlighter {
    public static native String highlight(String code, JavaScriptObject brush, boolean toolbar) /*-{
        var params = {};
        params['toolbar'] = toolbar;
        brush.init(params);
        return brush.getHtml(code);
    }-*/;
}

Notez le paramètre toolbar qui permet d’afficher ou non la barre d’outil. De nombreux paramètres sont disponibles ; à vous de les intégrer.

Ya plus qu’à utiliser tout ça, par exemple en récupérant le code contenu dans une TextArea et en l’affichant via un HTML.

public void bindTextAreaCodeToHtml(TextArea textArea, HTML html) {
    JavaScriptObject brush = BrushFactory.newJavaBrush();
    String code = textArea.getValue();
    String htmlCode = SyntaxHighlighter.highlight(code, brush, false);
    html.setHTML(htmlCode);
}

Conclusion

Vous avez désormais toutes les clés en main pour faire de la coloration syntaxique côté client en GWT.

Bien entendu, ce code est à adapter suivant vos besoins. Vous n’êtes pas obligés d’utiliser des static partout ;-) .

Comments

Raphaël Brugier (@rbrugier)

Hello,

Intéressant je n’avais pas suivi le développement de SyntaxHighlighter avec la nouvelle méthode sans le parsing du DOM.

J’avais utilisé GWT + le plugin sur mon projet de stage l’an dernier presque de la même façon

En tout cas continue les posts sur gwt, il y a du public

Raphaël.

Piwaï

Cool :) Je vais tâcher de continuer, j’ai quelques idées dans mon sac :)

Les IDE, et la règle des 80 / 120

2011-08-31T15:38:09+00:00

Cet article n’a strictement rien à voir avec Pareto. Un peu plus avec un tweet datant de quelques mois.

La longueur maximale des lignes de code est un débat récurrent dans les équipes de développement.

Dès lors que l’on met en place un formatage du code automatique et partagé par tous les développeurs (notamment pour faciliter les diff), l’éternelle question revient :

80 ou 120 ? Robert

Ça fait 5 ans qu’on a tous des 19 pouces, on pourrait peut-être passer à 160 non ? Gérard

Que nenni !

Voici la configuration que j’utilise :

Vous avez bien lu, je préfère 1000. Ou 2000. Ou 10000. Ou… bon, je suppose que vous avez compris.

Non pas que j’ai la chance de disposer d’un écran de cinéma pour coder, pour moi il s’agit juste de bonnes pratiques.

Ce n’est pas votre IDE qui doit décider de la longueur de vos lignes de code, c’est vous.

Une ligne de code qui dépasse la largeur de l’écran, c’est un code smell. Laisser l’IDE ajouter des retours à la ligne, c’est cacher le code smell.

Un peu comme mettre du déo sans se doucher après un jogging.

Pour la route, quelques cas classiques de longlignite aigüe :

Le syndrome du développeur C, aka le radin des variables

A l’origine, en C, il fallait déclarer toutes les variables locales d’une procédure au début de celle-ci. Ce n’est pas forcément une mauvaise idée.

Mais en combinant cela avec l’idée qu’une variable locale, c’est forcément de la mémoire utilisée en plus et donc de la “performance” en moins, on prend rapidement la bonne habitude de créer le moins de variables locales possibles.

Un exemple de la vraie vie :

WebApplicationContextUtils.getWebApplicationContext(this.getServletContext()).getAutowireCapableBeanFactory().autowireBeanProperties(this, AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE, true);

Vous trouvez-ça lisible vous ?

C’est peut-être super excitant à écrire (ah ça c’est sûr on est fier hein, on a utilisé aucune variable…). Et PAN, +10000€ de dette technique.

La solution est simple, elle s’appelle la variable locale. Découpez votre code, créez des variables locales même si elles ne servent qu’une fois. Et découpez votre code en petites méthodes.

Moins de 5 lignes, c’est bien. Au passage, je vous recommande chaudement la lecture de Clean Code :-).

On comprend déjà mieux :

ServletContext servletContext = this.getServletContext();
WebApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(servletContext);
AutowireCapableBeanFactory beanFactory = applicationContext.getAutowireCapableBeanFactory();
beanFactory.autowireBeanProperties(this, AutowireCapableBeanFactory.AUTOWIRE_BY_NAME, true);

Le fan de programmation fonctionnelle

Le mec, un jour, il a découvert Google Guava et ses Function ; il a trouvé ça trop cool et a adopté le “style fonctionnel” dans tous ses développements. Malheureusement, en Java, cela se traduit par des classes anonymes (à moins d’utiliser FJF… pub ;-)), et cela déborde vite de l’écran !

Encore un exemple de la vraie vie, un peu maquillé et allégé pour l’occasion :

public class MyPanel extends Composite {

	public MyPanel() {
		final Request request = new Request();
		initWidget(new VerticalPanel() 
			{
				add(new HorizontalPanel() {
					{
						add(new RadioButton("native", "native") {
							{
								setValue(request.isNativeRequest());
								addClickHandler(new ClickHandler() {

									public void onClick(ClickEvent event) {
										request.setNativeRequest(getValue());
									}
								});
							}
						});
					}
				});
				add(new Button("Run", new ClickHandler() {
					public void onClick(ClickEvent event) {
						ServicesHolder.requestService.execute(request, new AsyncCallback<Response>() {

							public void onFailure(Throwable caught) {
								Window.alert(caught.getMessage());
							}

							public void onSuccess(Response response) {
								try {
									updateUi(response);
								} catch (Exception e) {
									onFailure(e);
								}
							}
						});
					}
				}));
			}
		});
	}
}

Quand je tombe sur une classe qui comporte 1000 lignes comme ça, j’ai beaucoup de mal à suivre le flux d’exécution. Pas vous ?

L’utilisation d’une Fluid interface

Les Fluid interfaces, par design, sont faites pour permettre les appels chaînés, afin d’augmenter la lisibilité du code et éventuellement créer des DSL.

Si la chaîne d’appels de méthode est courte et a un sens grammatical, il paraît alors sensé de la laisser sur une ligne, sans que l’IDE ne formate cette ligne.

Exemple avec un binding Guice :

bind(Geek.class).annotatedWith(Piwai.class).toInstance(piwai);

Par contre, si la chaîne d’appels est trop longue, à vous de la découper à votre goût sur plusieurs lignes.

Une astuce simple consiste à ajouter “//” en fin de ligne, pour empêcher l’IDE de recoller ensemble des appels de méthodes que l’on a décidé de séparer.

Par exemple, pour utiliser un SharedPreferences helper généré par AndroidAnnotations:

prefs.edit() //
  .clear() //
  .name().put("John Smith") //
  .age().put(42) //
  .done();

A vous maintenant : qui a d’autres exemples de longlignite aigüe ?

Comments

Baztoune

Ah, l’éternelle question :D ça me rappelle ce topic sur SO
Dans l’absolu, je suis d’accord, c’est bien au développeur de découper ses lignes, pour donner du rythme à son code et le rendre lisible, mais en équipe, ne vaut-il mieux pas assurer l’uniformisation de l’apparence du code? Pas spécialement pour le gestionnaire de sources qui se débrouille très bien, mais pour la lisibilité globale du code, et ainsi éviter les disparités de style entre développeurs.

Gabriel Kastenbaum

J’ai juste une règle, qui diffère un peu de la règle usuelle du nombre de lignes :

une méthode doit être lisible d’un coup d’oeil. On parle toujours du nombre de lignes par méthode. Il faut aussi parler des lignes trop longues en largeur. C’est aussi fautif amha
Après (cf. exemple de la classe anonyme) java n’aide pas toujours. Mais l’idée est là. Pour un écran normal, il faut pouvoir tout lire d’un coup.

J’ai déjà galéré sur des méthodes dont le bug se voyait quand on scrollait à droite. Or je ne scrolle JAMAIS à droite. je n’y pense jamais.

C’est pq dans Eclipse je laisse une line width de 120 à peu près.
L’écran est une feuille.

Francois Marot

Entierement d’accord avec ce post. Pour moi le formatteur est un mal nécessaire (pour uniformiser tout ce qui est tabulation, espacement, supprimer d’éventuels saut de lignes multiple, et surtout faciliter les diff/merges) mais il doit en faire le strict minimum. Le développeur doit rester au manette, et si ponctuellement on veut pouvoir faire un ligne longue (pour mettre un commentaire sur un truc touchy par exemple), on doit pouvoir le faire. Tant que ca reste de facon exceptionnelle et justifiée. Donc des formatteurs de code, oui, mais de facon minimum.

when(piwaï.quit(excilys)).thenReturn(new Blog());

2011-08-31T14:28:18+00:00

Après deux ans et demi de prestation de service et de fun au sein d’Excilys, je m’envole pour de nouvelles aventures !

Tout ce que je peux officiellement vous dire pour le moment, c’est que je vais bosser pour une startup qui fait de l’Android. J’ai hâte d’y être !

Au sein d’Excilys, j’ai découvert le plaisir d’écrire sur le Blog et le Labs Excilys, et j’y ai laissé quelques 24 articles et 93 commentaires.

Je vais donc continuer sur ce blog (n’oubliez pas le Flux RSS) ;-)).

J’héberge le blog sur wordpress.com, comme ça aucun souci de maintenance, et en prime ya même une coloration syntaxique :

when(piwai.quit(excilys)).thenReturn(new Blog());

Ça sera aussi l’occasion de vous parler des projets open source qui me tiennent à cœur : AndroidAnnotations, Rockslide, FunkyJFunctional, 2H4U ;-)

On commence avec un peu de clean code : Les IDE et la règle des 80 / 120.

Khoa Nghiem

Bonne chance pour la suite alors.
Dommage que je n’ai pas eu plus l’occasion de te côtoyer

Fred Faure

Congratulations jeune padawan devenu jedi !

Thomas Bassetto (@tbassetto)

Bonne chance pour la suite :D