Subscribe to Updates

Click here to subscribe to new posts by email. We use Google FeedBurner to send these notifications.

Archive for June, 2015

PocketBible 3.2.3 for iOS Now Available

Posted on: June 2nd, 2015 by Craig Rairdin 5 Comments

PocketBible iOS IconApple has approved PocketBible 3.2.3 for distribution on the App Store. This version is a minor update intended to fix a few problems mainly on the iPhone 6 and 6 Plus. (We’re just going to pretend that 3.2.0 never happened.)

The new iPhones have larger screens. PocketBible has absolutely no problem with larger screens. In fact, exactly the same code runs on the iPad and iPhone. PocketBible asks iOS how big the screen is, then proceeds to fill it. Apple, however, has to protect you against apps that assume that the only possible size the screen can be is one of the known sizes as of the date of release of the app. So when we ask iOS for the screen size, it lies to us and tells us the size of the iPhone 5 screen. Then it multiplies the pixels by 1 + a small fraction and blows our user interface up to fill the screen.

The result of this “lie and blow up” strategy is a blurry app, as you can see on the left, below (click for full resolution).

PocketBible on iPhone 6

On the left is version 3.1.0. On the right is 3.2.3 (misidentified as 3.1.1 in the picture above). Version 3.2.3 jumps through the magic hoop that tells iOS that we understand the larger screen size. The “hoop” consists of using a different method to display the “splash screen” that appears when you launch PocketBible. When iOS sees we are using this method, it knows that we must know about the iPhone 6, so it stops lying to us about the size of the screen and allows us to use all the pixels on those great new displays. As you can see, the screen shots were taken just two minutes apart. It’s literally the same PocketBible code displaying non-blurry text. (Can you tell that this frustrates me a bit? I’ll post a link in the comments with more ranting about this if you’re interested.)

One nice change in this version is that you can change the password on your account without being forced to delete your books and your user-created data. The previous version believed you were trying to log into a different account, so it forced you to delete your books and answer some hard questions about your notes, highlights, and bookmarks before it would continue. The new version realizes all you have done is change the password, so it doesn’t ask you to do any of that.

If you DO log into a different account, it will still ask you to do something about your user data so that it doesn’t get corrupted by being sync’ed to a different account, but it isn’t as insistent that you do it right away.

This all being said, you shouldn’t be switching user accounts. If you think you need to bounce between user accounts, talk to us so we can figure out what you need and solve it correctly.

Behind the scenes, PocketBible 3.2.3 is now using https: connections to talk to the server for all connections, not just the ones where personal data like passwords are being transmitted. This takes advantage of some security changes we’ve made at the site in the last few months and makes all your data more secure than it needs to be.

The App Store on your device will notify you about the update, or you can just go get it now.

Here’s the full list of new, enhanced, and repaired features in 3.2.3:

New Features

  • Recognize and take advantage of the increased screen size of the iPhone 6 and 6 Plus instead of allowing iOS to scale the screen, which caused text to be blurry.
  • Support “custom Bibles” from BookBuilder which specify custom versification by referencing existing versification schemes. (Reader Engine version 1.073.)

Enhancements

  • Allow the Font / Size / Brightness setting window to rotate to landscape and to fill the full width of the screen.
  • Allow user to change password without forcing them to delete books and user-created data (notes, highlights, bookmarks, etc.).
  • Allow user more affirmative control over disposition of user-created data when logging into a different Laridian customer account.
  • Use https: connections throughout, even though no personal data is being transmitted.
  • Do a better job selecting italic and bold/italic fonts with families that support heavy, bold, demi, semi, medium, etc. variants.

Bug Fixes

  • Fixed a bug that caused text-to-speech reading to stop at an empty verse.
  • Table heading tags were getting filtered out of notes.
  • Opening a devotional with no existing start date would create a start date, overwriting the existing start date that might not have yet been sync’ed from the Laridian Cloud.
  • Fixed a memory leak when displaying lists of bookmark categories.

PocketBible for iOS is Back in the App Store

Posted on: June 2nd, 2015 by Craig Rairdin 25 Comments

PocketBible iOS IconIt appears this story is old news now. 3.2.3 is available on the App Store. A few of you are still upgrading, so I’ll keep the article here for a while.

On May 18 we submitted PocketBible 3.2.0 to Apple for approval. On Thursday, May 28 they approved it and by Friday night it was being downloaded by our users.

When I saw it was available for me to download to my iPad, I updated my personal copy. I got the message I expected, that my data needed to be updated. I went to Manage My Data as instructed but there was no response from the program. I quickly hooked my iPad up to my laptop and ran the program in the debugger. It turned out the Manage My Data screen was being built, but as soon as it was displayed, it was being dismissed by iOS so the user never saw it.

I tried deleting and re-installing to no avail.

During this process, Facebook notified me of some messages from a couple people who I know to be active PocketBible customers. When I visited Facebook I found there were several users having the same experience I was.

