Thanks for your comments on my last post. They were very informative and confirmed a number of things that I was thinking about the Android platform as a relative n00b. My only disappointment is that nobody commented on my really cool graphic of a silhouetted Android android listening to his iPod and dancing like one of those Apple ads. Oh, well.

One interesting overall observation was that comments tended to come from people who were more than techie, more than early adopters, but were developers themselves. This is consistent with the perception that Android is a more technically complex platform as compared to iPhone. The comments bore this out as well.

I summarized the comments this way. I divided them into comments from a consumer perspective, those from a programmer’s perspective, and comments related to unique features of the platform that we should look at.

Consumer Perspective

• Android Pros
  • Hard buttons (menu, back, search, etc.)
  • Apps are more collaborative
  • Implicit multitasking
  • Widgets
  • More customizable
  • Free integration with G-apps
• iPhone Pros
  • Apps are more polished
  • Apps are more similar - easier to learn
  • Overall easier to use
  • Apps are more trusted (Apple-vetted store)

Programmer Perspective

• Java!
• Simple background processes
• Other minor programming tasks may be easier to handle
• No App Store police
• “Intents” to communicate with other apps
• Ability to install outside App Store

Unique Features (not already mentioned)

• Speech-to-text; text-to-speech
• Publish a “Look up verse” intent
• “Verse of the day” widget

I, too, like the hard buttons. Right away I’m thinking we don’t have a toolbar like the iPhone app but instead rely on the menu button to cause a standard menu to be displayed. From there we can use a “more” button to expand the range of options that can be chosen from the menu. This will simplify the ui and provide more space for text without having to change any settings like you have to do on the iPhone.

I definitely agree with all the iPhone “pros” that were pointed out. There are small things about the iPhone that just make it feel better. For example, the little bounce you get at the end of a list to indicate that you’re at the end. You don’t notice how nice that is until you don’t have it on Android. And overall the operation of the device feels smooth and effortless.

I’m not a flaming Java fan yet. I’ve been programming in C and C++ for about 28 years. While Java is a descendant of C++, I don’t agree that the differences are necessarily better. They’re just different. For example, while I agree that there’s no real reason to separate the interface description of a class (i.e. the C++ .h file) from its implementation (the .cpp file), putting them together (in the .java file) necessitates the use of a separate “JavaDoc” tool to pull documentation out of the code. In C++ your .h file serves as the class documentation and typically contains no implementation to get in the way — it’s all about documenting the interfaces to your class. Again, not a big deal, but just different.

I’m also not sold on the necessity of eliminating the unsigned integer types. Seriously? I use unsigned ints all the time to indicate specifically that I don’t expect this value to be negative and to subsequently double the range of values that can be stored.

On the other hand I love the fact that the bit-width of each of the integer types is fixed by the language. We share code between several platforms and compilers and have to define types like “Int32″, “Int16″, “Int8″ and their “UInt32″, “UInt16″ and “UInt8″ counterparts for each platform so the shared code will be guaranteed to work right.

And it’s probably the bit-twiddler in me, but I’m not fond of garbage collection. I realize some of you n00bs don’t know how to manage the memory you allocate, but we experts don’t have a problem deleting everything we allocate with “new” and not leaving pointers dangling or memory orphaned. The idea of having a process fire up at some undetermined time and take some undetermined number of processor cycles to do memory management is disturbing. Sure, it’s convenient and this is the last time I’ll complain about it, but I’m just saying it’s disturbing.

Thanks again for the input. I’ve closed comments on the other post since I used this one to summarize them, but feel free to comment here.

OK we’ve been playing with the Android for a while now and have begun to get a feel for it. After spending the last couple of years developing for the iPhone, we have begun to develop some opinions on how the two platforms compare. But today I’m interested in yours, because it will help me shape the way I think about certain aspects of implementation of this app. If you have significant experience with both Android and iPhone, I’d like to hear what you think of the two platforms.

If you gave up iPhone for Android, I’m not interested in how you were treated by AT&T or how bad their coverage or 3G performance is in your area or how much their data plan costs — that doesn’t help me get my head where it needs to be. Instead, I’m looking for your reaction to the platforms themselves. What makes one or the other better? Which is more pleasant to use and why? What makes the applications for one better than those of the other?

Again, the fact that Android is experiencing rapid market share growth is irrelevant to this question. The fact that iPhone is only available on one carrier doesn’t matter. The fact that you can get Android phones from a variety of manufacturers won’t help me. I’m looking for your reaction to the look and feel of the operating system and the best apps on each phone.

In order to be relevant, you should have more than just passing familiarity with both platforms. I’m not looking for input from those who are die-hard fans of one platform but who have only passing knowledge of the other. I’m hoping to find a few people who have spent a couple months or more using each of these platforms as their primary phone and who have purchased a few apps for each.

