Mobile apps: History repeating itself

December 9th, 2010

I recently came across an old web article called “Mobile Applications, RIP” by Michael Mace (formerly of Palm). This article proclaimed the death of native mobile applications, based on lack of compatibility and ease of development. The author proclaims the future of mobile will be in the mobile web:

The business of making native apps for mobile devices is dying, crushed by a fragmented market and restrictive business practices. The problems are so bad that the mobile web, despite its many technical drawbacks, is now a better way to deliver new functionality to mobiles.

We've seen this movie before

Since the article was written in February of 2008, 5 months before the release of the iTunes App Store, it’s easy to dismiss this as a prognostication gone horribly wrong. And looking at some of the figures, there are certainly things that happened that were unexpected: the number of native mobile apps exploded with the release of the iPhone SDK and Android SDK, and so far the number of apps keeps growing. But read the article again. Why was the native mobile app market so horribly broken in early 2008? Anyone who was there at the time knows that developing J2ME apps was difficult. Every phone had a different implementation, and more often than not applications needed to have different code and a different release for every phone.

Instead of the flash flood of developers moving to the mobile web, Apple made sure it was all diverted to the iPhone. Native apps changed from being on death’s door to the next big thing. And while some people have been making money at this, there’s really not many. The rest of crowd, already defeated by the App Store, moved onto Android as the next new ground to conquer. Here is where history is repeating itself:

We created a series of elegant technology platforms optimized just for mobile computing. We figured out how to extend battery life, start up the system instantly, conserve precious wireless bandwidth, synchronize to computers all over the planet, and optimize the display of data on a tiny screen. But we never figured out how to help developers make money.

Android is an elegant, developer-friendly system. It’s on track to beat Apple in market share, and it’s closing in quickly on RIM. However, it’s yet to prove that it can make developers money. And while the fragmentation is not nearly as bad as it was with J2ME, there’s no denying that it exists and it is a problem. And when the cost of developing a native iOS and native Android app becomes too great, where do you go? Well, you go to HTML5 and the mobile web.

Don’t misunderstand, I’m not proclaiming the death of anything. But it’s amazing to me that despite how different the mobile marketplace looks, we are still facing the same problems and solutions. Plus ça change?

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • HackerNews
  • StumbleUpon

The Tech Sector and Unemployment

September 11th, 2010

Good software engineers are good because they are constantly learning, constantly trying new things, and are constantly ahead of the curve.

The New York Times ran an article this week titled “Once a Dynamo, the Tech Sector Is Slow to Hire” that focused on the struggles of some in the tech industry who are having difficulty finding new work after being let go from their jobs. For everyone who has experienced a job loss in this economy, including me, it’s a sad fact that finding new work can be difficult even in the best of circumstances.

So why are recruiters constantly asking me if I know any “good people”? Shouldn’t there be plenty of them out there? It’s not that simple, as I’m certain that the market for engineers varies wildly depending on where you ask the question, so someone in Corvallis may not be finding any job offers while a recruiter in Seattle may be at wits end finding people to fill their positions. As the author writes,

The chief hurdles to more robust technology hiring appear to be increasing automation and the addition of highly skilled labor overseas. The result is a mismatch of skill levels here at home: not enough workers with the cutting-edge skills coveted by tech firms, and too many people with abilities that can be duplicated offshore at lower cost.

However, the very next paragraph suggests another potential reason:

That’s a familiar situation to many out-of-work software engineers, whose skills start depreciating almost as soon as they are laid off, given the dynamism of the industry. [Emphasis mine.]

This last sentence is what I have a bit of trouble with. It’s true that the tech industry is fast and, given the pace of mobile, is getting ever faster. But the pace of tech means that an engineer’s skills start depreciating even while they are at their jobs. The skills needed to succeed in the industry change quickly, and if you aren’t learning then you’re stagnating. If you’re stagnating, then when it inevitably comes time for your own search you may not have what the recruiters are looking for.

Got a good job writing C++? Hopefully you also know some Java, or better yet some Python, Ruby or some other higher level scripting language. Do you do databases? If so, then it might interest you to look into the current debate over NoSQL and see if that affects your marketability as an engineer. If you do find yourself out of work, then it’s the perfect time to make sure your skills are not depreciating by learning some new ones.

