Shelf & Multiple Hpub support

[segundoseis]

Was: more than one hpub in the same application

As a user would be great to see more than one hpub in the same application. Pre-home with hpub-thumbsnails navigation?

[folletto]

That's a great thing, but I'm wondering if it's within the objectives of this tool, or we should just build the "framework" to be included in any other kind of app.

Still, I'd like to give some sort of basic functionality, so I'd like to hear some feedback about this topic. :)

[segundoseis]

I do not know if I'm complicating this. but I imagine an author who has multiple numbers, it would be interesting not generate more than one app in the appstore. What do you think?

[folletto]

I think that two different situations exist:

• allowing to read "any" book (iBook)
• allowing to create multiple numbers

Because those two I think that are similar technically, but very different from the point of view of UI and author. :)

[segundoseis]

truth! mmm .. now I'm thinking that I could download a zipped hpub as @svdgraaf was preparing. :-P

[MacBoy]

For those who would like to use Baker as a framework for magazines, each hpub would be a publication of the magazine. The same for a product catalog, each hpub would be a different product or section of the overall catalog.

It would be very nice if the Baker Framework could hold multiple hpub packages.

Thank you!!!

[aldriq]

I guess the main question is whether BakerFramework can/will evolve (or branch out) to a full-blown BakerReader that can hold any number of books, like iBook, kindle or Stanza.

[folletto]

Good point aldriq, that's truly something that we are thinking of, the point for that is the effort to reach that point, and what does it mean for the project, because then it would be a Reader with inside the Framework. Completely doable, but still decisions to take and development (a lot) to do. We'll see how the community is going to respond, step by step I think. ;)

[MacBoy]

Now that we can replace the internal "book" with an externally downloaded book, the contents can easily grow and be replaced. The HTML could have an Index page that one can link to different sections. That would be the workaround for having only one book in the app.

We still have a need for multiple books within the app.

Priority for it is lower than other features. For example, the Landscape orientation should be done first. This request has a suitable workaround already.

[aldriq]

I understand, it's definitely a medium/log-term decision. I imagine it also depends on how 'fast' the next hpub standard takes to consolidate.

[therabidbanana]

I'm planning on adding multiple hpub support to my Baker fork for a project I'm working on. Is there any planned movement on this from the Baker team, or planned updates to the hpub specification that might be of interest (the recent addition of a JSON library by @folletto seems to hint at moving toward JSON manifests)? If there are plans to support metadata in manifests that could be quite useful.

Here's what I'm thinking of building:

Keep every hpub downloaded, and the associated book:// url, with a dictionary mapping url to hpub. On a book:// url, check to see if it's already been downloaded by looking it up in the dictionary. If so, just unzip the local hpub, else download as normal.

For some people, that might be enough, but for flexibility I imagine I will also need to add the following capabilities:

• Showing the user a list of hpubs already downloaded.
• Allow deleting existing local hpubs
• Allow updating local hpubs (transparently delete and then redownload if versions don't match).

I see two possible ways to handle the extra use cases:

1. (Use Javascript/HTML as much as possible) Inject the dictionary of local hpubs into the page as a javascript variable. Either inject into every single page, or maybe only book://local pages, or maybe only a specific file defined in the application (index.html might be a good place). Add support for book://local/path/delete so that books can be deleted. Let users define whatever javascript they'd like to take the local hpub list and work with it. The injection of javascript variables seems kind of hackish, but would allow a lot of customization with just standard html/js.
2. (Obj-C all the way) Create a new UIView accessible either by a new url like book://shelf, or maybe in place of book://local if preferred - maybe build on top of something like https://github.com/AlanQuatermain/AQGridView to give a pretty interface. This option seems less hackish, but is also a lot less flexible.

Anyone have any thoughts on which version they'd prefer, or things I might not have considered?

[folletto]

Wonderful, let's see. :)

You're absolutely correct about the features needed in order to allow proper "download-and-storage" feature, since if we store something we also need to give a way to manage it (select, delete, update).

For that, I was thinking about a solution that involved the creation of a top navigation bar when you double tap. The bar is going to have a button "All books" and will allow you to tap on it and get a dropdown with all the downloaded book in the issue. From there, you can select one. If it was a downloaded book, on there it will also provide an update feature and a delete feature, even if it's not yet clear to me what's the best way to build it. As before, we probably have to create it, see how it works, and iterate a couple of times to get it right.

But... this doesn't mean that a HTML integration is excluded. We should still give ways from the book itself to work with book urls, but I don't expect the ability to delete/manage them, just to choose them. And for that a JS injected would be fine, let's just coordinate on the correct namespace for it. Probably creating a object called "book" is ideal, and we can append everything to it, so: book.shelf that returns an array of hashes: [{title, url}, {...}, ...].

You also got right the direction we are taking for the manifest. Again, it's more in the experimentation phase right now, so it might be that we scrap it, but we are testing something what uses a "book.json" file inside the hpub book, containing things like title, author, reference URL, pages and sheet options (orientation, size). I hope to be able to share something soon inside the example book that I'm re-building. :)