Along the way you’ll pick up our opinion I’m sure. But right now I’m looking for yours. Thanks for your help.

Alright, let’s start talking about Android. I’m interested in your feedback on a few things.

Our plan is to release something as soon as it’s usable in any fashion, then to keep releasing updates as new features are added until we get to the point where a relatively full feature list is in place. I’m interested in your priorities — what makes for a good first release, and what order should things be done in?

At this point we haven’t done anything to lock ourselves into a minimum Android version. Any suggestions? What’s the minimum version we should support?

Any features that make sense on Android that we haven’t done on other platforms? I’m thinking about features that might be unique to Android that make certain features in our program more possible or necessary.

You’re going to continue to hear us talk about iPhone and other projects going on here but never fear; we have time carved out for Android development and it will be moving ahead. Thanks in advance for your input.

We’ve received a lot of comments here in the blog and via email about Android. You obviously are interested in a version of PocketBible for Android and that is exciting. We’re interested in a version of PocketBible for Android, too.

The way we see it there are six important mobile platforms right now:

1. iPhone/iPod Touch/iPad
2. Android
3. Blackberry
4. webOS
5. Windows Phone 7
6. Symbian

We have a product for iPhone. It has rather quickly become our flagship product, given the demise of both the Palm and Windows Mobile operating systems. (Both Palm and Microsoft have abandoned their legacy operating systems in favor of webOS and Windows Phone 7, respectively. Old apps won’t run on these new platforms.)

We have a partnership with BEIKS on the Blackberry platform. It’s a great platform but it tends to be more of an enterprise device rather than a consumer device and as a result the demand for third-party software, especially in our niche, is less than what you might expect based on the size of its market.

We have a partnership with Bits of God Software on webOS. We decided not to do our own development for this platform because its market share is relatively small and it does not support traditional programming languages like C++ and Java that would allow us to leverage our existing code.

Windows Phone 7 is a big TBD. Obviously there are zero devices right now and it has zero market share. We include it in the list only because it’s Microsoft, so we anticipate it will be a player. In the meantime we continue to support and release new content for PocketBible for the old/current Windows Mobile operating system

Symbian has problems we’ve addressed before here in the blog. It’s very difficult to successfully market a Symbian product. We’ve attended more than one Nokia/Symbian developer’s conference. We know what’s involved. The problem is not developing, it’s selling. We don’t have any plan to do a Symbian product.

That leaves Android. I can tell you now that we intend to develop a version of PocketBible for Android. But we think there’s more you need to know to understand where we’re coming from.

Sometimes I think people get the impression that we’re bigger than we are. On the one hand, that’s good, because it implies that we’re providing customer service at a level you expect from a bigger company, but on the other hand it can lead to unfounded expectations.

When it comes to product development, there’s just me and Jeff Wheeler here. We have some talented part-time employees who, while they’re skilled at what they do, only add up to the equivalent of a little over one more person. We use some outside contractors for content development (Bibles and reference books). That’s it. Needless to say, that limits what we can do.

Jeff and I used to work at Parsons Technology. I wrote the original version of QuickVerse and brought it to Parsons in 1988. Jeff and I had previously worked together and I hired him in to work at Parsons 1989. He eventually took over QuickVerse development and was the lead programmer for QuickVerse for Windows.

From about 1994 until 1998 when Jeff and I left, he had 10-12 programmers working for him. Most of those were working on QuickVerse. There was a similarly sized group of editors who created new content (Bibles and reference books) for QuickVerse. I had a small marketing group (two people) and a sales group (three or four people). All told there were about 30-35 people just in the Church Software Division. In addition to those we had access to telemarketing, direct sales, support, production and shipping, human resources, accounting, and other departments which we shared with the rest of the company. At our peak in the late 90’s Parsons had about 1200 total employees and the Church Software Division was about 10%-15% of the company’s annual sales. So you could argue that we supported about 120-180 employees.

You can do a lot with 180 people. If something new comes along, you can put a small team on it and get it done. You can’t do the same with three people.

In some respects this doesn’t bother us. We left Parsons Technology in order to be small. (See this article from Christian Computing Magazine which appeared on an old version of our Web site in 2001.) We’ve been big. We know what that’s like. We choose to be small. We enjoy what we do and wouldn’t have it any other way. But realistically, it affects what we can get done in a given period of time. We understand that.

We actually “started working” on an Android version of PocketBible a while back. But then Apple announced the iPad. We felt it was important to make sure that our existing PocketBible app would work well on the iPad. At first we were assured that would not be a problem (all well-behaved iPhone apps work on the iPad) but when we researched it further we realized we’d need to make some changes to optimize our performance on the iPad. We both dropped what we were doing and started work toward getting an iPad-aware version of PocketBible out the door.

This has proven to be challenging. We realized in order to take advantage of the cool new features of the iPad we’d have to re-architect the PocketBible user interface to better take advantage of the larger screen. At the same time, when we’re done the same code needs to run on the iPhone. So all of this has to be done carefully. (You’re going to love the iPad app by the way.)

