FallFramework For Mobile

Not too shabby… I think I can say it’ll probably do something close to what I think we might possibly need… almost…

What am I talking about? Hi, I’m Cliff and you’re here because you’d rather writing a turing machine in Scheme rather than figure out if the 49’ers trumped Ravens in the 4th quarter. (By the way, they didn’t.. doggonit!) Recently I switched from being Joe Cool Java/Linux dude to Radical JavaME/OSX guy and it’s been an adventure. Coming from a mostly mainframe server-side programming career I take certain things for granite. (I sometimes take granite for sulfur and later take sulfur smelling brown chunks to the toilet but that’s another topic entirely.) Normally, with like JavaSE, you can like, do really cool agile things. Y’know like program to interfaces and do setter based injection with reflection, late binding, and dynamic class loading. But with JavaME you gotta be reeeaaally really clever and do egg-headed stuff like making sure you have more fingers than occupied bytes in memory, hard binding to concrete objects… cuz like you can’t use Class.forName or a classloader, and worry about tail recursion and loop unwinding. Well old habits die hard like Bruce Willis (yeah, that was a really dumb analogy). So I decided to do something about the short-comings. That makes me feel smarter than you because I did something about it and you didn’t. If you were smarter you would have beaten me to the punch and come up with an even better idea. Alas my intelligence and attention to detail overpowers your meager “it has to be this way” attitude, so neh!

Insults and arrogance aside lemme tell you… I think I might have something. What I have so far is the buddings of what I’d like to label the Fallframework. It’s nothing to brag about (which is why I brag on) as it does yucky code generation. Before you start with the “How dare you code generate in this day in age!” I wanna ask how would you handle the problem? You need to decouple you object model. You have a bunch of objects that depend on interfaces. You can’t use reflection, you can’t use class loaders, you can’t call your mother (cuz she doesn’t know Java), and you can’t poll the audience for help. Well I lean on XSLT (because I like it, and because it’s a really cool language, and because it’s perfect for transforming XML, and because it gives me more to brag about) to process a Spring Beans descriptor and generate a BeanFactory that can return any object declared in the descriptor. It’s still basic right now in that it requires you declare types for dependencies but I plan on adding a little compile time classpath navigation for class introspecting which should allow for the same kind of type coercion/conversion found in the Springframework. Here’s a sample of what it does so far:

I can take this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">
    <bean id="myBean" class="com.mapquest.javame.MyBeanImpl">
        <property name="someValue">
            <value type="java.lang.String">Run D.M.C.</value>
        <property name="someOtherValue">
            <value type="java.lang.String">27</value>
        <property name="someNumber">
        <property name="someArray">
            <value type="int[]">1,2,3</value>

Into this:

package com.mapquest.javame;

        class FallBeanFactory {

      public com.mapquest.javame.MyBeanImpl getMyBean() {
          com.mapquest.javame.MyBeanImpl bean = new com.mapquest.javame.MyBeanImpl();
              bean.setSomeValue("Run D.M.C.");
              bean.setSomeArray(new int[]{1,2,3});

              return bean;


So now you can practice T.D.D. with mobile
JavaME has to be one of the more challenging frameworks in which to practice proper T.D.D. Not only because of the difficulties with supporting a decoupled design but also because the industry, runtime, and your co-workers, practically tattoo early optimization on the insides of your eyelids. However I still feel it is best to stay true to T.D.D. (or B.D.D.) and optimize where/when necessary. I’m still new to embedded stuff and I’m waiting for my team or my Blackberry 8830 to prove me wrong (my last sprint demo did show incredibly slow processing) but I maintain the faith. It’s getting late so I’ll leave you with those thoughts. (If you really wanna argue with me… put technical details where my eyes can see…)

2 thoughts on “FallFramework For Mobile

  1. Cliff, from you I would have expected a cool Groovy script that transforms the spring config into the java class – XSLT is kinda ugly when you start doing anything more than trivial..

    I was hoping something like this existed when I was starting to work on my thesis 2 years ago..

    Rock || Rap on !

  2. Yeah I thought about using Groovy for tempating. However XSLT is soo much better suited to transforming XML and no it doesn’t get ugly when the task gets complicated. (Although transforming into a non-xml format has its challenges.) That’s one of the things I like most about XSLT… you can do an awful lot with relatively little code but doing something simple sometimes requires what seems to be more code than necessary. There really a balance or harmony you achieve when you code it well. And getting that harmony is what makes it so cool.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s