[therabidbanana]

I had considered adding a navigation bar, but thought it could get kind of cluttered showing even more on double tap, and I wasn't sure how minimalist you were hoping to keep the interface. As long as it's easy to disable, I suppose that's not an issue though.

I like the way the dropdown works in Dropbox (http://c0736882.cdn.cloudfiles.rackspacecloud.com/Dropbox%20iPad%20-%203.png). Something similar to that may be appropriate, but I have no idea how hard it is to program.

One thing I hadn't really considered - it sounds like you're imagining being able to see books in the list that haven't been downloaded yet. How do you imagine letting the application know those books exist - hardcoding the list into the app? Maybe some sort of JSON list or RSS feed pulled off of a server? My original thought was just having the local book be a simple, one-page hardcoded list of book:// urls and releasing an app update every time the list of books (or in our case, magazine issues) changed. That's probably not very scalable though. It might be better if there was a list the application could retrieve from the server - but then we'd need to work out a standardized format to use for listing books - maybe just a JSON array of manifests?

[folletto]

Yes, I'm imagining something similar to that UI. :)

About providing view of books not downloaded yet I wasn't really thinking anything, we might leave it for a future release. I won't put too much work ahead, or we wouldn't get a good feedback from all the users. ;) The one page approach you propose however should work well, and straight out of the box: if a book references another book, it should be easy to download it and add it to the Baker reader, so you could have a "starting" page, and then any other book will be able to trigger the download of other books. :)

Btw, with these features it's probably possible to release a Baker Reader, so... that's something we were thinking of, but with your help it might get here sooner than expected. ;)

[therabidbanana]

I have a beginning implementation working in https://github.com/orangesparkleball/baker/tree/multiple-hpubs.

A navigation bar shows up on double tap with a popover for displaying the list of stored books. The implementation is still a little crude - each hpub must have a unique filename, and updates are not download if the filename is the same. There's also not any way to delete books yet.

[folletto]

Excellent! I don't have time right now to try it out, but I'll do asap with the last master from that tree. :)

[folletto]

Tested :)

Ok, my proposal would be (sorry if I'm going to say even polish things and things you might already have planned):

• Move the button on the right, like Mail and Dropbox
• Use the book name instead of baker in the top bar
• Use the book name instead of the filename in the list (this probably needs the book.json manifest)
• Polish: fix a bit the animation in order to be coherent with the status bar

I omitted things like delete and update, since we already talked about it. ;)

[therabidbanana]

Was just about to post an update on this front. :)

• Do you mean putting this button on the left instead of the right? I was thinking we might also add a "Close book" arrow and place it on the left.
• This is now pulled from the manifest (if one exists).
• A bit trickier - since currently manifests are zipped inside the hpub, brings up a question below.
• I was having trouble trying to get them to come in together in a way that didn't look haphazard. I'll play with it a bit more.

Question - does it make more sense to keep the hpubs, or the extracted versions of the hpubs? Theoretically the hpubs will take less space, but I can't imagine it's a significant enough amount to worry about. On the flipside, keeping the hpubs makes them easier to treat as discrete books so you can move books into Baker with the iTunes File Sharing system.

