Archive for the ‘iPhone’ Category

I think I’ve mentioned before that the “iPad Version” of PocketBible is going to be what Apple calls a universal app. It’s not really iPad-specific. It will run on either an iPhone or an iPad. It decides at run-time which user interface to present and which features to enable. This differs from our Windows Mobile apps, which decide at install time which configuration to install (generally, a “PDA” version or a “smartphone” version).

We’ve been doing our development work on the iPad because that’s where the new features are. Yesterday Jeff installed to his iPhone just to see how we were doing. Everything worked fine, but we ran into a couple places where we forgot to do the “iPad Test” and as a result the iPad user interface was running on the iPhone. The result was the smaller of the two screen shots below.

Five panes on the iPad. Nice.

Five panes on the iPhone with the font size set to 8 points. Ouch!

What’s cool is that it works fine. The tiny navigation overlays even pop up in each pane when you tap them in the center. It’s tough to hit the links, but then at 8 points, they’re tough to hit even with a full screen of text.

This points out a couple interesting facts about this project. First is that there are several features we created for the iPad that will “accidentally” start working on the iPhone, either in the next release or very soon after. For example, we’ll make it so you can open two panes (either two views into the same book or two books). And as I mentioned in connection with the video posted last week, some speed improvements that we made while developing for the iPad will affect the iPhone as well.

The other interesting thing is somewhat related. We share a lot of code between the iPhone, Palm OS, Windows, and Windows Mobile. So today when I was working on showing you a list of all your user-created notes, it was trivial to add the ability to search your notes because that’s a feature we added in PocketBible for Windows Mobile a couple years ago and it’s just been sitting in the shared code, waiting for a user interface on the iPad to expose it. (There won’t be any UI for it on the iPhone in the next release, but it could show up any time.)

The code that does note searching displays its results as a list of Bible verses. That is, if you have a note on John 3:16 that says “God loves me” and you do a search for “me” in your notes, you’ll see the text of John 3:16 in the results instead of seeing your note. So while I was in that code this morning I changed it to display the text of your note. In that case, the advantage goes the other direction — next time we build PocketBible for Windows or Windows Mobile it will automatically start showing the text of the note instead of the Bible in the search results.

I’m really liking the note-taking process on the iPad. With the new control panel, the entire application is still available while you’re writing a note. So just tap the “lock” button so your note editor stops synchronizing with the Bible text as it moves, and you can perform searches, follow cross-references, and copy passages without losing your place in your note. Leave that “lock” function active and you can follow a series of links from a note without having to go back to the noted verse and recalling the note. Again, this is an iPad-only feature in this case, since the iPhone is so much smaller. But it’s cool.

I don’t want to sound like an Apple zealot or iPad fanboy, but I’m starting to think the iPad is the platform for mobile Bible study. I know, I know — you’d like to make that decision for yourself. We’re getting close. It will be worth the wait.

Apple announced its long awaited iPad tablet device last week, and like you we were all anxious to see it.

What we’re being told is that it will run most iPhone apps unmodified. They will only take up about 1/4 of the screen, since the iPad screen is significantly larger than the iPhone. We don’t have any reason to believe PocketBible won’t run on the iPad, but we’re doing what we can to make sure.

While the SDK has been distributed to developers, it is only a beta and we are unable to build what Apple calls “universal apps” that will allow the same binary file to run on either an iPhone or an iPad. We also don’t have access to pre-production devices, so we can only run in the emulator that is built into the development tools. So we have some reason to believe that PocketBible will work as-is but can’t be absolutely sure at this point because we’ve never seen it run on a device.

There are some simple user interface changes we’ll be making in the short term to better take advantage of the iPad’s capabilities. In addition, there are some new capabilities in the iPad version of the OS that aren’t yet in the iPhone that we’d like to investigate — what Apple calls “Core Text” is at the top of that list.

It’s not obvious from the end-user point of view, but PocketBible pushes the limits of the iPhone’s abilities when it comes to displaying text. PocketBible is exactly the type of application that the iPhone OS was not designed for — that is, an app that does sophisticated text rendering. The new iPad, with its bigger screen and potentially more usable keyboard, invites applications like word processors that need sophisticated layout capabilities. PocketBible is in that camp.

