jQuery Application Cacheing?

[KCL]

Anyone else trying to use jQuery in an offline mobile app?

If I understand correctly, I need to bring each file down to 25K or less.  I'm using version 1.5.2.  Has anyone gone to the trouble of breaking it up?

Thanks.

Scott.

[Garrett Smith]

Have you considered not using jQuery?
--
Garrett

[Scott Kallen]

Well, my question was about whether or not anyone has broken it up,
not the merits of using it.

I've committed to using the new deferred functionality in 1.5, which
was a savior when doing SQLite calls. And sure, I could spend the
time to roll my own for all the functionality, but I'd prefer to find
out if anyone has done it this way rather than reinvent the wheel.

Kthnxbye.

Scott.

> --
> You received this message because you are subscribed to the Google
> Groups "iPhoneWebDev" group.
> To post to this group, send email to iphone...@googlegroups.com.
> To unsubscribe from this group, send email to iphonewebdev...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en
> .
>

[Garrett Smith]

On 6/5/11, Garrett Smith <dhtmlk...@gmail.com> wrote:
> On 6/5/11, Scott Kallen <sc...@kallenconsulting.com> wrote:

[...]
> The client and the server should not be coupled. IF they are, you've
> got more porblems then jQUery.
>
than, not then.

[Garrett Smith]

On 6/5/11, Scott Kallen <sc...@kallenconsulting.com> wrote:

> Well, my question was about whether or not anyone has broken it up,
> not the merits of using it.
>
> I've committed to using the new deferred functionality in 1.5, which
> was a savior when doing SQLite calls.

The client and the server should not be coupled. IF they are, you've

got more porblems then jQUery.

And sure, I could spend the

> time to roll my own for all the functionality,

Functionality to do what?
--
Garrett

[Scott Kallen]

Client and server being coupled? Maybe I'm not as familiar with the
term as I thought, but I'm not sure how else to access the local
SQLite DB that resides on the device itself. With the javascript db
transactions being async, they were colliding and causing all sorts of
problems. "Deferred" relieved much of that headache.

This is a web application that uses the HTML5 local DB to collect data
from the database server and store it locally for use offline. And
yes, all transactions with the "online" database server are handled
seperately via ajax. When the user is done updating his/her data in
the offline database, the connection is checked and new, modified data
is sent back to the database server when available.

So, I guess I am coupled with the local DB in that regard. Is there
an alternative that I wasn't aware of?

Scott.

[Garrett Smith]

On 6/5/11, Scott Kallen <sc...@kallenconsulting.com> wrote:

[...]\

>
> This is a web application that uses the HTML5 local DB to collect data

Oh.
The W3C halted Local DB before it reached TR status. See:
http://www.w3.org/TR/webdatabase/

[...]

> So, I guess I am coupled with the local DB in that regard. Is there
> an alternative that I wasn't aware of?
>

You might be able to change it to use localStorage

http://dev.w3.org/html5/webstorage/

[snipped fullquote]
--
Garrett

[Mogens Beltoft]

iOS has full support for a local database accessible from javascript with SQL queries, so what's your point? That it will disappear again?

/Mogens

[Remi Grumeau ]

> iOS has full support for a local database accessible from javascript with SQL queries, so what's your point? That it will disappear again?
>
> /Mogens

+1
w3c recommands IndexedDB as a replacement, with no industry echo. Perhaps iOS5?
LocalStorage is a key-value db, like cookies, nothing you can compare to SQL.

Please keep this mailing-list a friendly place.

Back to the initial question, a min JQuery lib is around 4 or 6kb so what is exactly your problem of manifest per-file size limitation?

R.

[Scott Kallen]

Remi!

Obviously I'm not using the jquery downloader correctly--honestly,
this project is my first (wonderful) foray into the world of jQuery.
My jQuery minified version (1.5.1) weighs in at 85K. What am I doing
wrong?

Thanks!

Scott.

[Garrett Smith]

On 6/6/11, Mogens Beltoft <mog...@beltoft.dk> wrote:
> iOS has full support for a local database accessible from javascript
> with SQL queries, so what's your point? That it will disappear again?
>

It's a gamble. I wouldn't risk forwards compatibility bet on an
abandoned spec being supported. It might do what you want today, but
then maybe 6 months from now, there might be a change. Since none of
it is guaranteed by any specification, whose fault is it if your app
stops working?

Do you want give the client an application that can be expected to
work in the future or do you want to take the money and run?
--
Garrett

[xkit]

On Jun 6, 6:22 am, Scott Kallen <sc...@kallenconsulting.com> wrote:
> Remi!
>
> Obviously I'm not using the jquery downloader correctly--honestly,  
> this project is my first (wonderful) foray into the world of jQuery.  

Well, yeah. But the history of jQuery has shown it to be an ever-
shifting API.

> My jQuery minified version (1.5.1) weighs in at 85K.  What am I doing  
> wrong?
>

Besides using jQuery and using an abandoned API, it looks like you are
trying to solve something without asking how it is best solved. And we
don't even know what "it" is. All we know is "how" you're trying to
solve something.

