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.

I’ll keep this short. I got leopard, been using it for two days. Not as smooth an upgrade as Tiger was. My iMac did fine. My powerbook “lost” it’s airport card, which a little googling fixed. Overall I’m pleased. Not in love with the new look and feel (yet). Too dark. Glad “brushed metal” is gone.

Stacks doesn’t offer the “fan” option when the dock is used on the side. Spaces is kinda cool in that linux-had-for-years-but-not-completely-kinda-way. I’m sure if the visual navigation used by spaces hasn’t been copied into most linux window managers yet, it will be shortly. Time machine is kinda fun. Making backups fun will hopefully get more people to backup their data regularly. Most everything works, except svnX despite downloading it’s leopard update. Command line svn works fine.

Then there is Java. When the list of 300+ features included ~5 talking about iChat’s tabs and 0 about Java I knew it didn’t make the release. And you know what, I don’t care. I have a confession to make as a Java Developer and a Mac User: I hate Java desktop applications. IF they are done correctly, you may not realize your using a Java app, but 99% of the time you will. File dialogs that don’t jump to a file when you type a letter. Wrong fonts. Text fields that can’t spell-check. Drag-and-drop doesn’t usually work. No working “Services” of any sort. Cut-and-paste is hit or miss. Then there is the memory usage. I mostly use Java as a way to write programs on the OS I like for people who use another OS.

As a Java developer, the only Java programs I use are the ones I write, an IDE, and some tools for database management. Since I switched to mainly consulting, I use Java less. I don’t miss it. When Java 5 came out, I was impatient for Apple to port Sun’s JVM. Java 5 had a lot of language features I wanted to use. When Java 6 was released, I was still writing Java code daily, but the feature list wasn’t impressive. I decided I could wait. I can still wait.

Java 5 on leopard is rough. Leopard, in general, still has sharp edges. These will be fixed. Java will probably take longer than the rest of it.

Please no email regarding Java. I don’t care how upset you are and I already know I’m arrogant, so stuff it.

Over the past few months I’ve worked on a project involving the Pepper Pad 3. I can’t say much about the project, but I’d like to talk about the Pepper Pad itself. The “Pad” is sort of typical of mobile PC-style platform; wireless network access, touch screen, camera, ~20GB HD, and a “use-it-as-last-resort” button-laden keyboard. The Pad’s special features are an IR blaster so it can mimic a remote and it runs Linux. Whenever I show the Pepper Pad to someone, their first words are “I want one!” But after playing with it for 10 minutes the reactions cools to “If someone gave it to me, I might use it.” Well, it should be noted that this device is aimed at the home consumer market, hence the IR Blaster and lack of spreadsheets or proprietary email protocols.

(Continued)

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.

I’ve mostly been working on stuff under NDAs that I can’t talk about. I can say that I’ve been using JGoodies Bindings alot — and I like it. I tried JGoodies Validation — it’s not up to the Bindings level yet.

But, I’ve been playing around with Xith3D on the side lately. And much fruitless searching for a Wii. All that and random personal stuff going on and makes for not much blog updating.

Been test-driving more server-side packages. After playing around with NBXDoclet and JBoss-IDE I’ve decided to use Hibernate Annotations and the plug Hibernate Tools into NetBeans using the Ant Tasks.

NBXDoclet

I first tried out NBXDoclet, a NetBeans plugin that provides support for XDoclet and Hibernate (and a lot of stuff). It provides a lot menu options and special dialogs for creating properties, getters, setters, and the XDoclet markup to make “Hibernatable” POJOs. Ran into some bugs when trying to create an association. There is not much in the way of documentation, but the Flash demo gives you most of what you need. This project shows promise, but face it, XDoclet is not the wave of the future.

JBoss-IDE

JBoss-IDE is a set of plugins for Eclipse. After using NBXDoclet, I had high expectations for JBoss-IDE. I was let down. I found the whole thing rather confusing and under-featured. This is partly because I don’t want to reverse-engineer a database. I’d much rather take my code and a database driver and generate the schema.

I had used Hibernates Ant Tools on previous projects (many versions ago) and the “IDE” didn’t really seem to offer much beyond features of the ant tools.

Hibernate Annotations and Ant Tools

So, I went back to NetBeans and tried the new jdk1.5 annotations. This is the way to go, you can use which ever IDE you want (as long as it supports annotations) and get code completion for the annotations without waiting for someone to build/debug/update dialogs.

Integrating the the Hibernate Ant Tools into NetBeans is relatively easy. I created a seperate ant file for the hibernate stuff. Created a library in NetBeans Library Manager to house the Hibernate Tools jar files. Imported the NBUser properties into my new ant file and used the classpath setup for hibernate tools. Tested the whole thing from the command-line to get it working. Then I changed to target name to “-post-compile” and included my new ant script in the projects ant script (include it BEFORE the build-impl.xml file). So now when I compile, it creates a new schema and documentation. I even tried generating a Seam application.

The sticky part is a small bug. One of the jars included in the hibernate tools is the wrong version. And to get the seam application to deploy, you need to use a nightly-build of the hibernate tools. And be sure everything (Ant and JBoss) are running under Java 5.

Once the EJB3.0 and J2EE1.5 parts of JBoss become more stable, it would be rather easy to wrapper the libraries and provide a few file templates to create a full-blown JBoss/EJB3 NetBeans plugin.