If we keep them around as hpubs, it's probably worth caching any manifests into a database so the system doesn't need to extract the hpub to find the manifest - although I think the zip library might have support for peeking into the zip file without extracting. Maybe that's an option. Will need to investigate.

[folletto]

1. Yep. Uh, what were you thinking then happens when you close a book? I would take a simpler approach: in the dropdown there's also the "master" book (the first one) so you can simply swtich back to it. (this will open the system to more flexibility in the future as well I think).
2. Great!
3. Yes, good point. Regarding that question, I think you detailed well the possibilities. I'd try to keep the zipped book as well, exactly for the same reasons you just explained. Then, I'd just store somewhere the manifest (or in a db) in order to use it. The only drawback is the load time for opening a book, but it's something that we could check.
4. Maybe we can just wait the opening of the bar when the status bar is completely folded out, and then start animating in our bar. But it's just a thought, if you find a better and faster solution go for it. ;)

[therabidbanana]

The dropdown can now peek into the hpub and look for a manifest. If it finds one, it replaces the filename with the title from that manifest, otherwise it just uses filename. With this method we don't necessarily have to store manifests separately.

I think we still might want to store manifests separately - that'd allow you to delete a book but keep a reference to it so you could easily redownload it... but I imagine peeking into an hpub to find the manifest could still be useful if you downloaded a book but didn't open it (going back to the iTunes file sharing method of adding books), so it's a good first step.

[folletto]

I agree with the approach, great.

For the filename we might think of using a hash of the URI (since that is going to be the unique identifier, like IBAN) or use a physical path that matches the URI itself (for example: book://example.org/publisher/author/book -> /books/example.org/publisher/author/book.hpub).

[therabidbanana]

Is it worth forking this effort off into its own "baker reader" project? Our requirements for this project have evolved to create a "like iBooks" reader, complete with a shelf and the ability to download multiple books. I've got some of this going in my multiple-hpubs branch, but I'm restructuring so much of the code it's starting to look like a completely different program and it's not making sense to even support a single bundled book any more.

My end goal is to release to the App Store a "Baker Reader" program that is basically an iBooks clone with hpub support instead of epub. Then, rather than having to build a new app for each of our clients, we can have them download that and then send them the hpub via email or book:// url. I get the reasoning behind creating per-book apps - so each one can have its own unique look and feel, and be a separate app in the app store. So I can see wanting to have both a "Baker Core" that works as Baker does now, and a "Baker Reader" that pulls in elements of the Baker core while adding more of the iBooks like functionality.

[folletto]

Well it depends, I think that it should be possible to keep the two things together for quite a bit, so, what feature do you think it's going to break it?

I was trying to test your latest branch but it's giving me a few issues (NavBarController.h not found). I'd like to test it and to see what you want to add so we can coordinate.

That's because the Book Reader in many ways is going to be exactly Baker for a single magazine with multiple issues, with the OS-level book:// support disabled, at least thats's how we were planning it. :)

[therabidbanana]

Whoops, I did a lot of restructuring and didn't push all of my changes. Just pushed another commit or two that should remove any last references to the NavBarController.h.

As of yet, nothing I've done specifically breaks Baker, though some of the changes might be hard to merge (I split out some new classes to help cut down on the code in the RootViewController).

I just wonder if the changes I plan on building (no bundled book, a shelf view for viewing hpubs, the navigation bar and book:// url support) are getting to the point where they warrant splitting the project between a "Baker Core" and a "Baker Reader", where the reader duplicates the Core classes to handle viewing books, but also adds in a Shelf view and hpub handling support, etc - stuff that wouldn't make sense for people building a simple, single-book app.

I don't know if it'd make sense to keep adding constants to turn on and off extra features, which is probably what we'd need to do if they were both contained within the same repo (and include two different plists for building the app depending on if you want Reader or Standard - since url schemes have to be added with the plist, etc). I suppose they could be separate branches, but if they are maintained as two separate branches then that's not really any different from forking the project.

[folletto]

Ok, but I don't see at this time a breaking feature. :)

I mean: the only difference seems that you don't want a bundled book. It's quite simple to add a flag "if a book is present in the shelf, start with that". That will work for either single books, multiple magazine issues, series and Reader as well. :)

