On Oct 2, 4:47 pm, Homer <[EMAIL PROTECTED]> wrote: > > I would like to store the client-side parts of a Web application > inside a local database (from the Safari's WebKit). I mean, to store > the code (html, js, css) on the internal iPhone's persistent memory...
That was the first feature I added to the large (~230k uncompressed) js program I wrote for remote desktop and file access ( http://f2p.com ). Besides the large code, there are graphics toolbars, cursors & help images (~300k). On EDGE loading could take 30 sec or longer. So, I put everything into iPhone database and send only a tiny bootstrap loader (~3K) via network. The loader checks the time-date stamps for each piece, reloads anything that is out of date and activates the main program. For even quicker startup (to show remote desktop within ~0.5-1 sec from user's tap), I unpack the code and images gradually in several phases (since only a smaller part is needed at that time), each phase unpacks the next one after it displays its output. The refreshing of the database (in the case of outdated components) is done in the background after the app is fully ready for use. I also store original URLs for the components into the searchable database fields, and the loader utility functions fetch the record from the database if available and up-to-date, otherwise they get it from the network (and schedule database refresh for that record). Using such wrappers, the old code which had statements of the form: obj.src=URL , was mechanically converted into the form dbSrc(obj,URL) (the onload callbacks, if any, are done automatically from the dbSrc utility code, when the SQL completion callbacks occur or when the network load completes). When all the components are in the database, the loading is 1-2 orders of magnitude faster. The iPhone database is very fast, albeit wasteful of storage since it stores plain 7 bit characters (source & images; the latter use data URI base64 encoding) as 16 bit unicode char's, at least doubling the actually needed size (iPhone SQL doesn't support SQLite pragmas for char encoding). Further storage wastefulness is due to the missing deletion facilities (DROP & VACUUM) in the current iPhone SQL implementation, which doubles the storage after you update the records. These two limitations reduce the effective storage limit from 5MB to 1.25MB. Finally, the iPhone SQL creates a new database for every prefix variant of the original URL (e.g. with www. prefix or without it), which ends up creating several databases (requiring separate creations & updates), whenver user varies the site DNS prefix (we allow custom base URL prefixes via dynamic DNS which serve different roles). Despite these three problems in the present iPhone SQL implementation, it is quite useful facility. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en -~----------~----~----~----~------~----~------~--~---
