Category: Android

Android Developers Need to Speak Up

Published on by Nick Bradbury

I was really glad to see this post from the good folks at Pocket. They're saying what I've said a couple of times: Android is far easier to develop for than the tech press leads people to believe. Android's supposed "fragmentation" problem is a myth for most developers.

I'd like to see more Android developers do as Pocket did and help lay to rest this crazy notion that developing for Android means having to purchase dozens – or even hundreds – of Android phones to test with.

If you're an Android developer, you already know most of the "fragmentation" headlines are bogus. But people who don't develop for Android may actually believe these articles and think Android apps are impossibly hard to create because there are so many different screen sizes to deal with.

Yes, there are some really annoying things you have to deal with when developing for Android, but that's true of any platform.

So if you're an Android developer, write about your experience. Tweet about it. Tell your geeky Facebook friends that creating Android apps isn't really that hard. When you see some tech site trying to drive traffic with a BS fragmentation article, post a respectful comment about how different your experience has been.

Android’s Overblown Fragmentation Problem, Part 2

Published on by Nick Bradbury

A couple of weeks ago I said that while Android’s fragmentation problem is real, it’s smaller than some make it out to be. That post generated a good discussion on Hacker News, and I was really glad to see that since I’ve recently had to disable comments here.

One thing that was pointed out is that fragmentation is a very real problem for game developers, and I certainly concede that. There are plenty of other legitimate reasons to complain about fragmentation.

But most of the time when I see someone complaining about Android fragmentation, it’s either because they’re struggling to get their app to look good on the many different sizes of Android displays, or they’re upset about having to support so many versions of Android.

I came to Android development after years of creating Windows software, so to me those just aren’t a big deal. I’ve always had to support multiple OS versions and a wide number of screen sizes. Web developers are in the same boat – they have to make their apps work on an almost baffling array of devices, browsers, operating systems and screen sizes.

I think part of the problem with Android is that wasn’t until relatively recently that it was deemed popular enough to develop for. That resulted in a boat load of iOS developers and designers having to create Android versions of their apps.

These folks were used to developing for a very limited number of OS versions, and most of their customers upgraded to the latest OS very quickly. They also had to design for a small number of display sizes, which often meant they simply created 1x and 2x fixed-size graphics for their apps.

Suddenly they were faced with developing an Android app, where 1x and 2x graphics just don’t cut it. And they could no longer assume that customers were using a recent version of the OS.

To these people, fragmentation must certainly be an enormous issue – especially if they continued trying to design Android apps the same way they designed iOS apps.

The obvious answer is that they should stop doing that. Just like developing for iOS had an initial adjustment period, it takes time to learn the Android way of doing things. Developers and designers who are unwilling to invest that time just end up creating crappy clones of their iPhone apps.

To those folks, I can only say: remember when you bristled at seeing second-rate Mac ports of popular Windows apps? Remember how you felt about companies that treated your choice of OS as an also-ran?

That’s how you’re making Android customers feel. It doesn’t endear you to them, so they’ll seek out alternatives. They’ll switch to competitors who treat their iOS apps and Android apps as equal citizens.

But regardless of whether you’re willing to do that, can you at least stop complaining about "Android’s fragmentation problem" just because you have to support different screen sizes and OS versions?

There are legitimate reasons to complain about fragmentation, but those two issues are something developers have faced for many years with other platforms (and continue to do so). The fact that we have to do so with Android shouldn’t be that big a deal.

Android’s Overblown Fragmentation Problem

Published on by Nick Bradbury

It must be hard to be a developer that has to support thousands of different devices, with screen sizes ranging from tiny to enormous, running multiple OS versions on all sorts of hardware.

That’s why I’m glad I’m not a web developer.

By comparison, Android’s “fragmentation” problem is miniscule. It’s overstated in the tech press because it generates traffic.

I’ll grant you that it’s harder to support Android than it is iOS – there are obviously a lot more types of Android devices than there are iOS devices – but after a year of writing Android software, I’ve very rarely run into trouble due to fragmentation. And when I have, it usually hasn’t been a big deal.

So when you read about Android’s supposed fragmentation problem, take it with a grain of salt. Fragmentation is a problem, but it’s overblown.

Update: There’s an interesting discussion of this article over on Hacker News.

Android Apps Shouldn’t Be Crappy Clones of iPhone Apps

Published on by Nick Bradbury

I'm sure a lot of Android users have had this experience: you see your iPhone friends using some slick new app, and you wish it was available on Android. Then an Android version comes out and…

…it sucks compared to the iPhone version.

I'm not going to name names here, because some of these apps might be considered competitors to Glassboard and not even I'm that snarky (at least, not in public). But you all know what I mean.

It's like the iPhone developers finished their version of the app, and then one of them was forced at gunpoint to create the Android version.

The end result looks like an iPhone app, but it's slower. Buggier. Uglier.

It doesn't take advantage of Android's hardware buttons, nor does it use Android features like sharing and background services.

It doesn't have to be this way. Really, it's possible to create iPhone and Android versions of your apps and have them be of equal quality. Twitter did it. And I like to believe we did it.

The Android market is pretty huge, so why insult it with cheap knock-offs of iPhone apps? Treat it with some respect and it'll respect you back.

Android’s "Legacy" Nonsense

Published on by Nick Bradbury6 Comments

“You keep using that word. I do not think it means what you think it means.” – Inigo Montoya.

Lately I’ve noticed Google using the phrase “legacy apps” to refer to apps built for Android versions prior to 3.0.

