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);
  }
}

aLogcat – Android Logcat Application

aLogcat market barcode

There are several “log view” applications on the market. All of them provide a means to send your log file contents, typically via email. This is one good approach, but it doesn’t handle the use case where you don’t have immediate access to a PC email client to view the results. aLogcat is an Android application that allows you to view your Android device log from the device itself. It provides a scrolling, color-coded log that is filterable by keyword and log level. It also supports output in various log formats. aLogcat also covers the send log use case by allowing a snapshot of the log to be sent off to another device.

This is mainly an app for developers, but it is also useful for power users that are willing to get involved with developers to help them find problems in their applications. Most Android developers are small scale hobbyists and can’t devote full-time effort and money to rigorous testing across multiple devices. I hope this app lowers the barrier for involvement of the average user in the development cycle.

aLogcat

Java EE Got it Wrong

After working on two large-scale, cross contains / platform, web application projects, I’ve come to the conclusion that Java EE is fatally flawed.

If someone asked you to state the most important, guiding principle of the Java language, what would you say? You would would probably say “write once, run anywhere.” Indeed, for Java SE this holds true most all of the time. In Java EE however, it is hopelessly broken. The reality is that every web container is slightly different in ways that force developers work around problems, avoid certain features, or even have different code paths. Different code paths in a language that was never designed for it.

Different aspects of Java EE have different levels of stability. JSP works almost the same across all containers. Things like JSF and Java Persistence (JPA) however are hopeless. My most recent experience is writing a web administration console using JSF for the OpenSSO project. OpenSSO claims to support at at least 8 different web containers. Every container required JSF tweaking that ranged from annoying to just plain terrible. Needless to say I had egg on my face to some degree over the choice to use JSF. It was a no-brainer for me. JSF is the chosen MVC framework for Java EE. My mistake.

The only container where JSF “just worked” was Tomcat. Tomcat isn’t a Java EE container at all.Tomcat doesn’t include JSF or any of it’s dependencies. We might be on to something here. Let’s look at another example: Spring. Spring is essentially a lighter-weight, simpler replacement for Java EE. Why is Spring so popular? One reason is that it is an elegant design. But another, perhaps more important reasons is that no matter what container you are developing on, Spring is Spring. It’s the same JAR, the same code, the same implementation. It makes very few assumptions about the capabilities of the underlying container. Another example is Facelets, a light-weight JSP replacment. I use JSF+Facelets on the OpenSSO project, and it has been flawless (the Facelets part). Why? Because I include the Facelets JAR, it is not provided by the system.

What if Java EE had followed the same model? Java EE should have been nothing more than a plugin framework and some base services. Want to use JSF in your project? Just include it from a managed, networked Java EE module repository. Include the one, common implementation of JSF. Include the approved version for your level of Java EE. If you support Java EE 5, you get JSF version X, across all web containers.

 

 

DroidLife – Conway’s Game of Life for Android

Gosper's Glider Gun in progress

I just posted a new Android app to the market: DroidLife, an implementation of Conway’s Game of Life. CGoL is a simulation (zero-player game) of cellular life (don’t confuse it with Milton Bradley’s Game of Life, a board game). The app bundles many interesting seeds, and allows users to download thousands of others and run them as well. Seeds are just initial simulation states, and more specifically are simply a set of one or more points on a grid representing live cells. There are around 4 “standard” seed file formats. DroidLife understands the most common / simple of those, Life 1.06. The most complete repository of seed files can be found on LifeWiki.

I was initially motivated to write this app as it was the topic of an interview question, for which I was only able to give a mediocre answer. One thing is for sure, if anyone ever asks me about CGoL again in my life, I have enough information to bore them for hours. I also saw it as a chance to get my feet wet with some trivial graphics on Android. Credit to “MrSnowFlake” for putting together this game template (bump) thread, based on Android’s Lunar Lander sample, which helped me get started. Without it my ramp up time would have been much greater.

Depending on my time, here are a few things I’d like to add to the app,

1. Read other file formats: RLE, PlainText, Life 1.05
2. Save game state to file
3. Seed editor: define you own seeds

A b1s12 world seeded with a single cell

httpmon – HTTP Server Monitor

I just published a new application to the Android Market: httpmon. In a nutshell, it allows you to monitor the status of any number of HTTP servers. A monitor is made up of 1) a request which describes how to contact the server, 2) one or more conditions that must hold true to consider the server “valid”, and 3) zero or more actions to take if the server is “invalid”.

This was another learning exercise. I wanted to play around with how I would structure an extensible object model in Android. The app source is structured so that the conditions and action class trees are easily extensible at both the model and view level to add new types of conditions and actions. I’m quite happy with how well it came out in that regard. None of this is probably visible from using the app however.

I hope that at least some people find this useful, as I’m looking forward to receiving input for new types of conditions and actions.

Supported conditions,

• ping
• response time
• response code
• content contains (substring, wildcard, or regex match)
• header container (substring, wildcard, or regex match)

Supported actions,

• notification (alert sound, flash, and / or vibrate)
• send SMS

