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.

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.

On Jun 5, 2011, at 1:19 AM, Garrett Smith wrote:

And sure, I could spend the

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.

On Jun 5, 2011, at 6:58 PM, Garrett Smith wrote:

[...]

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

[snipped fullquote]
--
Garrett

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

On 06/06/2011 05:37 "Garrett Smith" <dhtmlkitc...@gmail.com>

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.

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.

On Jun 6, 2011, at 3:13 AM, Remi Grumeau  wrote:

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

On Jun 6, 6:22 am, Scott Kallen <sc...@kallenconsulting.com> wrote:

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

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.

On Jun 6, 2011, at 12:24 PM, xkit wrote:

On Jun 6, 6:13 pm, Remi Grumeau  <remi.grum...@gmail.com> wrote:

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

--
Rob

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

On Jun 7, 9:45 am, Remi Grumeau <remi.grum...@gmail.com> wrote:

--
Rob

[...]

...
j/k.

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

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.

On Jun 7, 8:25 am, Scott Kallen <sc...@kallenconsulting.com> wrote:

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&

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.