If you just want one book, you are just going to have a button that takes you to a shelf with only one book. No big deal (and even that could be a flag).

I agree that at some point the fork might happen, but I don't think it's now. Or am I missing something? :) (for the book:// protocol, it should be just off by default on OS level, to avoid overlapping features, there should be only one reader). :)

Also: the navigation bar is already in the master branch, are you thinking something different? :)

[therabidbanana]

In my mind, one of the key features is a reader that does have book:// turned on at the OS level so that I don't have to distribute apps via testflight every time I want people to be able to preview a new book (so far we're building these books as internal enterprise apps, not general public apps). Being able to email book:// links to distribute new copies is ideal (or include email attachments). We want to build several books and know our clients can view them without going through the hassle of getting us their device ids and without having to deploy to the app store, since the books would be private.

I suppose if people are fine with a shelf view for their single-book apps that's fine, though the shelf viewing support might be adding a decent amount of code to the project (unsure if it'd significantly impact performance to have the code there and just ignore it - but it seems silly to force users to have the shelf if they don't plan on using it).

I should note that I plan on adding support for multiple "shelves" of content, where each magazine/collection would have its own shelf within the reader and be able to notify the reader when there is a new book within the shelf (maybe each shelf is an RSS feed of links to hpubs or something like that?), on top of the ability to manually add books to a shelf. So in my mind the shelf isn't just a tiny bit of extra code, it's going to add a lot of extra functionality that just doesn't make sense for single-book apps.

Our end goal is to provide our clients with a CMS (based on the bakers-oven idea I've been toying with) for creating new hpubs (or updating existing ones) and distributing those hpubs to a set of users in the quickest and easiest way possible.

[folletto]

Could we get there in steps? Because maybe multiple shelves isn't going to be part of Baker Core, but everything else will. It's a hugely requested feature, it is going to be part of Baker Core. :)

After that, I think that a proper forking will be a good choice. :)

[therabidbanana]

Okay, I wasn't sure if the plan was to include support for the shelf in the Baker Core. I definitely plan on getting a single shelf working before trying to work on the multiple shelves idea, hopefully it'll be ready within the next week or two.

[folletto]

Great. :)

Do you already have something in mind? Or are you starting with a plain shelf? I'm asking because I've already started working on the design of that part, and I'd like to avoid duplicated efforts. ;)

[ravitola]

Hi there

Checking on this discussion to see if there has been any progress to move this along as I would be interested in collaborating on this effort. Let me know..

[therabidbanana]

Hey @ravitola, no real progress since my last comment in June, unfortunately. I've been a bit sidetracked lately. You can check out the work so far in my topic branch: https://github.com/orangesparkleball/baker/tree/multiple-hpubs

Still to be done:

• Fix the index view so that it isn't pushed down by the navigation bar
• Create a better interface for the list of hpubs

What's been done so far:

• A large amount of refactoring to create "book" and "shelf" models and separate view controllers responsible for different parts fo the app
• Enabling of book:// url catching from external apps
• Enabling file-type recognition so you can "Open With..." the file from other applications such as Mail and Dropbox
• Enabling file synchronization in iTunes so you can add hpubs with iTunes

[folletto]

I'd just suggest in any case to disable the book:// url catching until we have a bigger discussion about it, I'd avoid to release frameworks then are going to compete on which one is going to download books - and maybe you don't want to download any kind of book in your branded app, you know ;)

But that's critical instead to create a reader, so worth working with that, it just needs to be off by default. :)

[therabidbanana]

Well, I wanted to build support for catching the URL scheme, even if it does get turned off by default, so in my testing branch it's on. To turn it off is an easy plist change though.

[folletto]

Yep, we did the same, I just wanted to avoid situation of apps published on the store from the evolved framework that then are going to catch all the books from everywhere. :)

[therabidbanana]

