Walker Software Weblog

Google released the Android SDK. The lower levels look alot like the Pepper SDK (see my previous articles about the Pepper Pad). Linux Kernel, Native C libraries, Java language, and a Java Application Framework. The main differences that pop out are WebKit instead of Firefox for browsing, a new mobile oriented VM, 3d, and a App Framework that might actually be usable. The BIG, BIG change is the concept of intents, actions, and services that allow for plug-able modules to handle various actions and allow data sharing. An intent can be “Pick a Photo” and, depending on the software installed, it could be handled by the base software or a third-party addition without the user mucking about with strange settings. Pepper stores everything as XML, Android uses SQLite. Pepper leans on Firefox for rendering most UI via XSL stylesheets, Android uses screens defined in XML (I’m not clear on what’s doing the rendering. SGL?). Both Pepper and OpenMoko still use X windows while Android makes no mention of X.

The big problem (from my perspective) with Pepper was the inability to share data between applications, even if you wrote both applications. Android seems to have nailed that. Now the problem with Android maybe that it is too open. What is to stop someone from writing an app that display a dancing hamster animation and grabs all the contact info from the address book and uploads it a web site. My guess is that each provider will lock the phone to only install apps from their online stores. Call it “Security through retail sales channels”.

Pepper does not use a full, real Java stack. Android has it’s own VM. The SDK has tools to transform jars into a second set of byte codes for Android. So it is doubtful that a standard Java Swing would run on Android — with good reason — a desktop app’s UI would not be usable on a mobile device without modification. What incompatibles exist between a normal (Sun) JVM and Android’s VM?

Pepper also used Linux. The Pepper Pad cold-start and wake-from-sleep times are horrible. From all the reports I’ve seen OpenMoko isn’t fairing any better. To be fare, I rarely shutdown my phone, so maybe long start times aren’t too painful. I’m still curious how long the start-time is on an Android device. How long does it take an iPhone to boot for that matter?

Also of concern is the license. Android is released under the Apache Software License which means people can modify it without releasing the changes back to public. Which is generally good, however, imagine this: A wireless provider, say Verizon, creates replacements for the several components, say email. They tie the email component to their service which doesn’t meet your needs. Normally you could replace the component, but if Verizon modified their version Android to only accept components from the Verizon Online Store, and only allow Android updates from their servers, you would not be able to replace the component with one of your choosing. Unless, of course, you agree with a choice provided by Verizon and agree to the monthly fee. I hope providers don’t lock the phones down in those ways but I suspect they will. I’d like to be able to install software on my phone from any source I choose.

I’m guessing not all Android powered phones will be created equal. There will be artificial limitations — or even enhancements — available based on manufacturer, model, and wireless provider. A smart consumer would have to do alot of research and the average consumer would likely get burned. This could be a potential mess. I’m thinking the market will shake out like this: People that a guaranteed level of usability will pick an iPhone, people that want to tinker will get Android, people that think using email should hurt their hands will still use Blackberry, Microsoft will ready the next version of Windows Mobile probably with a Zune and Xbox duct-taped together, and your average cell phone user won’t care about any of those “fancy things” and just want the numbers to be bigger. Personally, I want a phone with a usable web-browser that supports wifi and is fast enough and does a good job with email and text messaging. If my LG enV had wifi and decent browser, I’d be happy — for 3 more months anyway.

One question I’d love to have answered is will Android be offered for existing phones. While I doubt it, I’d love to try it on my LG enV, even a beta version would be better than this BREW crap. Since Verizon is not part of the Open Handset Alliance, make that a double doubt.

I look forward to trying the Android SDK when I get some free time. The system architecture looks interesting and holds alot of promise, but I can see many ways this can go wrong.

In the last 2 years my partners and I have worked on and tried to sell a product we built at a our previous company. This product has been in development for 5 years (it’s been in production for 3 years). In those 5 years Java and it’s tools have matured greatly. If we had to build it (or a project of it’s size) from scratch today, it would probably only take 9 months and most of that would focus on the data model. I’ve personally learned a lot about software development in the last five years. But the last 18 months has been about selling. Our conclusion: selling software is hard, and selling enterprise software is nearly impossible. That’s why for the last 3 months we’ve been focusing on consulting.

Consulting is nothing new for us; we’ve done it in the past, and given our results, we’ll certainly continue doing it. I’ve more or less finished a prototype of a medium sized website with a lot of complex features built in PHP, IT mandates that the finished site be built in dot-NET (Doubt I’ll be involved in that). I’ve got a few upcoming sites that are going to be PHP based. I’m working on a Ruby-on-Rails based site. I’ve tinkered with NASA’s World Wind Java SDK for a part of project. And I developed a prototype application for the PepperPad 3. Oh, and we’ve load tested, and did code reviews for a few applications we didn’t write (much better than being on the receiving end).

In other words it’s been a busy few months.

Why Consulting? or Web Start is Killing Us

Our product is built in Java, it’s a three-tier, rich-client, Web Start distributed enterprise system for insurance companies. If you can believe the articles at JavaDesktop this sorta thing has been coming into vogue has the last few months. We when started this thing five years ago, no-one was doing Web Start enterprise clients. I still don’t think that many people are doing them.

Guess what, Web Start rich-clients are hard to sell. Maybe it’s just in the insurance industry, which people always say is 20 years behind the technology curve, we have to spend a lot of time convincing people that our product isn’t client-server. We tell them you can run it from anywhere. We patiently explain to IT that there aren’t any upgrade headaches, everyone is always on the latest version just like a web-app. We tell them that our software can do more (and in more productive ways) than most web-apps, but AJAX is making that less true. Most customers don’t care that maintaining one code path for Java means more solid software that doesn’t depend on the whims of browser vendors. Basically, you spend a lot of time/energy selling web-start just to have people go “Yeah, I don’t know. It looks client-server.”