But based on Google’s own data, almost everyone is using a version of Android prior to 3.0.

So “legacy apps” are ones built for the most prevalent versions of Android?

In Defense of Android’s Hardware Buttons

Published on by Nick Bradbury3 Comments

Lately I've seen a few posts criticizing the Android hardware buttons. I get where they're coming from – especially regarding the sometimes confusing way the back button is handled – but now that I've switched to Android, these buttons are among the things that make it so hard for me to use an iPhone again.

As an Android developer, I love that I can tuck actions into the menu button instead of having to use precious screen real estate for icons that perform those actions, as iPhone developers are forced to do.

Seriously, how many iPhone developers would love to stop fretting over where to place their settings icon, or their accounts icon, or their mark all read icon, etc.? Wouldn't it be nice to have a common place to put all those things so you didn't have to clutter your UI with them?

I'm also a fan of the much-maligned Android back button. Yes, some apps intercept the back button and make it act weird. I hate that, too – which is why I don't use those apps. Those crappy apps  aside, I like having an easy, consistent way to navigate between activities and apps.

Now, by this point iPhone users may have written me off as an Android fanboy, but that's not the case. There are plenty of things the iPhone does better than Android – most importantly the iPhone wins on overall UI consistency and attention to detail. But as both a developer and an end user, the hardware buttons make Android easier and simpler for me.

From Windows to Android with Glassboard

Published on by Nick Bradbury28 Comments

Earlier this year I got an offer I couldn't refuse. Several friends and former co-workers of mine were forming a company named Sepia Labs, and they asked me to join them. They planned to create a mobile group sharing app, and they wanted me to develop the Android version.

I've been itching to get into mobile development for a long time, but I didn't even own an Android, let alone know how to develop for one. Yet there was no way I could turn down the chance to learn mobile development while working with people I know and respect.

So I joined Sepia Labs, and we immediately set out to design a different kind of mobile group sharing app, one that values privacy above all else. The end result is Glassboard, which we launched today for Android and iPhone, and will soon be available for Windows Phone 7. I'm really proud of what we accomplished with Glassboard, and I hope you'll give it a try (and after you get it, this post will help you get started).

Now, I can tell you that switching to Android wasn't easy after almost two decades of Windows development. I had to learn a new language (Java), a new IDE (Eclipse), a new platform (Android) and a new programming mindset (mobile) in a very short time. Oh, and just to make it harder, I decided to do it all on a Mac. I guess you could say I was looking for a challenge :)

And a challenge it definitely was.

The first challenge was trading my iPhone for an Android. I've used an iPhone for several years, and my new Android felt unpolished and geeky by comparison. But I slowly warmed to it, and now I love my Android so much that on the rare occasion I pick up my iPhone I curse it for not having a back button.

The second challenge was learning Java. My usual approach to learning new things is to just jump in and get my hands dirty, but I decided not to do that with Java. Instead, before I wrote any code I read a ton of books on the language (my favorites were this one and this one). I had Java books all over the place – on my desk, next to my bed, in my car, and in every bathroom of the house. I wanted to really understand the language before I used it so I could design Glassboard correctly (and not have to redesign it a dozen times as I learned more about Java). Surprisingly, I liked Java right away. It does feel a little too object-oriented sometimes, and it was hard getting used to garbage collection and the C-like syntax, but it made sense to me. It's a very well thought out programming language.

Next I had to figure my way around Eclipse so I could actually write some Java code. Like Nick Farina, I absolutely hated Eclipse at first. I despised its strange, overloaded user-interface. I made up new swear words as I stumbled around trying to decipher its overwhelming array of menu items. But I've definitely grown to appreciate Eclipse. It has some incredibly powerful features that I haven't seen elsewhere, and it rarely gets in my way – in fact, it actually helps me write better code. And funny thing is, when I work on FeedDemon now, I wish that Delphi had the features I've gotten used to in Eclipse.

I thought my biggest challenge would be switching to the mindset of a mobile developer, but that hasn't been nearly as hard as I expected. I've written for years about simplicity, killing features and doing away with options, all of which are requirements for mobile development. Mobile development forces you to focus on exactly what your software needs to do, and I really enjoy that.

But developing specifically for Android has been a huge challenge. There's an awful lot to learn – intents, activities, AsyncTasks, XML layouts, services, BroadcastReceivers and on and on and on. Once you wrap your head around everything it all makes sense and fits together well, but getting to that point doesn't come quickly. And as is always the case, the thing that takes the most time is learning your way around all the gotchas. If you're just getting started with Android development, be prepared to spend a lot of time on StackOverflow!

Of course, I can't write my first post about Android without mentioning its supposed "fragmentation" problem. It is a problem, but it's mostly blown out of proportion. Desktop developers have always had to create software that works across different OS versions, different devices and different screen sizes, so the fact that you have to do that on Android isn't a big deal. But it is a big deal when different Android devices handle things differently – video playback and recording, for example, are challenging due to device differences, and getting video streaming to work reliably across devices feels impossible (as Netflix discovered).

All in all, learning so much new stuff in such a short time has been both thrilling and exhausting. I'm finally doing mobile development, something I've wanted to do for years. But take it from me: if someone offers you a job that requires switching from Windows to Android development and learning it all in a few months, stock up on the caffeine – you're going to need it!

PS: Hopefully this post explains why it's been so long since there was a new build of FeedDemon. I am still working on FeedDemon, and a new release is already underway.