Android Phone and Tablet Recycler Views Tutorial

As Head of Mobile R&D in Seeking Alpha I’m being asked constantly by developers and product managers alike if we can implement a feature on both the phone and the tablet.
For example, here is the Seeking Alpha Android application showing the portfolio page on a phone and on a tablet:

Seeking Alpha's Android app - phone

Seeking Alpha’s Android app – phone

Seeking Alpha's Android app - tablet

Seeking Alpha’s Android app – tablet

Continue reading

Event Inheritance in EventBus

If you are not using pub/sub framework for your Android client, this post is not for you. But then again, if you are a mobile developer you should ask yourself why your mobile clients applications aren’t using pub/sub framework? This deserve a separate post that will explain the benefits of such architecture. If you are into pub/sub for Android clients you are probably using Otto or EventBus.
EventBusSome of my team were using EventBus and encountered a weird event dispatch situation: some subscribers would get multiple invocations for a single event post.
The code could be simplified to the following sample:

public class MyActivity extends Activity {
   public class BaseEvent {}
   public class DerivedEvent extends BaseEvent {}
   public void onStart() {

   public void onStop() {

   public void onEvent(BaseEvent event) {
      // Handle base event

   public void onEvent(DerivedEvent event) {
      // Handle derived event

One could argue the need for inheritance in the events object. If you use EventBus extensively, you will learn that you need a lot of event objects to replace all those listeners that infested your code before you used EventBus. Usually, you will have a lot of events but some of them need to pass the same information to the subscriber (say a String or a List). Writing the boilerplate code for instantiation and getters/setters for each separate event class could be time consuming, and error prone:

public class Evnet1 {
   private final String foo;
   public Event1(String bar) { = bar;
   public String getFoo() {
      return foo;

Now imagine repeating this for Event2 to Event100. Not a lovely though, isn’t it?
We would rather have Event2 to Event100 extend Event1 and that’s all. This was the base idea of the code sample presented above for MyActivity.
Now somewhere else in your code there will be a publisher that will do this:

EventBus.getDefault().post(new DerivedEvent());

And for some reason both onEvent methods in MyActivity will be called! WTF? If you dig into EventBus internals, you will understand why this happens (If you don’t understand this drop me a line). So does it mean we can’t use event inheritance with EventBus? Absolutely not!! The solution is simple: don’t ever subscribe to base event object. This will solve all your problems. i.e.:

public abstract class BaseEvent() {}
public final class DerivedEvent1() {}
public final class DerivedEvent2() {}
public void onEvent(DerivedEvent1 event) {
   // Do something with the event, what you normally intended for the base
   // event in the previous sample
public void onEvent(DerivedEvent2 event) {
   // Do something with the event, as it was the DerivedEvent from the
   // previous sample

Now if you fire the DerivedEvent2:

EventBus.getDefault().post(new DerivedEvent2());

Only the event handle for this event (line 11) will be called.

To prevent inheriting the derived events, label the classes final, and to prevent instantiating the base event classes label them abstract.

Efficient Android Code – A Case Study

Just the other day I cam across UC Android’s MSRP parser implementation. I was astonished, left speechless. Gazing paralyzed at the code I resisted the urge to run screaming to the development manager and demand that the author of this gem will be publically hanged on the next weekly happy hour. Instead, being the good soul that i am, I decided to take this code as a test case to demonstrate how can we increase Android code efficiency.

I will try to demonstrate:

  1. Can we increase this code efficiency? Maintainability? Performance?
  2. Is it worth making the effort?

Continue reading

The future of Windows Mobile

It is no secret that I work in one of the most experienced Windows Mobile development ISV company. Lately we were wondering about the future of Windows Mobile. Traditionally, we developed Windows Mobile applications in C++ (for the Pocket PC platform). We used MFC throughout Windows Mobile 2000, 2002, 2003, 5.0. For the Smartphone platform we plunged right into .Net Compact Framework.
While working on our latest Windows Mobile 5.0 products, we suddenly encountered some MFC changes that broke backward compatibility. We also seen the effort put in by Microsoft to promote .Net in general and for mobile development in particular.
Fears begun creeping in: will MFC future is doomed? Will we still have Win32 API’s in future Windows Mobile releases? What will the Pocket PC and Smartphone unification bring for developers?
We are now faced with decisions regarding our future Windows Mobile development technology. Basically we can:

  1. Stay with MFC and face its fate bravely.
  2. Move to Win32 APIs (or create our wrappers around it).
  3. Switch to .Net CF (and suffer the performance penalty and the hardships of doing non standard “things” with it).

What do you think?

What should be our future Windows Mobile development technology?

View Results

Loading ... Loading ...

Is hi tech the new era slavery?

It is now almost over 4:00 am. I’ve been working for over 20 hours without a break. No, it’s not the 19th century, and I’m not mining coal. I’m managing software development in an hi tech company.

It is a free will slavery. Thousand of people in the western world are subject to this slavery every day. Have we changed forced slavery with our hi tech stock holders oppressors? Do you have the feeling that we labor much more than our parents did? And do we get more?