I posted a status update to our Facebook followers instructing them not to download the update to their iPads (the program was working fine on my iPhone). After a few more minutes of testing I realized there was no way to work around this and that I was going to have to stop it from being distributed. Unfortunately, Apple does not offer an immediate “off” switch. I pulled the app from the App Store but it would take 24 hours to fully take effect.

I posted a message on the home page of www.laridian.com and wrote a blog article to explain what I knew about the problem. I set up a response on our tech support ticket system that pointed affected users to the blog article for more information. I pulled the update announcement I had made on Thursday from Facebook and our blog. I posted a status update on Facebook pointing to the blog.

Over the next five or six hours I tracked down two related problems in the Apple code. I was able to fix one of them fairly easily because the 15 places in the code that were affected were all in the same file (or, for you programmers, the same class).

Other problems were related to UIAlertView (messages that pop up in the middle of the screen, usually with an “OK” and a “Cancel” button) and UIActionSheet (windows that pop up from the bottom of the screen and contain a simple caption and a column of buttons). I found these to be used in 294 places in the code. Each of these instances had to be reviewed to see how to best work around the problem. In some cases, I changed the implementation to use an alternative method of doing the same thing. But in most cases there was no better alternative.

After doing some research on the Web (programmers use a site called stackoverflow.com to confer, converse, and otherwise hobnob with their fellow wizards) I found a good work-around that required only a simple change to the code in about a dozen places.

By Saturday afternoon I was ready to put the program in the hands of some beta testers. I posted a call for testers on the blog and on Facebook. I knew this would be tough going into Sunday morning, but I got a small number of testers from around the world to run the program through its paces. (I apologize to my fellow church members for taking a few minutes during the announcements to pull out my laptop, add three new beta testers to the provisioning profile, re-sign the program and upload it to the website.)

Interestingly, the only problems they found were bugs that have probably been in PocketBible since version 2.0 or maybe earlier. I made some effort to fix those but under the circumstances didn’t want to take more time than necessary to get the program back up on the App Store.

By Sunday evening, about 48 hours after discovering these debilitating bugs, I was ready to upload the program to the App Store. At the same time, I filed a request for expedited review with Apple. It took them 10 days to review the last version; they’ve taken as little as 2-3 days in the past. I was hoping they’d agree to expedite it, because even after it was approved it would take 24 hours to propagate to all of Apple’s servers. Apple approved the expedited review on Monday morning and an hour later the app itself was approved.

By Tuesday morning everyone was seeing the update (version 3.2.3) and reporting that it was working.

I apologize for the inconvenience. Here are a few FAQs:

What are the symptoms? “Manage My Data”, “Shop for Bibles and Books” and many other menu items don’t do anything. This is especially problematic, since the program tells you that you need to go to “Manage My Data” to update your data due to the program itself being updated. But Manage My Data doesn’t work. Other selections, such as “Copy Passage” and “Register Now” cause the program to crash.

Version 3.2.0 seems to be working on my iPhone. Should I be worried? The problem seems to be limited to the iPad.

Should I remove the program from my iPad? No. When you download the fixed version (3.2.3), it will overwrite the bad version and everything will still be there (books and user data). It is OK to leave it installed and even run it. It’s just that certain functions are disabled. You might also have it crash if you interact with any pop-up choice boxes like the registration prompt. Just leave it installed for now.

Why does PocketBible require you to go to Manage My Data anyway? Previous versions of PocketBible tried to maintain the integrity of your user data (notes, highlights, bookmarks, etc.) by detecting when you have logged into a different account, then asking you to say how you wanted to handle your existing data with respect to the new account (i.e. replace your local data with the data on the server or merge your local data with the data on the server). Unfortunately, it assumed that simply changing your password meant you were logging into a new account. This new version of PocketBible uses the same technique as PocketBible for OS X, which records the customer ID you use when you sync your data, then compares that customer ID to the one you are logged into. That way you can change your password or even log out and log back in, and PocketBible won’t get confused. Since the old version did not keep track of your customer ID, and since you may have logged in with your email address instead of your customer ID, PocketBible has to log into your account and ask the server for your customer ID. This is quick and painless — unless you can’t get to Manage My Data to do it!

I’m a programmer. What’s really going on? Apple changed the way that UIPopoverController, UIAlertView, and UIActionSheet dismiss their views. In each case, we previously could assume that after dismissing those views we could display another modal view or otherwise act as if the view was gone (whether it was actually gone from the display at this point is irrelevant — I know that takes another cycle through the run loop). But some recent update to the SDK made it so that dismissing UIPopoverController resulted in any modal view displayed after that to be dismissed along with the requested UIPopoverController.

UIPopoverController does not notify its delegate when it is programmatically dismissed, only when it is dismissed by a tap outside its view. So we have no way of knowing when it is done. There are various techniques to discover whether or not the view has been dismissed. I chose a very simple polling technique that doesn’t make assumptions about whether or not it takes only one pass through the run loop, as other solutions do. For UIAlertView and UIActionSheet, I changed the delegate method I use to act on a button press from the “button pressed” delegate method to the “dismissed with button press” delegate method. This assures that the view has been dismissed before we continue.

 

©2017 Laridian