Sorry if this has been answered already and I can't find the answer. I know we discussed it a bit.
I am preventing caching of most of my pages by simply appending a random GET parameter to my links.
But I haven't been able to find a way of prevent caching of the initial landing page.
On my iPhone, it seems pretty good about showing the latest page. But on Android, if I make a change to that page, I always have to manually refresh it.
Is there a way of forcing a refresh or something like that for that landing page, or preventing it from caching? The DOM no-cache attribute doesn't work (apparently intentionally) for the initial landing page.
Right now people can save my mobile web app nice icon to their home screen, on both iPhone and Android, and that is all well and good.
But some people don't save the icon from the landing page. They might look at another page first and then save the icon. If they do that, of course, the result is that the "app icon" takes them to the page they were at when they saved the icon rather than the landing page.
Do people know of any strategies for dealing with this situation?
For example:
1. A way to force the icon to be for the landing page regardless of what page they are on? (I somehow doubt this).
2. A way to detect that they are coming in from the icon and changePage to the intended landing page?
I somehow feel this is not possible, but was just wondering in case somebody had a "cunning strategy" for dealing with this.
I have a landing page for my web app. Depending on different conditions (perhaps a cookie check) I want to switch off to a different page. All the pages are local and are accessible via AJAX via my navbar. I just want to be able to automatically have different users start off on different pages.
There is probably an elegant way of doing this. changePage or something like that? Is there an example of doing this somewhere? Where would I place the script for this?
In the v1.1 release candidates there was an instability problem with footer navbars in Android (2.3.3). Basically, sometimes they worked and sometimes they didn't.
That's why I reverted back from the rc to v1.0.1 which didn't have this problem.
Alas... I am seeing the same problem in v1.1. I have 4 navbar items. I can go from the 1st to the 2nd and the 4th to the 1st, but not from the 2nd to the 3rd. It's just unstable.
The only thing about the 2nd is there is a long select list (by long, I just mean it extends beyond the length of the screen. It's not that long in absolute terms. Maybe 15 items.).
So now I'm thinking - do I have to go back to v1.0.1 again?
Oh no. It appears that the fixed toolbars are not fixed for ios 4.3.3. So for those users a navbar at the bottom actually is worse than in v1.0.1. If the page is long (like a long list) the navbar is way down below the list.
:(
Is there a graceful way of having it at least fall back to the v1.0.1 behavior for ios 4.3.3?
In v1.1, on the iPhone, as I transition from page to page, the top of the header aligns with the top of the screen, so the mobile Safari address bar is hidden, which is nice.
On the Android, this only seems to happen if there is a long page, like a long select list.
Is there a way of making sure the Android pages also all align with the header as the top, thus nicely hiding the address bar above it?
I guess I could do something inelegant like pad the bottom with invisible content. But surely... there is a better way?
I upgraded to v1.1 hope the clunky Android transitions in v1.01 would be helped like mentioned on the release page. But they still seem to be the same on my Android 2.3.3 device - you see the current page, then sort of a blink and the new page.
Is there something else I need to change in my code to take advantage of the new transitions?
The new fixed toolbars work fine, which is great.
The loader, though, looks like just a big gray dot - not like the old spinner at all. There's no arrow or anything.
Anyway, if anybody knows how to improve the clunky Android transitions that would be great.
Included with the final v1.1 is a file called jquery.mobile.theme-1.1.0.css. In the docs I don't see it used anywhere. For example, it's not among the files linked to in the examples.
I still haven't upgraded to 1.1, but let me ask anyway.
In my mobile web app, I am seeing nice slide transitions in iOS. This is a 2D transition right?
On my Android, what I'm seeing is sometimes a slide, but very often what it looks like is the current page pops open again for an instant, and then the target page pops open. Very clunky.
Is this improved in 1.1? Is that my best solution, or are there are things I might consider?
One other point - does this transition depend on whether the new page is cached or not? I've also been experimenting with adding a random number parameter at the end of URLs to prevent caching. The caching isn't so much a problem on the iPhone, but it is on the Android.
on the iPhone the web app looks more like a "real app" because the mobile Safari UI disappears. Or maybe it's just line "2" that does that. I haven't tested by removing one or both of those line yet.
On the Android those are basically ignored, right? So the Android continues to run as an ordinary mobile browser formatted app, but it can also use the home screen icon if defined. On the Android, it sort of looks like a real app anyway, because the mobile browser UI doesn't take up screen space and are in the hardware buttons (point for Android).
For a mobile web app (basically a mobile version of my web site), I'm thinking maybe the Android way is the best way to go for the iPhone as well. Right now on the iPhone it's a HUGE nuisance if the user needs to click a link to visit the "full site" or go to the external site or open an image, etc. and then get back to the "app."
On the Android, all you need to do is go "back" and you are back in the app. But on the iPhone you have to go back to the "web app" icon and start all over each time.
Wouldn't it be better just to not make it a "web app" to begin with?
Is hiding the mobile Safari UI worth the nuisance involved?
From a button, I call a routine which expires a user's cookies and then redirects them to a "logged out" page. It does this via a server side routine which clears the response buffer and then does an HTTP 302 redirect. This works fine.
From another page, however, I call a server-side function which, depending on a condition, attempts to clear the response buffer and basically do the same thing - clear the response buffer and return an HTTP 302 redirect page instead. But this doesn't work. I get an unstyled original page with the HTTP 302 header as part of the visible page.
As far as I can tell, the only difference between the redirect that works and the one that doesn't is that the one that works is part of the page created after a button is pressed, and the one that doesn't work is done inside a page passively, without pressing a button.
I know it sounds a bit vague or opaque. I feel I'm not expressing myself well even as I write this.
Let me ask this: What do you all do to add headers (like new cookies) and then redirect back to the same page so you are where you were, but with the cookies installed in the browser? That's essentially what I'm trying to do.
For some reason, at least one page in my web app get so cached it still thinks a user is logged in when they are not. Meanwhile, on other pages, using the exact same test, the pages always seem to know whether the user is logged in or not.
To avoid this problem, I've started putting a random GET parameter on the problem page by appending (JavaScript):
'/k.' + Math.random(10000)
to the URL. This seems to work, which helps confirm that this is a caching problem.
I'm trying to generally "tighten things up" so I can squeeze more text into these select items (see screenshot). This uses the standard select items with thumbnails, like in the following example from the docs.
<li>
<a href="index.html">
<img src="images/album-bb.jpg" />
<h3>Broken Bells</h3>
<p>Broken Bells</p><
/a>
</li>
Basically what I'd like to do is narrow all the margins to allow for more text, particularly between the thumbnail and the start of the text. There is an awful lot of wasted space there. Anybody know where the bodies are buried to do this?
Is it possible to create a form in jquery mobile which allows a user to select a photo from the iOS camera roll and attach it for upload? Or is that just not possible?
In my web app it is is sometimes necessary to leave the web app and visit the "full site" in the mobile browser. I do this, after sufficient warning, with a URL like this:
<a href="/" data-role="button" data-ajax="false" target="new">Go to the full site</a>
In a regular browser (e.g. Chrome), this is fine because it just opens a new tab and you can easily just close the tab and you're back in the web app.
On the Android it's also ok, because you can press the hardware menu button, choose Windows and select the web app window and you're back. Not a one step action, but not too bad.
On the iPhone (and iOS) though, there doesn't seem to be a way back to the web app again. Going to the 8-possible-windows view on the iPhone, the web app isn't among them. And on the iPad the web app doesn't appear amongst the mobile Safari tabs.
Are there any best practices for leaving the web app in iOS and then getting back again?
It would be great if there was just some way to open a "sub browser" view from inside jquery mobile like you can in a real native app. but I guess that's not possible, is it?
can appear in the <head> section of every page because it's not really all re-loaded for every AJAX call (except for the title) and, in fact, is good to have there just in case there is a need to manually reload a page (for example, from the Android browser, where it is not really running as a web app anyway), to avoid losing the styles.
I was thinking of maybe keeping a few main items on the navbar and moving everything else to a select menu that opens up from the navbar. Some nice bubble or something, with icons, that opens up on top of the current page and can be dismissed naturally.
Are there recommended techniques or examples of this?
I'm still trying to figure out how to view an attachment - lets say an image attachment now for simplicity's sake - without leaving the web app, and staying within the current UI.
The links to the attachments are all in the same domain.
Is maybe going to a page with an iframe containing the attachment data a good idea?
On my iPhone, for example, I can go to a no-ajax link and see image and PDF attachments. But then it's awkward to get back into the web app again. I'd really like to contain whatever I'm opening in the same header and footer I'm using on the other pages.
The footer in my web app seems to be a bit wider than the other element (on both the iPhone and Android), using JQM 1.0.1.
I notice this because the navbar is centered in the footer, but because the footer is too wide it's a bit off to the right, leaving footer background exposed on the left, but not on the right.
I reverted from v1.1 rc1 to 1.0.1. Now the Android navbar buttons work reliably. There is definitely something weird in v1.1 rc1 with Android buttons (I'm using Android 2.3.3).
But now I have two problems I didn't have in ordinary v1.0:
(1) On the initial page only, the "loading" message never goes away. On subsequent pages it does go away after the transition. This happens on the iPhone and Android and also Chrome. So something is "sticking" the loading message there.
(2) On Android only, the slide transitions stopped working. They look nice on the iPhone, but it's just a choppy transition between pages on the Android.
I know I wrote a lot of messages today. Sorry for posting so much. I did do Google searches and looked at Stack Overflow etc. before posting, and the docs (what I can find of them) but keep getting stuck on these little UI issues.
Everything in v1.1 seems to work so well on the iPhone and iPad. And I really wanted those fixed toolbars at the bottom!
But... it seems all broken in so many places in Android 2.3.3:
- Slide transitions aren't working.
- Navbar touches or tab bar buttons in footer work only sporadically.
- The themes even seem less smooth.
I guess I have to revert to a stable version in order to get everything to work again.
I can't believe this is a release candidate with so much stuff not working in Android 2.3.3. Am I the only one having problems with toolbar buttons being flaky and transitions not working, etc.?
I was so excited after seeing the nice truly "fixed" toolbars. But now I've been frustrated all day just trying to get buttons to respond reliably in Android.