Hey everyone, just thought I'd give a quick update since I got a message in my Github inbox today:

I've stopped working on this and I'm not sure when I'll have the chance to get back to it any time soon. I recently switched jobs, so haven't been able to make changes during my work hours any more. If anyone wants to take the lead on this, feel free to take a look at what I've done so far in my branch and either build off of it or start fresh (I did a pretty intensive code refactoring, so it'll probably be nearly impossible to merge into the latest code).

I'll probably loop back to this at some point when I have a bit more free time, but I definitely won't have any time in the next few months to work on it, and if it's done by then I'll just find something else in Baker to fix. :D

[folletto]

Hi! :D

Even if it isn't a "good" news, thanks for the update! :)

We are going to tackle it in the 4.0 release, so we are going to have a look at your work by then, and see if we can borrow idea. 4.0 will be probably also a refactored version, so... we'll rewrite a lot of it as well. :)

Thank you very much, and I hope you'll still find a few minutes every now and then to chime in. :)

[mpena2099]

Hi folks!

Please, see this: http://ios-blog.co.uk/iphone-development-tutorials/how-to-make-a-magazine-app-in-ios-part-ii/

Thanks!

[folletto]

Thanks! That's a very nice link. Did you try to contact him to see if he wants to try an integration with Baker? ;)

[mpena2099]

Not yet, but I'll try! :)

[viggiosoft]

Hi, I'm the person that prepared the articles about magazine in http://ios-blog.co.uk and http://www.viggiosoft.com . I have been contacted to follow this project (I didn't know it before, excellent work by the way, congratulations!) and provide my cooperation in this discussion. It seems to me that everybody agrees on the need to extend the framework by adding the front-end (shelf) and back-end (client/server communication, Newsstand, In App Purcahse). While there is no a clear direction if these implementations should be added in the current framework as it or as new frameworks. I have prepared several apps, and on of my great early choices was to implement a reusable PDF reader (with all possible options: search, links, multimedia, ...) in order to be able on each app to re-use 80% of the reader (customer will require a customization) and the need to build just the shelf (front-end). Later I found that having 3 parts is better than two: the reader, the front-end shelf (UI), the back-end. In most cases the customer will ask you to rebuild from scratch the UI, while the back-end is highly reusable in different apps and different devices. So my opinion in such case is to avoid extending the existing framework, excellent as a reader, by adding back-end features and UI views. My suggestion is to provide other two modules that will link with the reader and will provide some guidelines for custom implementations. E.g. the back-end will change its implementation based on the kind of server it needs to work with or on the protections applied to provide In App Purchase, but the download and installation of the content will be done in the same way as this is established by the reader format. Besides the front-end will contain the basic hooks or protocols to both the reader ("open this book") or to the back-end ("purchase this book", "download this book") but it will be up to the final developer customize this part of the app. Anyway I would be happy to provide my contribution based on the directions that the owner of this project will give to me.

Carlo

[folletto]

Hi Carlo! :)

At the beginning more than a year ago (wow, thinking about it) we didn't have in mind to expand the framework to such a level, so the code isn't much modular. It would be great to have a structure like the one you defined, but it's probably related to the refactoring tracked in Issue #59 that still hasn't been done.

If you want to contribute to Baker, the best idea would be probably for you to have a look at the code base and suggest here an approach that could be doable in your perspective. We're open to discuss any option. :)

A cool approach could be for you to work on a branch from the upcoming 3.1 release and incorporate in your shelf, discussing and feeding then back the result. But, I think, this could be quite a big undertaking, so I can't really ask you to do it. :)

Check the code and let's see what you think you could do. :)

Thanks! :)

[viggiosoft]

Hi Davide,

thanks for your suggestion. Definitely forking 3.1 and trying to refactor it in such way that it can talk with an external shelf using a general purpose interface is a great idea. I will try to experiment a little bit privately in order to have a deep understanding of the code sections I need to interact with and if I get some valid result I will be happy to publish and explain my comments.

Thank you

[folletto]

Thanks to you! Please keep us informed on your thoughts and progress. :)

[mpena2099]

Hi!

