eReader updated to version 2.1

Picture 1.pngJust checked the App Store for my iPhone and found the above. The store reports: Release of 2.1 of eReader on the iPhone and iPod Touch has added the following features and improvements: Cover art in the on-device bookshelf. Cover art in the on-line bookshelf. Jukebox view for on-device bookshelf. Jukebox view for on-line bookshelf. Speed and appearance enhancements in bot the on-device and on-line bookshelves. Improved access to Launch Safari to a user defined URL from within the application. Marking books for pending download from the eReader and/or Fictionwise bookshelves. Various minor bug fixes.

6 Comments on eReader updated to version 2.1

  1. It definitely has both Manybooks and “other site” access, the two things that people were complaining had disappeared from v2.0. Interestingly, it now launches Mobile Safari to browse the site, instead of doing it from within eReader itself.

    Also interestingly, and perhaps a bit annoyingly, one can no longer download a file directly in just by entering http:// and the URL/name of the file. You must use the prefix ereader:// and any website offering eReader files for direct iPhone download must use said prefix as well.

    I guess this is a result of the Apple terms of service issue that forced the removal of the features in 2.0. They weren’t allowed to act like a web browser, and had to use the actual web browser instead.

  2. Chris is on the money re 2.1, it seems to have fixed all the auto-syncing nonsense from 2.0.x and returned the ability to add your own content, but at the cost of a much more convoluted (and far less flexible) eReader>Safari>eReader download process. I am also assuming this was done at Apple’s behest, but whatever the explanation it’s a mess and creates all sorts of problems for users with large collections of .pdb files on their hard drives (both DRMed and non-DRMed from both Fictionwise/eReader and other sources) that they want to selectively upload to their iPhone/iPod touch.

    Forcing us to build custom HTML prefixes for every file is a real burden and requires much more work in setting up (and maintaining) a local webserver than was previously the case.

    Why oh why won’t Apple just let users import generic data files into iTunes, associate them with a given application, and then sync them to the device and app like music/movies/podcasts?

  3. Well, presumably we won’t need to “build” a custom prefix. Just type it into the blank in eReader where you’d otherwise type http://.

    But for people who have actual directory pages set up, that could be a problem. (Though then again, perhaps a mass search-and-replace in the HTML code could take care of that.)

    What with the Tweetie thing, the NIN thing, and now the OS 3.0 vs OS 2 compatibility catch-22, I’ve long since stopped expecting sensibility out of Apple.

  4. I didn’t see evidence of Apple’s interference. Can you provide some?

  5. The evidence is 1)in the email that Steve P. sent me saying it was for a Terms of Service issue (which, granted, you can’t directly access) and 2) in the paragraph at the bottom of the help page you get when you tap the question mark button on the “other websites” page in your eReader app (which you can).

  6. Thanks Chris!


The TeleRead community values your civil and thoughtful comments. We use a cache, so expect a delay. Problems? E-mail

wordpress analytics