Lifecycle of an Android Application

Every time I get a new gadget, something possesses me to try to write an application for it. It’s happened with dang near everything since the Newton, yet only a few gadgets have ever had a finished project. I tried the hardest on Symbian, but never came up with anything useful. I’d like to blame the SDK, but you should never blame your tools, no matter how much they completely sucked.

In October of 2008, a brand new T-Mobile G1 arrived via UPS, one of the first Google Android devices to hit the market. I had always owned smartphones, whether they ran Windows Mobile or Symbian (S60 or S80), but I wanted to get something that was easy to develop for, and would work well on my network. So, Symbian was out (hated the SDK), iPhone was out (Just started supporting apps, plus no one wants to be on AT&T), Blackberry was out (SDK even worse). Android seemed like a really neat, but young option. Being on the bleeding edge never scared me, it just usually screwed over other people.

So, approximately 3 days after receiving that G1, I downloaded the SDK, and started to use my extremely rusty Java skills to bang out a LiveJournal client for Android. It’s not as though I still really used LiveJournal, but I felt like it’d help me try out all of the neat APIs in Android. Web services, location tracking, image capture and manipulation, they were all there and usable. A shell of an application started to emerge around a series of mocked up layouts, and I was able to hook up login, posting, preferences, and user pictures in a short amount of time. ElJay was born, and I even wrote about it here. I’m amused at how proud I was that it was pretty complete after a few days — because it shows. Since I decided to dive right in instead of going through tutorials and example applications, it was subject to many of the first time Android developer errors. Screen rotation would lose settings, or interrupt a login, or interrupt a post. Web activity would throw exceptions that I never caught. Nothing was in a service, so switching applications or views would interrupt the same interruptables as above. Everything I did was in onCreate, so switching back to the application after Android cleaned house meant that someone would have to log in again. Sometimes, state wasn’t kept, so you’d post to no account at all. It was a barrel of laughs. I updated and updated until it was a mess of spaghetti code and generic exception catching. Android 2.0 finally broke it, and I didn’t care for a while.

I eventually pulled it from the market.

… until the screams entered my inbox.

A few weeks ago, I recommitted to ElJay, but instead of running through to try to fix it, I made the best and worst choice I could make, and started over. This time, I started it as if I were doing one of my Perl-based web applications, or writing a desktop application — I started with the back end. My first task was my XML-RPC interface, followed by my LiveJournal model. I created a unit test suite for those external interfaces. I created a suite for all of my display controllers. After a while, I got to the point where I had a decent unit test suite, and a few test accounts that passed the unit test suite. This process took a lot longer than the “few days” it took to bang out the first version, but from a system level, it worked well. It also helped me solve a long-standing bug I ran into in the first version, where the default Java XML library used by Android doesn’t handle some output from LJ very well. Hey, I could have saved myself from a rewrite! … Nah.


Only then did I start working on the user interface. This time, I could actually plan for exception handling, threading, the external service, the sync API, even basic user interaction. It also honors resolution independence properly, since I’m no longer using pixels as measurement. 😛 It’s amazing how much more confidence I feel in this application — not that I believe it’s bug free or foolproof, beta testing will prove that wrong within minutes — but that I can easily work with it, fix issues, and section pieces out for later. Things are getting really close now, and the beta rolls out in less than two weeks.

For those keeping track, the first version allowed posting with user pictures, security options, tracked your location, worked with tags and moods, and allowed you to save entries for later. The new one does all of that — and well — but also adds friends list support, attaching photos to your posts, and with any luck, manage your messages. I’m also throwing ads in, but they’re optional.

It does live.

Fun facts for hard times

When developing for Android, the default button height is 48 dip.

MooseX::Declare, TextMate, and TmCodeBrowser

Do you use TextMate?
Do you use TmCodeBrowser?
Do you use MooseX::Declare?

Must be a pain that nothing shows up the side pane when you start using it. It was for me.

Open ‘~/Library/Application Support/TextMate/PlugIns/TmCodeBrowser.tmplugin/Contents/Resources/.ctags.tmcodebrowser’ in a text editor. Add the following:

–regex-perl=/^[ t]*(class)[ t]+([^ t;]+)s*[ t]*[{;]/2/c,class,classes/
–regex-perl=/^[ t]*has[ t]+'([^ t;(]+)’/1/p,property,properties/
–regex-perl=/^[ t]*method[ t]+([^ t;(]+)/1/m,method,methods/

Reload TextMate.

Bask in the awesome.

Happy 25th Anniversary, Macintosh.

Twenty-five years ago today, January 24th, 1984, Apple offered the first Macintosh for sale to the public. Released with a huge amount of fanfare using arguably the first high-budget “Super Bowl Ad” during Super Bowl XVIII on January 22nd, Apple aimed to change the computing marketplace forever. Contemporary personal and business computers used a command line driven interface to operate, and programs written for these platforms followed the same type of functionality. IBM’s PC, Commodore’s 64 and 128, even Apple’s II series all followed the same idea, and few computers on the marketplace tried to change that at the time. The big contender, Apple’s Lisa, was a market flop, mostly because it was sold at over $10,000, 5x the amount of the average business computer at the time. Macintosh offered a 32-bit processor (on a 16-bit bus, but let’s not get caught up in the technicalities), 128k of RAM, a high resolution monochrome screen, and a mouse to control one of the friendliest user interfaces at the time. $2,499 was very steep in 1984, but it took the world by storm, and became the envy of every platform.

We got our first Macintosh in the fall of 1986, a smoke and fire damaged Macintosh 512K Enhanced, complete with an Apple HD20 (20mb hard drive!), a LaserWriter Plus printer and an Abaton Scan/300 sheet-fed scanner. My grandmother’s house had burned to the ground, and her basement tenant and friend was getting into desktop publishing — this was her machine. My dad took the machine in while she was relocating, cleaned the smoke damage out of everything, and powered it on. I remember hearing the chime the first time and watching it power up, and it was completely different than the Commodore 64 I grew up with. My dad let me play with MacPaint, and I was hooked. It wasn’t until years later that I realized my dad was letting me play on a setup that was $15,000 when purchased new in 1985.

That machine lasted me until 1993 as a full time machine. I learned Pascal, HyperCard, and MacBASIC on that machine. I did the best looking school papers and projects on that machine, using the scanner to include maps and other data, and using the laser printer to provide crisp, clean printouts. I had Aldus PageMaker and Microsoft Word to create brochures, flyers, and homework. I ran a BBS off of WWIV/Mac for a couple of years. I tried to squeeze System 6 and MultiFinder in the scant, un-upgradeable 512K of RAM. I got into the first BBSs with MacTerminal, and later, ZTerm, all with my Racal Vadic 1200 baud modem, and later, my generic Hayes-compatible 2400bps modem. I really, really used that poor machine with the warped, fire damaged vents.

To this day, that machine boots, hard drive and everything. The LaserWriter Plus and Abaton scanner were sold off by the next owner long before.

The machine taught me about typography, user experience, software development, and the appreciation of a great graphical user interface. I’ve had many PCs and Macs since, and they are exponentially better than that poor little FatMac I used to have. Without Apple’s leadership with that little machine, though, the computing world would be a far different place.

I just had to share.

Happy 25th anniversary for your crazy creation, you guys. Thank you.

For some reason, this amused me

This amused me. 🙂

Because you can’t tell a great hacker except by working with him, hackers themselves can’t tell how good they are. This is true to a degree in most fields. I’ve found that people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.

Rest in Peace, Mr. Butterfield

Jim Butterfield died last night at 1:30 in the morning, from complications from cancer. He inspired many a geek who hacked their way through Commodore 64’s in the old days. He certainly helped me explore the inner workings of computers, and he will be missed.

The sad thing is that he leaves with a whimper, when he was such an influential person in the 80’s, in that scene. Anyone who opened a copy of COMPUTE, COMPUTE’s Gazette, or RUN knows who he is, and how brilliant he was.

My best wishes to his family. Know that he left his mark on so many people, and he will be remembered.

The Comeback of a Language

Not sure what was going on with me this morning, but I think I was trying to pick a fight in #catalyst this morning. I was at work all of about ten minutes before I asked a simple question, amounting to: “Are there any plans to bring Catalyst to a wider audience?” Confusion followed, followed by a decent discussion. The general point I was trying to make is simple. If you ask someone who works near web development if they’ve ever heard of Ruby on Rails, chances are, they have. If you ask them about Catalyst, you’ll usually end up with a shrug. Those who are willing to listen further generally stop listening as soon as you say “framework for perl”.

There is a stigma attached to perl for various reasons — people view perl as unreadable, or slow, or hard to develop in on a large scale. Most people have a perception of perl that dates back to the late 90’s, coding against or Hell, back then, I was rolling my own CGI scripts so they were ‘lightweight’. God forbid anyone look at my code from back then. Perl was pushed as a rapid-development, but hacky language, and most people produced a lot of code that looked like line noise or otherwise, and that is what is burned into people’s minds. There is an unfortunate percentage of the current perl population that still writes kludgy one script wonders and calls it a web application, and that’s also bad for the community, in my opinion. Frankly, a language that holds contests on who can make the most unreadable code, or who can fit the most into one line, generally deserves that stigma.

The other side of the coin is Perl 6, the upcoming complete rewrite of Perl. If you Google for perl 6, you’ll find articles talking about its impending release dating back to 2001, yet we still don’t have a final revision. The bytecode interpreter is far from complete, and the closest thing there is to a working, usable interpreter is written in Haskell, another higher level language. The whole thing feels kludgy and incomplete to an outsider, and that’s probably because compared to other modern object oriented languages like Ruby and Python, Perl 6 is kludgy and incomplete.

So, disillusionment and wankery abounds when it comes to perl, and a lot of it is deserved. It’s a perception problem, and one that is almost impossible to solve. But, hell, I’m stubborn, and other people have made far inferior products rise from the ashes.

Those who remember a few years back realize that not many people were aware of or used Ruby before Rails came out, and a lot of old perl hands fell right into Ruby because of its similarities. I find Ruby to go against ‘what I mean’, so it’s a reach when I start pounding out any code. I was hoping to find an alternative when I stumbled upon Catalyst, and I’ve been hooked since. I think quite a few people would see the same thing, if they only knew what was there.

My plea to #catalyst was simple. Catalyst is a diamond in the rough, a flexible, fast, and powerful web application framework that is very easy to use once you get over the first learning curve. It is an excellent demonstration of modern OO perl development, despite any flaws or issues that still remain in the framework. The problem, however, is there is very little marketing or outreach happening, and without any kind of constant public opinion, the userbase stagnates and eventually shrinks, leaving frameworks like Catalyst to die on the vine. Someone within the Catalyst community, or even tangentally related to the Catalyst community needs to find a way to bring people back into the perl fold by making them aware of the strengths of the framework.

A few things would need to happen, in no particular order. Note that this is only my opinion, and I’d be happy to be told I was wrong.

  • They want their wiki moved from Trac to MojoMojo before they do any major wiki work. Fine, I’ll give that one.
  • Get some nice looking skeletons into the default Catalyst project template. Make it look pretty. For some reason, this actually works, and makes people want to do the same.
  • Catalyst’s primary development happens on mailing lists and on IRC. This should be outlined somehow within the wiki so creep doesn’t occur.
  • The primary focus of should be marketing and outreach — a bulletproof example of the stability and scalability of an application written in the framework, with easy to deal with tutorials and a complete set of hyperlinked documentation. Links should be given to external sites who use the framework, as well as third party Catalyst tutorial sites.
  • There needs to be a third party tutorial and development site! You can toot your own horn, but it’s hard to convince people that what you have works really well unless they can see other people getting together and doing things really well. The real championing of OS X doesn’t happen on, so the real championing of Catalyst shouldn’t be on Luckily, it’s not, as the site is a bore and makes the project look dead, as it is hardly updated.
  • Along with the third party site comes some community support. Bring people together. Show people to IRC, bring people to a forum. Get a forum of a couple of hundred and hold CatalystConf or something similar. The key to getting the product into the eyes of many is to show people that there is an active following behind it. Lesser languages and frameworks do it and give people confidence to continue developing. Check out Lasso and REALbasic if you have no idea what I mean.
  • Tell people you’re using Catalyst. If you run a site that is truly great, and starting to get public attention, mention the framework. The Rails apps are doing it. The PHP people just try to hide that it’s PHP behind it.

I’m not talking about zealotry, here. I’m not talking about Catalyst being the best or brightest, or that perl is the best or the brightest. I’m not talking about how Ruby, Python, or PHP suck (this time). I’m only talking about bringing a really great language and a fantastic framework into the foreground so people are at least aware of the options before they talk some smack.

Or maybe, just maybe, I’m completely full of it.