This is not unique to the iPhone. Windows Mobile also lacks key text rendering capabilities that are present in its big brother, Windows on the desktop. For example, it’s not possible in Windows Mobile to accurately measure the width of a piece of text as it will be displayed on the screen. You can almost do it, but it doesn’t work right for bold and italics. So we’ve had to implement our own functions for this.

We could probably get into a lengthy discussion of whether or not this form factor is something the public will accept. I’ve seen everything from people who want it to replace their phone (assuming they can keep from knocking themselves unconscious when they answer it) to those who point out that tablet computers with full-blown operating systems have failed to capture consumer attention, which causes one to question whether a similar device with a mobile OS stands a chance.

That said, one of my long-standing complaints about devices such as the Sony Reader and the Kindle are that they don’t allow any kind of third-party software. (Or at least until recently when Amazon announced a “Kindle Developer’s Kit” for Kindle.) My Kindle is great, but it’s horrible for Bible study because the software simply doesn’t have the features you need to access an integrated Bible library, or even perform moderately sophisticated searches. Viewed as a souped-up e-book reader, the iPad may stand a chance. While it’s hard to imagine anyone beating Amazon’s selection of e-books for Kindle, if anyone has a chance of doing so it would be Apple.

The iPad could actually be the perfect electronic Bible study device. It’s just portable enough to be truly portable, while being large enough to facilitate convenient cross-referencing between titles.

From a developer’s standpoint there’s not a whole lot to complain about. It’s like a big iPhone, so everything we’ve learned about iPhone and Mac programming transfers painlessly to the iPad. We’re not crazy about the shortsightedness of some of their new features (“split views” being at the top of that list for you programmers) but we’ve also seen initial shortsightedness in the iPhone OS get repaired in subsequent releases. Unfortunately, like the similar issues that arose years ago on the Palm OS, by the time the official solutions are released everyone has already coded their own work-arounds to meet user demand.

What all this boils down to is that we fully plan to support the iPad and in fact enhance PocketBible over time to take advantage of unique iPad features. We think it could be an ideal Bible study platform for those who have the spare change to invest in one.

PocketBible 1.2.0 has been approved by Apple and is available in the App Store.

The new version wraps up what we call our “user-created data” functionality. That is, the program now supports the creation of notes, highlights, bookmarks, and the tracking of your progress as you read through devotional (daily reading) books. This is a fairly major milestone for PocketBible. Initially we weren’t even going to ship version 1.0 until these features were implemented. Our early alpha testers convinced us to ship as soon as possible and wrap up the rest of the features in a series of point releases, which is what we ended up doing.

There are other minor improvements to the program as well. In particular, we took advantage of the extra space in landscape mode and added two additional buttons to the toolbar: “Forward” (the “Back” button seemed lonely) and “Bookmarks” (gives you a quick path to your list of bookmarks). And check out the new, very colorful, Go TO Verse screen.

Mark today’s reading, current reading, or selected reading as “completed”

Title bar turns green for readings you’ve read; red for those you need to read

Today button now activates new Devotional menu when selected while a devotional is active. Gives access to devotional features including new reading progress view and settings

“Catch Up” function lets you quickly adjust your reading plan to put you back on schedule

Open Book screen uses color coding to indicate which devotional books you need to read today to stay on schedule

Progress tracking is optional

Added frequently requested “Forward” and “Bookmarks” buttons to the tool bar when in landscape mode (where there is room for more buttons than in portrait).

Color-coded the book name buttons in the Go To Verse “Bk/Ch/Vs” selection process. Colors correspond to well-known sections of the Bible (Pentateuch, History, Wisdom, etc.) to make it easier to spot a particular book.

Added more “short-cut” buttons to the Go To Verse spinner corresponding to the sections of the Bible mentioned above.

Minor updates to the Context menu for non-Bibles to remove inactive choices.

Improved handling of saving your notes when the phone rings or you get a text (or simply exit the program) to eliminate potential loss of data.

Next up is providing you a way to sync your user-created data to our server and from there to your PC and other mobile devices. As usual there will be other improvements included in each update.