I need to post more often, sorry. I’ve been doing more Java development lately, actually mostly research because we may be rewriting some projects.

Binding

I’ve been looking into various Swing binding projects. There seem to be two big ones SwingLabs Bindings and JGoodies Binding. The SwingLabs project dropped off the list rather quickly because it is tied to the swingX components (which requires more setup in GUI builders) and it tries to do long-term persistence (we will use EJB3/Hibernate for that). Also there is no stable release at the current time (Feb 2006).

JGoodies Bindings however has had a few stable releases, a relatively small set of classes/intefaces to learn, and inspired by small-talk — These are all good things (at least to me). The major downside seems to be writing boilerplate code to glue the components to POJOs.

I don’t know, maybe the swingX components would allow us to write the code that glues the component’s data to the POJO with the GUI editor. Maybe we could automate the JGoodies code in some way. At this point, I haven’t used either tool.

WebStart EJB Clients

Have you ever written a WebStart EJB Client? No? After searching around the web, it appears not many people have. Using Web Services for our purposes is too slow and Web Services still has around 5MB overhead in client jars. Standalone EJB client jars weight in around 9-22MB depending on vendor. You also need upwards of 5 ports open. In the past, we took the hugh download size. Used VPNs when outside the local network to resolve the port problem. But now, we are looking for a better way.

That better way seems to be by avoiding the whole problem to begin with by using sevlets as front-end to your EJBs. Bright Side Remoting is an open source project I found yesterday. It seems to the answer to my problems. It has a small client jar and servlet and using the remote interfaces for your EJBs with dynamic proxies it uploads serialized data to the servlet and interacts with your EJBs. Again, this is a package I’m researching; I haven’t actually used it yet. There are a few wrinkles here, the demo doesn’t work. If click the “Home” link, you’ll see a message stating the company is no longer in business. The good news if the code is still available and under a BSD license.

In case you are wondering whatever happened to the demo app I was writing in the “Tiger Style” series, I stopped working on it after I found VoodooPad which has most of “first round” features I was going for.

Over the last month I’ve been looking at Ruby and Objective-C. After looking at Ruby for a week, I came to a couple of realizations. First, a lot of Ruby’s “relaxed” syntax could easily be fit into Java via an upgraded/alternative parser. Secondly, I can see how enclosures provide for some interesting options but I’m not really convinced they make code more readable as some people assert. Third, a lot of Ruby’s syntax is because Ruby, unlike Java, allows programmers to override operators. Forth, I realized that this is another language that will have server-side and command-line success but will likely never move beyond that. I know there are binding that allow Ruby to use some graphical toolkits, but I don’t see the move happening. Fifth, I realized that, knowing “the lay of the land”, I’ll probably never get a job or contract using Ruby.

The Objective-C book I ordered arrived today. I know I’ll probably never get a job or contract using Objective-C, but I can make shareware using it. I’ve written some shareware games in Java. Unlike a few Java games that recently received a lot of attention on JavaDesktop, mine are written in pure Java — no JNI libraries needed, no OpenGL, but they use pre-compiled native launchers. Even in the good reviews, I get beaten up for slow startup times. The Windows launcher has a native startup slash screen and I hate to tell the Mustang guys, but users do not find it be acceptable. Most of the third party Java game API lag behind or don’t exist on the Mac and since the Mac is my primary platform, I find this unacceptable. To take this games to the next level, I have to learn Objective-C to use either for the complete game or to make my own launchers and JNI. I used to program in C/C++ for Windows and Linux for 5 years before switching to Java. Objective-C and Cocoa should be pretty easy to learn. I look forward to experimenting with Cocoa but not to dealing with pointers and manual resource handling.

2005 has been a pretty good year for Java on the desktop, but for Java to really shine the “Virtual Machine” need to upgraded to something beyond the Windows 95 style interface that Java aims for. Between OS X, Windows Vista, and Windows XP with Google Desktop Search and Google Toolbar I think the path is pretty clear. Java needs APIs to integrate with the system’s search functionality. Java needs APIs to integrate with Bonjour/Zeroconf (Apple has an API, and check out Howl for a cross-platform native library). Imagine adding Zeroconf setup info to your app server and have your rich-clients easily find the server (or switch test and production servers). Java needs to integrate the system’s spellchecker into the Swing text components (I’ve had enterprise rich-client customers request this many times, but never had anyone request system-tray integration) and provide APIs for the spellchecker to be used in custom components or server-side tools. Java needs a much faster startup time for Swing clients and not just splash screens. A smaller memory foot-print and the ability to create objects on the stack could hurt either.

I have been writing a little project using FlexDock and thought I’d do a write-up. R.J. Lorimer’s tutorial on FlexDock is a good starting place, if you haven’t read it, you may want to read it before trying this. Most of the examples you’ll find create all the dockables and place them on the screen in a very static way. FlexDock offers a way to persist layouts between sessions; which will be needed if you plan to take your application beyond the demo stage. FlexDock has a very nice user’s guide, but the advanced features (views, perspectives, persistance, and themes) aren’t documented yet.

Download Demo Source Code (Zip file).

(Continued)

Most of the features added to Mustang I’ve felt non-committal on. But at last they are addressing a pet peeve of mine, the JTabbedPane. Read Alexander Potochkin’s post TabComponents in action. It’s stuff like this that make me wish swing’s release cycle was not tied to the JVM.