So when I say “we intend to develop PocketBible for Android” you need to understand that doesn’t mean it will be done next month. It might not even be started by next month.

Furthermore, when we went from developing for Palm OS and Windows Mobile to developing for iPhone, we were able to bring along a lot of code from our previous projects because the iPhone “understands” the language in which it is written. We cannot run any of our existing code on Android. So we’ll be starting from scratch.

To put this in perspective, it took us about a year to release the first version of PocketBible for iPhone when we started with our existing code. It’s been almost two years now and we’re almost (not quite) done implementing all the features of our Windows Mobile app for the iPhone.

For Android we’re starting from nothing. I can’t say at this point how long it will take to develop PocketBible for Android. It’s probably not the case that it will take the year it took for the iPhone program plus the time to write the code we borrowed from our older programs. But at this point I can’t say.

While we are saying we intend to develop for Android, you also have to understand that we have lots of other requests and ideas on our to-do lists. Our Memorize! users would really like to see that app on the iPhone. Our PrayerPartner users are going to want us to port it to the iPad. So even once we start on Android, it might not be the only thing we’re doing.

This all helps explain why we don’t like to talk about what we may or may not do in the future. If we had told you on the day we started working on Android that we were working on Android, we’d have to tell you shortly after that that we had abandoned our work on Android to work on iPad. And now we’re telling you we “intend” to do an Android version but the schedule is unknowable. This won’t be a problem for those of you who are familiar with software development and understand what all is involved, but for those of you who are unfamiliar with software development you’ll probably get the wrong idea about the schedule — either thinking it will take us longer than it will or that it will be done sooner than is physically possible.

For a small company like ours these are exciting times. Back when Palm OS and Windows Mobile ruled the mobile space, we were riding pretty high. Things have changed quickly, and we’re working on responding to the changes. Thanks for sticking with us. We hope you’ll continue to do so.

We haven’t announced any plans regarding Android and Android phones.

You may be able to use our free iPocketBible.com service to access your Laridian books and Bibles on an Android phone using it’s Web browser and Internet connection. To try it, go to www.iPocketBible.com.

There’s only one trick: when used with anything other than an iPhone or iPod touch (such as an Android phone), two-fingered scrolling should be immediately turned off. After initially logging in to iPocketBible.com, select options and then set the Scroll Mode to One Finger Scrolling (Popup Menus). One Finger Scrolling uses the default scroll method of your browser, rather than the iPhone-specific scrolling, and also applies less constraints to the formatting to make it more likely to work with your screen size. To access the menu again, tap or click near the right side of the browser window. (You may find it easier to change these settings from a PC-based browser, rather than your phone.)

Remember, after changing to “One Finger Scrolling (Popup Menus)”, the toolbar will not be shown on the web page. Instead, tap or click near the right edge of the screen to access the toolbar.

I’ve been helping with technical support on and off this past week, and a recurring question has been something like this:

“Are you working on Bible software for the Android phone? When will it be available? Will it support ___ (insert your favorite feature here)?”

My response:

“We haven’t announced any plans regarding Android. Such announcements are usually made at our blog: http://blog.laridian.com.”

You shouldn’t assume that this means that we are (or that we are not) working on an Android product. It just means that we haven’t announced anything. If you read our blog regularly, you know that this is similar to what we’d said about the Palm Pre until we recently announced a partnership.

After giving this answer more than a few times, I saw one of Patty’s replies to a similar question. In addition to my response above, Patty also cleverly pointed out that our free iPocketBible.com service (www.ipocketbible.com) can be used from many web-enabled phones, and suggested that customers with a web-enabled phone may want to give it a try. While iPocketBible.com was designed for use with the iPhone, we’ve found that it also works from many Web browsers. There’s only one trick: when used with anything other than an iPhone or iPod touch, two-fingered scrolling should be immediately turned off. After initially logging in to iPocketBible.com, select options and then set the Scroll Mode to One Finger Scrolling (Popup Menus). One Finger Scrolling uses the default scroll method of your browser, rather than the iPhone-specific scrolling, and also applies less constraints to the formatting to make it more likely to work with your screen size. To access the menu again, tap or click near the right side of the browser window. (You may find it easier to change these settings from a PC-based browser, rather than your phone.)

Remember, after changing to “One Finger Scrolling (Popup Menus)”, the toolbar will not be shown on the web page. Instead, tap or click near the right edge of the screen to access the toolbar. This technique allows you to access all of your Laridian content via many Web browsers, whether on a Windows PC, a Mac, or a web-enabled phone.

So, what about Android? We haven’t announced any plans regarding Android. Our iPocketBible.com service may work with Android and other web-enabled phones. It’s free, so you can give it a try if you want to. Check it out at www.ipocketbible.com.