Loading full-text of documents at startup isn't scaleable about iphoneebooks HOT 3 CLOSED

More thinking on this, and a conclusion (though hardly a solution): HTML sucks 
for
small-device reader applications.

While incrementally loading text is easy (just pick a point and start drawing), 
and
even incrementally loading the subset of HTML-like formatting that Plucker 
supports
is quite doable, loading real, native, in-the-wild HTML without having parsed
everything before the current point is essentially impossible.

Even assuming perfect XHTML (which is hardly a safe assumption given some of the
garbage that's out there), you'd need to at minimum read the header and any
intervening [style] blocks to know how to draw a particular section.  When you 
add
all the myriad ways of messing up HTML - missing close tags, improper nesting, 
and
gawd knows what else...  I give...  I don't think it's possible to render part 
'C' of
an HTML file without having first read 'A' and 'B'.  Maybe if you're willing to 
draw
it with minimal formatting and then re-draw it once you've read from the top 
down. 
That could give you faster load up time (at the expense of ugly text at first). 
Frankly, coding that seems like it would be a nightmare.

We could load the book up fast if the user's near the beginning (just render up 
to
the current offset before showing, and figure out the rest in a BG thread), but 
I'm
not sure that buys much.  Load times would increase linearly as the user 
scrolled
down in the book.

I begin to see why Plucker doesn't do HTML on the device, but pre-processes it. 
 The
Plucker format is designed so that any given record is 'closed' with respect to 
what
came before it.  Any global-type formatting (BG color) is set at the beginning 
of
each record.  There's nothing like CSS and just simple font families and sizes. 
 We
could greatly ease the problem by using a pre-processor ourselves for HTML, but 
I
personally like the idea of just dropping files on the phone and being able to 
read
them without any foreplay...

I wonder if there's any widget on the iPhone that can just take an HTML file 
(rather
than a string of HTML) and display it?  Hopefully Apple might have done better 
at
quick loading?  Time to dive into the headers...

The UIWebView does it, and I've gotten it to compile.  But the problem is that 
there's no way to determine how 
large the view should be (that I can find--there are some string drawing 
routines but they just segfault for 
me).  Somehow, UITextView can do it, but you can't do it directly.  The method 
you're looking for is 
"[uiwebview loadRequest:[NSURLRequest requestWithURL:[NSURL 
fileURLWithPath:pathString]]]".  It loads 
without blocking.

This also displays images in-line, even!  But there's no way to:

- change the font
- change the text size directly (although you can do -makeTextBigger and 
-makeTextSmaller applied to the 
WebKit WebView, which I haven't tested)
- pre-process the file and send it to the UIWebView as a string; the 
loadHTMLString: withBaseURL: method 
seems to be unimplemented.
- guarantee that the view will only be 320 pixels wide.  (If there's an image, 
the view expands to fit it and 
goodbye, vertical-only scrolling.)

I'm already loading up text & HTML files up to a certain character count and 
then loading the rest "in the 
background."  But I'm not sure whether a UITextView is possible to make 
thread-safe or not.  I'm trying to 
avoid multithreading if at all possible.

Fixed in 2.0