First of all, sorry Google by his translator. :D

I contacted Carlo because I have to build an iPad digital magazine similar to existing ones here in Brazil and, as I would use the Baker, the idea was to join the code of Carlo with Baker (I still do not know if the Carlo's Shelf is BSD License but... =D)

I am new to developing to iOS/Xcode but I'm a WEB developer for years.

Despite the difficulty, I will try to put Baker on Carlo's Shelfr. And place HERE the results, of course. ;)

OK?

Thanks! Mauricio

[folletto]

No worries, and thank you in advance for any contribution you'd like to make. :D

[mpena2099]

Hi!

That's what I'm trying to do to pub Baker on "Carlo's Shelf":

1. change the file links to download store.plist HPub COMPRESSED files; (DONE!)
2. download OK, unzip the file using the class decompressing already exists in Baker; (DONE!)
3. Save journal in a directory created with the name "ID" magazine; (Carlo's Shelf already do something like this, so... DONE!)
4. hPub file unziped, display it in the same window the Carlo's Baker display the PDF file, ADDING Baker code;

OK... THAT is the problem! No idea how to do this! =D

Above is the method (on ShelfViewControleler.m) of Carlo's Shelf that reads the file:

---

-(void)readIssue:(Issue )issue { QLPreviewController preview = [[QLPreviewController alloc] initWithNibName:nil bundle:nil]; preview.delegate=self; preview.dataSource=self; urlOfReadingIssue=[[issue contentURL] URLByAppendingPathComponent:@"magazine.pdf"];

[self presentModalViewController:preview animated:YES];

}

QUESTIONS:

1. it's possible to call Baker INSIDE this method???
2. how to do this? :P

Thanks for all!

[viggiosoft]

Hi Mauricio,

can you share your work as a fork on GH? I will try to have a look and see how can I help you on point [4]. Honestly I had no time to look at the whole stuff, all my customers are pushing me to see all they apps released by Christmas and I'm really busy... But as you already merged the shelf with baker in a single project, this can simplify my job.

Carlo

Sent from my iPad

On 03/dic/2011, at 02:26, mpena2099 reply@reply.github.com wrote:

Hi!

That's what I'm trying to do to pub Baker on "Carlo's Shelf":

1. change the file links to download store.plist HPub COMPRESSED files; (DONE!)
2. download OK, unzip the file using the class decompressing already exists in Baker; (DONE!)
3. Save journal in a directory created with the name "ID" magazine; (Carlo's Shelf already do something like this, so... DONE!)
4. hPub file unziped, display it in the same window the Carlo's Baker display the PDF file, ADDING Baker code;

OK... THAT is the problem! No idea how to do this! =D

Above is the method (on ShelfViewControleler.m) of Carlo's Shelf that reads the file:

---

-(void)readIssue:(Issue )issue { QLPreviewController preview = [[QLPreviewController alloc] initWithNibName:nil bundle:nil]; preview.delegate=self; preview.dataSource=self; urlOfReadingIssue=[[issue contentURL] URLByAppendingPathComponent:@"magazine.pdf"];

[self presentModalViewController:preview animated:YES];

}

QUESTIONS:

1. it's possible to call Baker INSIDE this method???
2. how to do this? :P

Thanks for all!

---

Reply to this email directly or view it on GitHub: https://github.com/Simbul/baker/issues/20#issuecomment-2998279

[mpena2099]

Hi Carlo!

Yes, I'll share my work, no problem. I don't know how to use GIT yet but I'll do this today and post it on GH. Any help after that will be welcome. ;)

Thanks! Mauricio

[mpena2099]

Hi folks!

If I made this correctly, see the Baker + HowToMakeAMagazineApp together in https://github.com/mpena2099/bakershelf

Now I need a help to call Baker from HowToMakeAMagazineApp...

Thanks! Mauricio

[viggiosoft]

Hi Mauricio, I just opened an issue about some missing files in your fork'd project. I would keep all issues and communications related to that experiment on the new bakershelf git so people interested can follow it in the right place.

[nin9creative]

Has anyone seen this example? http://www.siteless.org/?p=585