When my position was eliminated in July last year, I decided I wanted to learn Android. I wrote a simple app that integrated with a service I loved; that app is now used by over 10,000 people daily in the Seattle area. I knew my web development knowledge had holes, so I learned Django. I read developer blogs constantly to get back to the bleeding edge of technology. I still do.

Even in Seattle, the tech sector hasn’t regained the energy it had before the crash. It may never. But the demand for good engineers is still there. By keeping pace with the industry, and constantly learning and trying new things, you can help yourself get ahead of the others looking for that next opportunity.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • HackerNews
  • StumbleUpon

Whither the native app?

August 28th, 2010

Earlier this month, over 60 developers attended the inaugural Seattle Android Developer’s Meetup to network, meet fellow developers, and eat free pizza. In addition, the meetup included talks from one of the developers of the lock screen replacement GOTO and the adult-oriented app store MiKandi. The last presentation was an introduction and demonstration of AIR for Android by FLEX developer Dusty Jewett. (full disclosure: Dusty and I are currently coworkers).

It’s unfortunate the number of people who chose not to stay for this talk. I think a lot of people who are still relatively new to Android, or who are relatively new to mobile in general, may not concern themselves with frameworks and high-level languages like FLEX or ActionScript. Native apps are the way to go, right? Why write for Android if you’re not writing in Java, or maybe even C++ using the NDK? iOS developers, shouldn’t you be writing in Objective-C?

That may have been true a year or so ago. Today, browser support for HTML5 elements is constantly maturing, and JavaScript performance is getting better with each release of WebKit. The number of mobile web app frameworks is increasing. With AIR, you’ll be able to package a SWF directly into an APK without writing a single line of Java code. The new Netflix app for the iPhone uses a UI front-end implemented entirely in a WebView. Chrome OS is right around the corner, and with it an entirely new app store, where the “native” language is JavaScript.

Personally, I welcome this. If I can write a significant chunk of my app in a device-independent language like JavaScript, that’s code that I’m more likely to be able to reuse moving from the mobile web to Android, or to iOS, or to Chrome OS.

What does this mean for mobile developers? Should we be afraid for our jobs? Probably not. There’s plenty of stuff a browser can’t currently do, and many apps will probably want some level of integration that will warrant some device-specific coding. And anyone who can write Java or Objective-C can pick up JavaScript or ActionScript pretty easily — good developers will always learn new skills as different tools in their tool belt.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • HackerNews
  • StumbleUpon

Android’s Dashboard pattern and screen changes

August 9th, 2010

I’m on record here with my appreciation for the Twitter for Android client and the introduction of UX patterns for Android. In particular, the Dashboard pattern — the large grid of icons as the “main menu” of an app — is a good way of introducing users to functionality and easily tapping around various parts of an app.

Unfortunately many of these apps that use the Dashboard pattern do something really annoying: they prevent the activity from changing from portrait to landscape. This may be acceptable for people sporting a Nexus One, an EVO 4G, or any of the other phones with virtual keyboards. But what about those with a first generation Droid? What about all the rumored phones in the pipeline with physical keyboards?

Sidetappin'

Alas, one of the offending apps is, in fact, Twitter. The new version of Facebook’s app, while adding a cool photo scroll on the bottom, is another culprit. It seems that, rather than make these activities work well in landscape mode, these apps have taken the easy approach that “works” but provides a poor experience for someone who likes using their phone in landscape mode — and serious texters practically live in this mode.

Don’t let a good pattern be let down by half-done implementations. Let’s give some love to landscape mode!

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • HackerNews
  • StumbleUpon

What happened?

August 4th, 2010

I guess it has been summer in Seattle, I had a new job, and in my spare time I’ve been more focused on writing code than blog entries. But has it really been nearly two months since I’ve written anything here?

I am too much of a perfectionist, and the time it takes to write even a few paragraphs can seem to stretch out longer than I’d want. So my idea queue piles up, and every time I see this page I think to myself, “maybe next week.” The café project was supposed to prevent me from doing this.

Time to get back on the horse. Hopefully I can continue with my Android tips, but I have some thoughts about general software organizational stuff brewing as well. I just need to pretend it’s not summer anymore.

  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • HackerNews
  • StumbleUpon