AT&T’s 3g Microcell Scam

AT&T is beta testing what they call a 3g Microcell in select markets. In a nutshell, this is a mini, personal cell tower for your home. It bridges a local 3g router with your existing broadband connection. When available in your market, the microcell is available to AT&T wireless customer at an additional fee. It can blanket 5,00 square feet with a strong signal (probably under optimal conditions, not in a city). It is locked to your phones only. You must have a 3g phone. Engadget has a more detailed write up.

Let me make sure you understand. For the privilege of having a usable wireless signal in / around your home, you can pay AT&T an additional charge. This is on top of the $80+ you are already paying for your wireless plan. Along with that, AT&T also gets to use your pipe, not theirs, to provide you the signal. The pipe you are already paying for to them (via AT&T DSL) or some other broadband provider, on top of the $80, on top of the charge for the Microcell.

Depending on the additional microcell charge, this is somewhere between a bad insult and rape. I expect to have a usable wireless phone service for $80 / month. I’m certainly open to working outside the box to make it better, but I shouldn’t have to pay an additional charge. If anything, AT&T should provide a kickback to microcell users, as it is using the microcell host’s broadband pipe and not further clogging AT&T’s. It shouldn’t come as a surprise that microcell users would be connected to their microcell more than any other cell “tower”, possibly with the exception of their employer’s locale (and it makes sense for businesses to have microcells of their own anyway). That means that the microcell is diverting large percentage of traffic that would otherwise be filling up AT&T’s pipes.

Here’s how AT&T should make use of microcell technology. In areas where many users report spotty service, AT&T should contact customers and offer them free microcells. The microcell host should get some discount just for using the microcell for their own purposes. Additionally, if the user agrees, they can share some configurable portion of their broadband and make it available through the microcell for surrounding customers. The microcell host should get a discount proportional to how much service they provide, proportional to the load they take off AT&T’s pipes. AT&T should make larger-scale microcells available to businesses (millicells?).

At even a small monthly discount, AT&T would have more volunteers than they would know what to do with. In densely populated areas, this would be a godsend for them.

This idea does complicate deployment to some degree. The microcell needs to monitor and throttle bandwidth and connections, and reject connections when the limit is reached. For discounts, it needs to track and upload usage back to AT&T. These are not hard problems by any means. I also wonder how broadband providers would feel about AT&T offloading traffic onto their networks without providing any compensation.

JSF Select Widgets (a little) Easier

The implementation of JSF select lists have always confounded me a little. When building your array of SelectItem objects, you are free to put any object as the item’s value. However, simply doing that will lead to confusing / misleading errors. The catch is that you must implement a JSF Converter for the value type in your SelectItem.

I don’t understand why the JSF impl can’t smooth this pattern over. For example, wouldn’t it be enough for the SelectItem values to be uniquely identifiable via a string? Then JSF can simply map them to a the real object stored on the server. Even for a client state saving method, couldn’t JSF serialize the object itself on the client page? Now we are getting somewhere.

The above is really only feasible if your value type is easily transformable to and from a string. If it isn’t, then you are stuck writing comlex serialization / de-serialization routines for any object value that you use in a SelectItem. Why not generalize that? Below is a general-purpose ASCII (and hence web safe) serialization / de-serialization utility.

import com.sun.identity.shared.encode.Base64;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

public class AsciiSerializer {
  public static String serialize(Object o) throws IOException {
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    ObjectOutputStream os = new ObjectOutputStream(baos);
    os.writeObject(o);
    os.flush();
    os.close();

    String es = Base64.encode(baos.toByteArray());
    return es;
  }

  public static Object deserialize(String es) throws IOException, ClassNotFoundException {
    byte[] ba = Base64.decode(es);
    ByteArrayInputStream bais = new ByteArrayInputStream(ba);
    ObjectInputStream is = new ObjectInputStream(bais);

    Object o = is.readObject();
    is.close();

    return o;
  }
}

You still must write and register a converter, but now it is trivial,

public class MyConverter implements Converter {
  public Object getAsObject(FacesContext context, UIComponent component, String value) {
    MyObject mo = AsciiSerializer.deserialize(value);
    return mo;
  }

  public String getAsString(FacesContext context, UIComponent component, Object value) {
    return AsciiSerializer.serialize(value);
  }
}