I wanted to have a “send email” action, but it turns out that there is no way to send an email programmatically, on behalf of the user, with Android. I am not sure why they would let an app send an SMS on behalf of the user, but not an email. An SMS seems more dangerous actually. Of course, I could have used JavaMail, but that means gathering an SMTP server and port, and supporting credentials. Most users will lack the will or the way to set that up I think.

Intercepting BACK in an Activity

I couldn’t find anything good explaining this, so I’ll post here. The pattern is that you have a parent activity that lists objects, and a sub activity that allows editing those objects. If the user hits the BACK key, we want to save their work and pass it back to the parent activity. All you need to do is override Activity.onKeyDown() as such,

@Override
public boolean onKeyDown(int keyCode, KeyEvent event) {
  if (keyCode == KeyEvent.KEYCODE_BACK) {
    if (save()) {
      return super.onKeyDown(keyCode, event);
    } else {
      return false;
    }
  }
  return super.onKeyDown(keyCode, event);
}

The semantics are that if you return true, then the normal flow of the BACK key continues. Here, we call super.onKeyDown() to let the default implementation process the key press as it normally would by calling super.onKeyDown() instead of just returning true directly. If you return false, then the flow stops, and the back key is canceled. In the code above, save() might implement some logic to validate the data, and set up to return a value to the parent activity by calling setResult() with an intent,

private boolean save() {
  if (validate()) {
    Intent intent = new Intent();
    intent.putExtra("org.jtb.some.data", mData);
    setResult(Activity.RESULT_OK, intent);
    return true;
  }
  return false;
}

Android Market and the Developer Problem

Android market has a lot of serious problems (that were not fixed in donut), but I want to focus on just one here: the lack of connection between the developer and application users.

Users can interact with the developer in 3 ways: by rating the app, by leaving comments, and by emailing them directly. The comment / rating system is completely anonymous, there is no way for the developer to interact with users that leave comments and feedback.

Why is it important for a developer to be able to interact with a user? Most Android apps are not published by large scale software producing companies. In most cases it’s one person, without a team of testers ensuring the application’s correctness across many different devices and several different Android OS releases. Developers rely on user feedback to find and fix problems with their apps. It is nice when users use the developer’s email to report problems, but more often than not the developer gets comments like “force closed, uninstalled” with no way to get any details from the user.

This problem can be fixed, with some rather harsh stipulations applied to market downloads. When a user downloads an app, they should implicitly agree to open a communication channel with the developer. Specifically, a “receipt” should be provided to the developer for every download (free or paid). This receipt should include details of the user … including their email, device info, date installed, date uninstalled, etc. If the user doesn’t like this, they can choose to not download the (free) application.

I suspect most people would object to this with privacy concerns, but to that I say too bad. Free software should never be truly free. Instead, “free” software just means you may compensate developers with non-monetary forms of payment, such as,

1. Providing feedback on features, usability.
2. Sending crash logs.
3. Or even, fixing bugs directly.

If the user is truly leaching in that they aren’t willing to provide any of the above, it’s of no consequence to the app developer if they decide not to run the app. It’s a frustrating experience for developers to work hard on an app and publish it, for free, only to receive negative, or vague comments. A developer-friendly market stimulates more application development, which is benefits users in the long run.

This all goes for free apps. For paid, or ad-supported apps, I believe it is up to the developer to provide some level of correctness without user involvement.

Reverse a Linked List, Java

Reviewing for interview questions, I ran across this. Most solutions you’ll find are in C, and that can be easily adapted … however, the C-ness sometimes gets in the way of spotting the subtleties. Here is the function in Java,

static void Node reverse(Node head) {
Node current = head;
Node newHead = null;
while (current != null) {
Node tmp = current;
current = current.next;
tmp.next = newHead;
newHead = tmp;
}
return newHead;
}

So how does it work? In a nutshell, we always have 2 lists: 1) the remaining portion of the original list pointed to by current, and 2) the new list pointed to by newHead. Each iteration strips the head element from the original list, and adds it to the head of the new list.

• line 5 saves the current loop pointer, this will be our new head at the end of each loop.
• line 6 advances the current loop pointer one past the head, but remember we saved the old current pointer in tmp at line 5.
• line 7 assigns the next pointer of our new head (tmp) to the previous head pointer. The first time through the loop, this is null, and we’ll have a new list containing one item.
• line 8 permanently tracks our new head by moving it out of the temporary loop var.

I can’t imagine it gets better than this. No new allocations, and O(n).

CraigsHome – Android App

I published a new Android application to the market today: CraigsHome. CraigsHome plots CraigsList rental listings on your Google map. You can get more information about the listing including photos, and even email the author right from your device with one click.

Right now, it only covers rentals (apartment, room, house). It could easily also cover for sale listings. Without going into too many details, it would require some extra processing on the back side. With for sale listings, this could be the Zillow-killer app. Re-presenting data from CL is never going to be as clean as Zillow listings, but with the popularity (and free-ness) of CL, it could really put a dent in things for them.