If you have suggestions, send them to me at craigr@laridian.com rather than posting them here in comments.

PrayerPartner for the iPhone has been updated to version 1.0.1, and is now available on the Apple App Store. Search for “PrayerPartner” in the App Store, or try this link.

This is a free update for all PrayerPartner owners. If you’ve previously purchased PrayerPartner, then either iTunes or your iPhone (or iPod touch) will notify you that the update is available.

New Features in 1.0.1

In response to customer requests, an optional passcode (PIN) requirement has been added. The optional PIN allows you to protect any sensitive information that you’ve added to your prayer list. (The PIN applies to the entire program, preventing access to all prayer requests if the PIN is not known.) Simply turn on the PIN requirement and select up to a 4-digit PIN. PrayerPartner will then prompt you for this PIN every time that PrayerPartner starts.

Automatic saving of data when PrayerPartner exits, such as when the phone rings or a text is received, has been improved.

I guess I’m going to have to address this issue at some point, so here we go.

Apparently one of the more controversial decisions we made with PocketBible for the iPhone was to follow the other major eBook reader software like Kindle and eReader and present the text a page at a time rather than continuously scrolling. That is, to move through the text of a PocketBible Bible or book, you swipe right to left (or just tap on the right side of the page) to “turn the page”. The new page enters from the right.

The alternative is to present Bibles and books as a long stream of continuously scrolling text and allow you to use drags and flicks to smoothly scroll the text. This method is followed (with some variations) by some other Bible software programs.

You Only Think You’ve Seen Continuously Scrolling Text Everywhere

People tend to point to applications like Safari, which lets you flick around on a Web page to scroll up, down, left and right, and claim that “all iPhone apps let you flick to scroll”. This is true when you have a limited amount of text, but not when the text is virtually unlimited. For example, a Web page is a finite amount of text (and images and whatever). It can be rendered once into an in-memory buffer, then portions of that buffer can be moved onto the screen as needed. More importantly, the overall dimensions of the page are easily determined. The programmer can tell the iPhone “I’ll be scrolling around on a 1391- by 3287- pixel image of this page.” That way, the iPhone knows when you’ve hit the “top” or “bottom” of the page and can do that cool “bounce” animation it does when you try to go past the edges.

Even large scrolling lists — like your list of contacts or PocketBible’s search results list — have bounds that are easily determined. It’s easy to count your contacts or your PocketBible search results, multiply by the height of one contact or search result entry in the list, and tell the iPhone the result. So 25,000 search results times 80 pixels is 2,000,000 pixels. If you go past 2,000,000 the iPhone knows you’re at the end and stops asking for more (in this case it actually stops because you’re looking at the 25,000th item, but down inside the code it’s animating the end-of-list behavior based on the y-coordinate being greater than or equal to 2,000,000).

The iPhone needs to know how tall your view is going to be. The problem with the text in PocketBible is that it’s practically infinite in length, and the time it would take to calculate the height needed is probably measured in hours (or at least in minutes), not the milliseconds you expect when you open a book or change the font/size you’re using to display text. The iPhone needs to know this height and we can’t calculate it in a timely fashion.

There are ways around this, but because we can’t calculate the height in advance we’re violating a built-in assumption the iPhone has about scrolling views. So that means we have to code our own scrolling view or at a minimum do some nasty jury-rigging to fake the iPhone into believing it has a finite-length view when in fact it doesn’t.

You’ve probably run into apps like Facebook which shows you 25-50 items in a list then allows you to press a button to load more. Again, you think you’re seeing a long, continuous list but in reality you’re seeing a short, finite-length list and you have an option to see a longer, finite-length list. You just think it’s an infinitely long list.

When To Load the Text?

Because the text of the Bible or a reference book is so long, it’s impractical to load the whole thing into memory at once (both to determine its size and to have it available for continuous scrolling). So we use techniques that allow us to load the text in pieces. (In our case, one paragraph at a time.) The problem, of course, is that it takes just as long to load the whole book one paragraph at a time as it does to simply load the whole book into memory. To get around this, we make use of idle moments (such as while the view is “coasting to a stop” after a flick) to load some more text. Normally the processor isn’t doing anything during this time, so you don’t notice that we’re loading text at that time.