Occasionally, you’ll come across refugees from web-apps. They love you because you’re transmitting only the data (mostly) over the wire in a binary format instead of bloated plain-text with markup. They love the power of rich-clients. They know that running mission critical applications as a script in the same in same program you use to access every other service is begging for security exploits or other headaches. They know HTML wasn’t made for applications. Then they get overruled by someone higher in the corporate structure.

So now, we’re focusing on consulting, that means I don’t play with Swing as much these days. Sure, World Wind uses some Swing (but mostly JOGL). The Pepper Pad doesn’t use much Swing but it can. But mostly we’ve using web technologies. They work well enough for “casual use” applications. What’s “casual use” for some people, is mission critical for others. That said, I still think adobe is crazy for working on a web version of Photoshop.

Anyway, on to silly comments about server software only the most bored geeks would read.

PHP

I really like PHP. Sure, PHP has got it’s issues and quirks, but when you don’t want to be limited by a framework and you need it done quick PHP is the way to go. The biggest benefit of PHP is that no matter what sort of hosting solution you have, it has a 99% chance of supporting PHP. If you’re using Java, dot-NET, or even Rails, your hosting options are more limited. Yes, if app/site gets very popular you will need dedicated or co-located hosting. But, when you are small, a shared-hosting plan can serve you just as well, in most cases, while you are still feeling out your audience and working on your offering.

Ruby on Rails

I have a love/hate relationship with Rails. Once you commit to learning the framework, Rails is a joy to use. Ruby is a great language. The hate comes when you deploy your app. Rails isn’t fast and if you deploy to shared-hosting, even a “dedicated” box that serves a few other sites using other server software, then Rails can’t have it optimal configuration. I hope Ruby get faster at launch time and at runtime and that Rails gets faster and easier to deploy (webserver/Rails integration) because I’d REALLY like to use them more. Just to clarify: it’s the setup of a production environment that I don’t like. Once the environment is setup, actual deployment is pretty painless. Except, sometimes your production environment doesn’t automatically pull in the same modules as your development environment. While some shared-hosting providers allow Rails hosting, it’s not really fast enough to do more than providing clients with a sneak preview during development.

.NET (aka dot-NET)

Um, yeah, dot-NET. My experience thus far with dot-NET is from the outside looking in. I helped on a code and security review of a dot-NET project. We also did load testing and polish on a dot-NET project. I found and fixed a bug in dot-NET project after the developer gave up searching. I had always assumed that dot-NET was more of a application framework, but apparently not. One of the projects used a third-party Object-Relational Bridge and the others passed raw SQL statements to the database (like with PHP). It appears that dot-NET generates javascript for you, but this causes more issues (like postbacks) that don’t exist in other frameworks. In general, it seems dot-NET doesn’t do you any favors and tends to get in the way and cause problems. In other words: dot-NET is platform/framework made by Microsoft, the same company who brought you MFC. Like I said earlier, I have limited experience with dot-NET, so take my comments with a grain of salt.

In case you are wondering how I can do code reviews and security reviews in a language/platform I don’t use: It’s simple. Most web-apps have a similar structure, they have mostly the same issues and limitations, and they use the same protocols regardless of language and platform. If you take unfiltered user input and slap it in a SQL statement or on a web page, you will have security issues. Logic works the same way in most languages, it is only the syntax that changes. Understanding control flow and edge cases is far more important for reviews and debugging than knowing the language inside and out.

Server Side Java

As consultants, we haven’t had much call for server-side Java yet. I think, it’s because mostly Java is used in IT shops for much larger projects/teams than we’ve been getting. Start-ups and small companies prefer PHP, Rails, or something else. Java isn’t sexy anymore but it’s still very functional and delivers good resource utilization on the server. It’s all about using the right tool for the job. IT departments tend have the “I have a hammer, everything is a nail” mentality — so if they have Java programmers, everything is Java; if they have dot-NET people, everything is dot-NET. I still think Java is the best solution for a large project but it would be hard to recommend for medium or small sized projects.

For some of my work, I often need a JTabbedPane with a close button. Many of those I found were either not free and usually completely custom components that only look right on Windows or with their bundled look and feel. So far, the “best” code I’ve found is from a javaworld article. But it has it’s own problem’s.
(Continued)

I was playing around with an idea today and wrote a little utility to create harder to break passwords based on normal passwords. The strength column is just a relative amount of time it might take a hypothetical brute-force algorithm to crack the password. It’s packaged as jar file, which means on a Mac (or a windows-box with Java 1.4.2 or above installed) you can double click on the jar file to start the app. You can grab the jar file here.

*Update*
I’ve setup a page for it. Click the Password Creator link under Pages on the left.

I’ve been testing some assumptions we have always held about moving data using EJBs (and RMI) and what I’ve found is not exactly what I expected. In the places I have worked, we held the belief that Serializable, by default, sent too much information over the wire and that it was slow. This seems to be a mixed case.
(Continued)

I’ve been working on a framework for real-world swing apps (business apps). While there are some existing forms libs, they are mostly layout managers. there aren’t many projects focusing on making real swing apps easy to write by taking care of moving data between objects and widgets, providing standard dialog templates, etc. I’m working on a framework that does those things. It is evolving with code I’m writing for a client, once it settles down a bit, I’ll open-source it. I’m also trying to incorporate as many swing best-practices as I’m can find. So far, I using trampolines, and ExceptionListeners to name a few.