jQuery Forum

before a page loads, it'll request JSONP data from

Why, do you like hitting yourself on the head with a hammer? Unless you have no control of the server, you're just making things more difficult for yourself.

Why not just have the server return a normal HTML page? The whole point of jQuery Mobile's page model is to allow you to load pages using AJAX without you having to worry about the AJAX. It just works.

If you want to get slick and replace elements within a page with data from the server (say, to paginate a list) then have the server return an HTML fragment. Why unnecessarily complicate things by using JSON?

As for URL structure? Who cares? I've no more interest in fretting over URL structure than I do code indentation style. It's simply a religious issue. Use what makes sense to you. It has no impact on jQuery Mobile.

(OK, so JSON vs. HTML fragments is a religious issue as well. In that case, though, my religion is right. ;) )

Don't quite understand what you are asking about keeping track of IDs. If you want to persist the user's state, then you can use one of the HTML5 storage mechanisms (or even a cookie) to maintain state between sessions. Phonegap has some help for this, as it implements local storage even on platforms that don't natively support it in the browser. Otherwise, to maintain state while the app is running, you can use a global variable (use one, make it an object) and/or attach data to the document/page/individual elements using jqmData().

Since everything comes from your server, your MVC is handled by the server, so kinda don't understand the overall question. If you move the database onto the device itself, then things get more complicated, as now you are moving all the MVC to the client, and you will need to make some decisions on Javascript components to support that. Myself, I wouldn't use PhoneGap in that case, since I don't want to beat myself over the head trying to implement MVC in Javascript - I use Rhodes, which runs a webserver in the device running Ruby. Although Rhodes is not a Rails implementation, it is very similar and is a natural fit for Rails developers.

Hi watusiware,

Thanks for responding.  I really appreciate your advice and points of view.

I guess the motivation for all this unnecessary pain is to:
1. avoid getting rejected by the app store as just a website with a native app wrapper; hence the part with retrieving JSON data versus HTML pages
http://stackoverflow.com/questions/7934942/itunes-app-approval-requirements-with-jquery-mobile-and-phonegap
https://groups.google.com/forum/?fromgroups=#!topic/phonegap/Ue5MiWdyQ-A
http://www.adobe.com/devnet/phonegap/articles/apple-application-rejections-and-phonegap-advice.html
https://groups.google.com/forum/?fromgroups=#!topic/phonegap/Ue5MiWdyQ-A

2. have the ability to update the data on the server-side and then the app should reflect the latest and greatest data without needing to release a new update to the app

Of course, I'm all very new at this so maybe I need to look into other frameworks that does this better?  You mentioned Rhodes so I took a brief look at it and it seems to be doing what I need with RhoConnect.

With Rhodes, are you using:
- Rhodes as the server on the mobile device to generate HTML pages,
- RhoConnect to update the data with an external server,
- and jQuery Mobile as the mobile user interface?
It seems like Rhodes allow device calls as well.  Very interesting.  I'm guessing you are not a follower of the PhoneGap religion as well then? :)

I was thinking that keeping the data exchanges strictly as data as opposed to HTML fragments would help with future modifications to the app.  The older versions can still accept the data and the new versions (possibly with different HTML structure) can still accept the same data.  Again, I wouldn't doubt that I might have missed another reason, framework, or best practice that can avoid the pains of JSON with the added benefit of allowing different versions of the app to be able to ingest data/HTML from the same server.

Thanks for the point about URL structure.  After reading your post it really makes sense that jQuery Mobile wouldn't care about URL structure (and hence would not have any framework in place for it) since it's really up to the server to properly render links to the correct URL.

My question with the IDs is really a moot point after reading your post since the URL structure should really be handled at the server and not within the jQuery Mobile framework.  But since I'm not getting that information from the server, I'll need to store it manually as a javascript object or something.

I was originally thinking that only data comes from the server since Apple doesn't want a web app with a native wrapper and using PhoneGap/jQuery Mobile allows me the flexibility to access the device.  I had no intentions of moving the MVC or the database to the client but maybe that's something I should consider (or from your post...perhaps not).

I just wanted the app to display data from the remote server and maybe have the ability to use geolocation, camera, or photo gallery.

It seems like what's left for me is build something so the app knows which external URL to get the JSON data from.

Again, any other input/advice that can steer me to a better solution will be awesomeness!

Thanks again!

Hi watusiware,

That's a very good point about data getting formatted on the server is no different than data getting formatted locally by javascript.  I should look into the Apple guidelines from that perspective and see if I see anything different.  You've got me worried about the network access red flags.  I should really look into it some more.

I didn't know that most PhoneGap apps use only local, static content.  Everything seems so dynamic I always just assumed there was a lot of data exchanges with external servers.  I guess they could be fetching HTML also, and I wouldn't know the difference.

Thanks for the heads up on licensing with RhoConnect.  I didn't catch that part when I was browsing through the information yesterday.

Thanks again for sharing all your knowledge.  I'll internalize it some more and make some decisions on:
- format data locally (with more javascript and templating work) or on the server (with more routing/controller and versioning work)
- figure out a way to store some data locally and to use less network access to better my chances of getting approved
- integrate more phone specific features like geolocation, camera, etc.

It's been a blast and thank you for taking the time to respond and share.

Take care!