The problem is that it can take longer than that time to load a paragraph. And you may be furiously flicking through text, not giving us time to do any loading. In these cases, we end up using time that is normally spent to recognize your input gestures. As a result, the system seems to be slow to recognize your gestures, and the motion of the text gets jerky.

At some point, we have to draw the text to the screen, which also takes time. One option is to launch a second thread to draw text that has been loaded and decompressed. But since the iPhone has only one processor with one core, this second thread is no more efficient than the method described above (using idle time on the main thread).

Furthermore, there are limits on what kind of drawing you can do in a second thread. Because the iPhone is a relatively new OS and doesn’t have the maturity of, say, Windows Mobile (which, like iPhone OS vs. Mac OS, is also a subset of its desktop counterpart), there are significant missing components for drawing text in anything but the main thread. Apple assumes you’re going to do all your text rendering with its built-in Web view component. But it, too, is an immature component and doesn’t have all the features we need to support everything we need to do with and to the text. So they give us one really nice why to draw text, but limit it to only being used in the main thread of the application. The text functions that can be accessed from other threads are more limited in their scope.

A Little History

Our initial implementation of PocketBible used continuous scrolling. We released an alpha version (a preliminary release that was nowhere near feature-complete) to a small group of testers in January 2009 with the goal of releasing the finished product in March. Because of all the problems described above (and more), the scrolling was a bit clunky. I actually thought it wasn’t horrible once you got used to it, but the alpha testers hated it and sent us back to the drawing board.

For the next six months I tried variations on when to load text, how much text to load, what thread to load text in, when to draw, what thread to draw in, etc., eventually writing at least four complete, from the ground-up, implementations of loading, rendering, and scrolling text. Late in the process I threw it all away and started again and had a relatively good implementation. We released beta 1 and the testers weren’t happy with the scrolling performance.

This was pretty disappointing. We were tempted to just go ahead with this implementation, but when we tested with the newly released OS 3.0 the performance was significantly worse. Something had changed with the new OS and would have required starting over again.

What do the Other Guys Do?

At this point I paused and did a survey of other similar software. I wanted to see what kind of performance they were getting during scrolling, and if there was anything I could divine from applying a programmer’s eye to the use of their software. I opted to look at general ebook software like Kindle, eReader, and Stanza. I chose not to look at other Bible software because the general ebook readers have larger user bases and well-funded, professional development teams.

What I found was a constant use of a “paging” metaphor as opposed to “scrolling”. This was interesting. If they were “getting away with this” with their enormous customer bases then potentially we could do likewise.

User Fatigue and Reading Comprehension

Within a couple days I had a paginated user interface up and running and for the most part, the beta testers liked it. Sure, there were those who really wanted to scroll. But there were others who actually preferred the paginated approach. They found it required a lot less concentration on manipulating the text and allowed them to focus on reading. Their fingers weren’t in the way all the time. And when they tapped the screen they knew it was going to move exactly one page instead of flicking and having to figure out when/if to stop it from scrolling too far, then having to find their place.

This was encouraging because it gave us some very real benefits to the new approach. Paging required less interaction and less concentration on navigating, thus allowing more concentration on reading and comprehension. And the performance was adequate and the implementation simple.

At about the same time my daughter was complaining about a college class that required them to read hundreds of pages of PDF files from the professor’s Web site. The school made the case that this was part of their “green” initiative, but my daughter found that in order to easily read and mark up the text it was necessary to first print it, thus negating the green argument and costing her a fortune in paper and ink. (Ironically, whereas the school could easily have printed this material on a two-sided printer, my daughter could only print on one side, thus costing TWICE as many trees as the “non-green” solution.)

This led me to do some research on online reading vs. reading in print. It seems to be a consistent conclusion that offline reading (from paper) results in better reading comprehension. One of the reasons that was cited was that the eyes can easily go from line to line and from page to page in print, but when reading from the screen the eyes have to constantly adjust for the motion caused by scrolling. The difficulty of moving the screen to the next full screen of text resulted in the eyes and brain having to continuously re-locate their position in the text. The resulting diminished comprehension negatively impacts test scores and was one more point against my daughter’s school’s “green” initiative.