In web development, there are so many ways to solve problems. Ask the
right questions. Often, I will go back to the req and ask what is
needed and how best to solve that problem.
--
Garrett

[Scott Kallen]

Well, the project was started the project before the spec was abandoned.  Go ahead and fault me for following the W3C spec.  It didn't even *OCCUR* to me that they'd pull such a brainless, elitist stunt.  And yeah, the merits of indexdb can be debated ad nauseam, but to abandon Web DB as they did because they felt SQL was antiquated or relation databases are no longer the flavor of the day is ridiculous at best and irresponsible at worst.  I'm sure no one wants to have that discussion here, so that's where I'll leave it.

And when we started the project, jQtouch was evaluated to be the best candidate out there due to it's seeming maturity and jQuery roots (jQMobile had very little traction).  I had never used jQuery but it was a highly recommended framework that had a lot of folks who knew,  used and supported it.  Perhaps iui would have been a better choice but it was the call we made at the time and the reasoning looked (and if I can solve this problem without a radical redesign, it will be) sound.  Oh and we used php for the server-side stuff for a lot of the same reasons (ease of maintainability and amount of folks who know it).  I'm sure that was a bad decision as well.

My code is well under the application cache 5Mb limit, but I stumbled across the 15K/file limit only recently as I was trying to debug the app cache functionality.  The thing works fine when if the internet connection drops, you just can't start it in offline mode (yet.)

So the "it" I am trying to solve is this:  jquery-1.5.1.min.js is too large.  I need the library (or critical parts of it) to be broken up enough to keep uncompressed file size to under 15K.  Number of files at this point is irrelevant.

My apologies if I was unclear.

Scott.

[RobG]

On Jun 6, 6:13 pm, Remi Grumeau  <remi.grum...@gmail.com> wrote:
> > iOS has full support for a local database accessible from javascript with SQL queries, so what's your point? That it will disappear again?
>
> > /Mogens
>
> +1
> w3c recommands IndexedDB as a replacement, with no industry echo. Perhaps iOS5?
> LocalStorage is a key-value db, like cookies, nothing you can compare to SQL.

You lost me there - +1 for which statement? What does "no idustry
echo" mean?

Are you suggesting/hoping/praying iOS 5 will support IndexDB? Is there
a list of supporting browsers anywhere, or can you suggest one? It
seems that there are lots of statements on the web about support in
various browsers, but very little official word from browser
publishers.

I find it difficult to keep track of W3C documents lately, they seem
to be caught between the "living document" and "published version"
models.

W3C Indexed Database API
Latest published: <URL: http://www.w3.org/TR/IndexedDB/ >
Editor's draft: <URL: http://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
>

There is a discussion mailing list for those interested:
<URL: http://lists.w3.org/Archives/Public/public-webapps/ >


--
Rob

[Remi Grumeau]

>> w3c recommands IndexedDB as a replacement, with no industry echo. Perhaps iOS5?
>> LocalStorage is a key-value db, like cookies, nothing you can compare to SQL.
>
> You lost me there - +1 for which statement? What does "no idustry
> echo" mean?

I mean industry / device maker / mOS have a better LocalDatabase
support for now... for now.
It doesn't mean support is good, it just mean you have better chances
to find out a LocalDatabase support than an IndexedDB one.