Interestingly, the results of this research could easily be applied to what we were doing on PocketBible. When you flick the text you have to stop and figure out where you’re at. When you turn a page you know right where to continue reading. If you avoid this by slowly scrolling as you read, your eyes can’t move from line to line as easily as they can when those lines aren’t moving. And your fingers get in the way.

So Where do we Stand?

In summary, the reason PocketBible doesn’t have continuous scrolling isn’t because we haven’t thought of it. It’s because we’ve tried several ways of doing it and none has resulted in acceptable performance.

While pagination started as a second-choice user interface, it turns out it’s used by all the large, well-funded, popular ebook reader software for the iPhone. And it turns out it has documented benefits when it comes to user fatigue and reading comprehension.

It cannot be argued that pagination is “not the iPhone way”. The large, continuously scrolling text often cited as examples of “the iPhone way” isn’t actually as large as our text. And there are lots of similar applications that don’t use scrolling as their user interface for books. So while it can be said that continuous scrolling is an iPhone way to interact with books, it cannot be said that it is the iPhone way.

I’m aware of the fact that other Bible software uses scrolling instead of paging. I’ve heard conflicting reports on whether they do this successfully or just “acceptably” in the opinion of their users. I’ve also heard that some do continuous scrolling within a chapter (thus avoiding the problem of having a large amount of text) but then have another gesture that means “next chapter”. This is great for Bibles but doesn’t solve anything for other types of reference books. And it creates a weird concept of “sometimes you flick to scroll and sometimes you have to do something else” to see the next bit of text.

I don’t have any insight into the other guys’ code so I can’t comment on why they may get acceptable scrolling behavior when we don’t. Maybe their standards aren’t as high. Maybe their code isn’t as feature-rich. Maybe they’re better programmers than we are. In the end it’s irrelevant. We are all playing the cards we were dealt. Knowing someone else at another table has a better hand than I do doesn’t mean I can win at my table. To continue but convolute the metaphor, you can either stay in the game with us or you can go play with someone else. We can’t control your behavior.

We have not disclosed our plans for any future features of PocketBible, other than to say we’re continuously working on it, and that the features you see in other versions of PocketBible will find their way into the iPhone version in the future. We have a long list of must-have features in PocketBible and a long-list of suggestions from all of you. We consider the must-have list to be the more important one at this time. We’ve been implementing little things from the suggestion list as we work through big things on the must-have list, but are prioritizing useful new functionality over simply changing the way things work.

Pagination is a feature that is not broken and doesn’t need to be fixed. While we may look at wasting another six months on scrolling in the future, we’ll do that at a time when it won’t cause other very necessary features to be delayed.

Before You Comment…

This article is meant to be informative, not to launch discussion. We already know that some of you would prefer to scroll rather than page through the text. If you’re just writing to tell us that, then you must not have comprehended this article very well. Try paging through it instead of scrolling.

Furthermore, this article summarizes some complicated programming issues into imprecise layperson’s terminology. Like a paraphrase of the Bible, there is a lot lost in the process. If you are not a programmer and think you have an idea for doing this in a way we haven’t tried, don’t bother to comment. Chances are good you don’t really understand the issues and I won’t be able to tell you that without insulting you. If you’re a programmer and are sure you know how to do this better than we do, I remind you you haven’t seen our code so don’t know what we’re working with, then ask you to send completed, working code to me by email instead of discussing it here where we’ll only confuse the masses.

Comments are moderated. I will remove references to other iPhone programs. I will remove feature requests and off-topic posts. I will remove links to other sites. I may remove other things I haven’t thought of.

I’ve been thinking all week I was just about done with this semi-major point-release of PocketBible for iPhone but then something else would leap out and I’d have to take a day and fix it. I thought I’d take a few minutes to let you know what’s coming in this update.

Notes

The major new feature is notes. You can associate notes with any Bible verse. Notes are independent of the Bible you’re reading. So a note on John 3:16 in the KJV also shows up on John 3:16 in the NIV.

Notes are indicated by a “Note” link at the start of the verse. Tap the link to view the note, or simply tap-and-hold anywhere on the verse to open the context menu and from there, choose to view or create a note.

Any references to Bible verses in your notes will be automatically linked. While viewing a note, just tap the reference to view the Bible verse. Notes are happy to be just plain text, but if you’re comfortable with HTML you can use most HTML tags in your notes. We provide a menu of HTML tags you can easily insert, and bold and italics are available from a toolbar in the note editor. So select the word you want to italicize, then use the <i> button to italicize it. No advanced HTML tagging knowledge required.

The note editor supports undo and redo. Few iPhone apps do, and for good reason. The current state of the text editing features on the iPhone is pretty primitive. It’s difficult to get access to everything you need to support undo/redo.

Pasteboard (aka Clipboard) Support

The other major feature is “Copy Verse” and “Copy Passage” (actually two features, but very closely related). Both are accessed from the context menu. Tap and hold on a verse then select Copy Verse to copy the verse to the clipboard. From there you can paste it into any app, or into a PocketBible note. Similarly, you can select Copy Passage from the context menu, then select the start and end verse you want to copy.

We save both a plain-text and HTML version of the verse on the clipboard. If your other app supports HTML you get really nicely formatted verses. There are options to control how and if verse numbers are included in the passage, and whether your notes should be included.

Rotation Lock

Finally, in terms of significant new features, we’ve added a simple rotation lock. Rotate the device into the position you want, select Rotation Lock from the Settings menu, and then you can lie down, stand on your head, or whatever it is you guys all do that requires rotation locking. Just an aside: This should be a feature of the device. It’s silly to ask hundreds of thousands of applications to implement it instead of doing it once in the OS.

Close the context menu after choosing to toggle Strong’s numbers on/off

Implemented underline and strike-through

Be more rigorous about the way we determine the type of the book. This will move a very small number of books from the “dictionary” or “commentary” section to “other” books.

In connection with the last change, send “look up” requests to “other” books so they can try to respond if possible. Again, a very small number of books are impacted.

Changed the title field on search results to truncate on the left instead of on the right so you can see the most detailed portion of the title in non-Bibles. (This makes sense when you see it but is hard to describe.)

And finally, I’ve fixed a few bugs:

Fixed proximity picker position in landscape mode

Fixed Spanish book names in both 3-tap and spinner go-to controls

Fixed OT/NT buttons in Spanish Bibles

Fixed reversed Hebrew strings

Ignore touches that come in while we’re in the process of going somewhere. Otherwise we can have weird zooming issues.

Release Schedule

I’ll post another blog article when I deliver this version to the App Store. It will be a couple weeks after that before it’s available for download. I just need to finish up the Help to cover the new features.

Next up: Daily devotional tracking and other features related to devotional books.

If you’ve been a Laridian customer for a while you know that our policy has always been to avoid talking about products that we are working on until they’re actually available. Starting with the Web-based version of our iPhone product (iPocketBible.com) we made an exception to that rule and openly talked about our development activities for iPhone. We continued that with the native PocketBible for iPhone. We did this as an experiment to see how it would work out.

It’s been an interesting experience. We’ve received many positive comments and suggestions on the blog and by email. Several emails, though, attacked both our products and our personal character, and criticized our programming and management skills. Needless to say, these both consume our time as we try to address the criticisms and drain us of enthusiasm for the project. Even the positive comments often result in lengthy email exchanges.

We’re at the point, especially with the upcoming version 3 of the iPhone OS, that we need to return to the old way of doing things and allow ourselves to work undistracted by both incoming emails and the pressure to release information to the PocketBibleiPhone email list. I’ve removed a few articles from our blog and disabled comments on others. We will return to a “no comment” policy with respect to products which may or may not be under development, and reserve the right to read but not reply to your emails.

We do appreciate your interest but hope you’ll understand our need to focus.

For those of you who have written expressing some confusion about a product called “pocket-bible” for the iPhone 2, no, that isn’t our product.

Yes, we do have a registered trademark on the term “PocketBible”. Our version of PocketBible for iPhone and iPod Touch is called iPocketBible but the trademark covers any software that is used to display the Bible text, regardless of platform.

We’ve had to deal with a number of trademark infringements over the years and so far they’ve all been handled very reasonably. We hope this one will be no exception.