Can't remember for Android, but iOS is ok, Blackberry relies on Gears
for OS5 and LocalDatabase for OS6 (can't tell yet for Playbook but i
guess it's pretty much the same WebKit impl than OS6), WindowsPhone7
doesn't support any HTML5 for now and IE9 doesn't support most APIs
(just elements + some CSS3) so you'd better use Silverlight there.

R.

--

Kinds Regards,
Remi Grumeau

[RobG]

On Jun 7, 9:45 am, Remi Grumeau <remi.grum...@gmail.com> wrote:
> >> w3c recommands IndexedDB as a replacement, with no industry echo. Perhaps iOS5?
> >> LocalStorage is a key-value db, like cookies, nothing you can compare to SQL.
>
> > You lost me there - +1 for which statement? What does "no idustry
> > echo" mean?
>
> I mean industry / device maker / mOS have a better LocalDatabase
> support for now... for now.
> It doesn't mean support is good, it just mean you have better chances
> to find out a LocalDatabase support than an IndexedDB one.

Thanks.

>
> Can't remember for Android, but iOS is ok, Blackberry relies on Gears
> for OS5 and LocalDatabase for OS6 (can't tell yet for Playbook but i
> guess it's pretty much the same WebKit impl than OS6), WindowsPhone7
> doesn't support any HTML5 for now and IE9 doesn't support most APIs
> (just elements + some CSS3) so you'd better use Silverlight there.

Good grief, glad I'm not doing local storage then. Browser wars redux
(more or less).

--
Rob

[Garrett Smith]

On 6/6/11, Scott Kallen <sc...@kallenconsulting.com> wrote:

[...]
>

> So the "it" I am trying to solve is this: jquery-1.5.1.min.js is too
> large. I need the library (or critical parts of it) to be broken up
> enough to keep uncompressed file size to under 15K. Number of files
> at this point is irrelevant.
>
> My apologies if I was unclear.
>
>

Ah, what I meant is more close to the req; that is, what your customer
wants. Most things have a multitude of solutions.
--
Garrett

[Garrett Smith]

On 6/6/11, RobG <rg...@iinet.net.au> wrote:
>

[...]

>> Can't remember for Android, but iOS is ok, Blackberry relies on Gears
>> for OS5 and LocalDatabase for OS6 (can't tell yet for Playbook but i
>> guess it's pretty much the same WebKit impl than OS6), WindowsPhone7
>> doesn't support any HTML5 for now and IE9 doesn't support most APIs
>> (just elements + some CSS3) so you'd better use Silverlight there.
>
> Good grief, glad I'm not doing local storage then. Browser wars redux
> (more or less).

Except testing is so much more fun.

...
j/k.

BTW Gears was abandoned over a year ago.
--
Garrett

[Remi Grumeau ]

>> Good grief, glad I'm not doing local storage then. Browser wars redux
>> (more or less).
> Except testing is so much more fun.
> ...
> j/k.

Oh yeah, so much fun...... specially on BB :S

>
> BTW Gears was abandoned over a year ago.
> --
> Garrett

But BB OS4 & 5 still ship it

[KCL]

An update.  I seem to have successfully broken jQuery up into seven 15K (although it appears that 25K would have sufficed) files.  Everything appears to be functioning with no discernible errors.  I've been testing it for over a week now and all seems working.  My app is running offline beautifully.

And as for the req, it was my desire to do this app native.  After much cajoling and outright arguments, I agreed to do it as a web app.  It certainly has been a learning experience!

Scott.

[RobG]

On Jun 7, 8:25 am, Scott Kallen <sc...@kallenconsulting.com> wrote:
> Well, the project was started the project before the spec was  
> abandoned.  Go ahead and fault me for following the W3C spec.  It  
> didn't even *OCCUR* to me that they'd pull such a brainless, elitist  
> stunt.

That's bit harsh. The document never reached recommendation status, so
whoever chose to use it should have been aware from the start that it
may not become a standard and at least may have had some significant
changes before it did. At the very least it should have been a factor
in the project's risk management strategy.

The working draft includes:

| Implementors should be aware that this specification is not
| stable. Implementors who are not taking part in the discussions
| are likely to find the specification changing out from under them
| in incompatible ways. Vendors interested in implementing this
| specification should join the aforementioned mailing lists and
| take part in the discussions.

Gives a reason for being abandoned:

| The specification reached an impasse: all interested
| implementors have used the same SQL backend (Sqlite), but
| we need multiple independent implementations to proceed
| along a standardisation path.

As well as suggesting alternative technologies:

| The Web Applications Working Group continues work on
| two other storage-related specifications: Web Storage
| and Indexed Database API.

The working group responsible for the Web SQL Database specification
is the W3C Web Applications Working Group. It has 93 participants, all
in good standing, 90 from 22 organisations (such as Microsoft, Apple,
Nokia, China Unicom, Google) plus 3 invited experts[1].

Go ahead and call them brainless elitists, but forgive me for not
listening. :-)

1. <URL: http://www.w3.org/2000/09/dbwg/details?group=42538&public=1&gs=1&
>


--
Rob

[KCL]

OK, fine.  We can do this here.

Implementors should be aware that this specification is not

stable. Implementors who are not taking part in the discussions

are likely to find the specification changing out from under them

in incompatible ways. Vendors interested in implementing this 

specification should join the aforementioned mailing lists and 

take part in the discussions. 

Strangely, I find the same text in the working draft for localStorage as well.  A year ago, we looked at all of this and needed HTML5 offline storage.  SQL support for HTML5 has been in the spec at *LEAST* since 2008.  You suggestion is to say, "well, let's wait to see when all this becomes final."  Good luck in the real world with that.

The specification reached an impasse: all interested

implementors have used the same SQL backend (Sqlite), but

we need multiple independent implementations to proceed

along a standardisation path.

Can you tell me what *this* is supposed to mean?  Specifications don't reach impasses, PEOPLE do.  We can't standardize because everyone is using the same thing?  Huh??  How is this an impasse?  And even if it is, is it worth kicking the legs out from under anyone using it?  To me, this smacks of perhaps a handful of elitist folks who don't really give a crap about the guys in the trenches.  And yeah, perhaps brainless wasn't fair.  I'm sure they're all really smart guys who weren't looking for a solution as much as vindication for their particular point of view -- if they couldn't have it their way, then by god, they'd stop it in their tracks.  They should run for Congress.

As well as suggesting alternative technologies: 

|  The Web Applications Working Group continues work on 

|  two other storage-related specifications: Web Storage 

|  and Indexed Database API.

This isn't a suggestion for an alternative technology.  I don't even know *WHAT* it's supposed to be. Pardon me, but isn't the exact same paragraph you cited FIRST in your response, embedded in that document as well?  You're suggesting that THEY'RE suggesting the less-mature spec is the way to go?? And how is EITHER of these an alternative to a relational database?  Oh, that's right.  We're taking the "I sure hope someone builds something" approach.

And I forgive you for not listening--honestly, I'm more pissed at that section of the working group than their defenders.

Scott.