I'm making an app where having a UIWebView is absolutely necessary. However, I'm having a problem where the UIWebView doesn't load the mobile version of the website.
I've read some questions on StackOverflow, and they all seem to say it's up to the website to decide what type to display, and that the UIWebView acts just like Safari.
However, I have tested with 9 different links to different websites and they all load the desktop version in my UIWebView and the mobile version in Safari.
What could I do to force the UIWebView to load the mobile version just like Safari does? Are there a type of headers I could send or cookies to set or anything that actually works?
Furthermore, the desktop versions scale terribly in my UIWebView. They do allow zooming, but when I release they all (the websites) reset back to the same position. And when I try to scroll horizontally, they just snap back into the original position, which leaves the website impossible to read and my UIWebView utterly useless. If I can't force the mobile page, how can I make the desktop versions act differently?
I forgot to set the constraints for the UIWebView, which caused the content to be rendered wrongly. I don't know how that's relevant, but constraining the UIWebView seems to not only render the content correctly but also display the mobile site.
Related
I am building a webview app that should load a specific website using UIWebView, but the webview doesn't behave as Safari.
A lot of links don't open, and file download and preview doesn't work, also, some JavaScript doesn't work.
Is there a way to make my web view behave exactly as Safari browser?
There seem te be some subtle differences in the Implementation or configuration between WBWebView and Safari (and SFSafariViewController) that renders a part of the Website I want to display unusable.
Here is what I am trying to do:
Basically all that is needed is an "App" that just opens a specific website in fullscreen mode, so no chrome, URLs or additional navigaton buttons are present. The Website works fine on Safari on iOS (and every other (modern) browser on desktop or mobile) but the menu does not when embedded in the App.
All I did was creating a new single view Application in Xcode, drop in a WKWebView and have it load the URL. The part of the page not working is this menu component that is used throughout the site: http://tympanus.net/codrops/2013/04/19/responsive-multi-level-menu/ So basically the user has no way to navigate. While debugging the website it seems like when I push the menu button the menu does not expand like it should because the changed css classes dont get picked up correctly. If I manually toggle the css classes on the menu-element it gets displayed correctly. It makes me wonder if there are some additonal constraints related to WKWebView?
Can anyone tell me if there are any settings or configurations I can alter that allow the website in WKWebView to behave exactly the same as it would under Safari?
As far as I understand SFSafariViewController I always get the browser toolbar and navigational elements which I dont want to have in the app, so that is not an option- or is there a way to get rid of that?
Any help or pointers would be greatly appreciated :)
I am trying to open a specific page of a pdf (for example, http://cb.vu/unixtoolbox.pdf#page=14) inside an iFrame. While it works on desktop browsers, it is not working on an iPad.
Also noticing that, this does not work on the iPad even without the iFrame if I want to go the page 14 by typing http://cb.vu/unixtoolbox.pdf#page=14 directly in the address bar of mobile safari.
Has any of you came across this problem? If so, how did you solve it?
Thanks a lot for any help!
I've observed this on iOS 4.3 to 5.0. When you create a even a simple offline web app, meaning one HTML file + few assets such as CSS and JS (all present in the cache manifest), it works offline (I tested in Airplane Mode) – BUT, when you add such an app to your home screen and open it in fullscreen mode, it first displays initial content, then everything disappears (page becomes white) for half a second or more, then content reappears again.
You can see this by adding Glyphboard, a well-known and useful offline web app, to your iOS home screen and launching it a few times. You should see the white flash effect every time you load it.
This is a big problem because it gives away the non-nativeness of an app and gives the impression that the app is non-optimized for performance and buggy.
I've tried finding reports about this but all I can find is rumors and misconceptions about the iOS 4.3 JavaScript rendering engine fiasco, which doesn't need at all be related to this issue. But in iOS version 3 I distincly remember not ever seeing the white flash.
Clearing the screen and other artifacts while rendering is a common issue of HTML rendering due to the progressive nature of HTML. The concept is that the browser should draw as early and often as possible and render styles/scripts/content as they become available. It's possible the markup has an issue where all rendering is delayed until some content or a script is available. This could happen if:
You have dynamic heights based on image dimensions but you haven't
set the image dimensions in the markup or CSS.
Your layout is based on tables and you aren't using 'table-layout:fixed` in CSS.
Your HTML uses inline scripts with document.write().
You have some kind of onLoad() function that reveals/modifies content.
You link to an external stylesheet.
You're using uncacheable external content or you've disabled caching.
You're using external content that's returning 404 or isn't available offline.
Has your HTML/CSS changed between testing IOS versions?
I've found this to be caused by the use of:
<meta name="viewport" content="width=device-width initial-scale=1.0 maximum-scale=1.0 user-scalable=0">
With a minimal page, I get a white flash between the apple-touch-startup-image and the page contents if I use the viewport meta tag. If I take out the tag, no flash.
It's possible to work around the problem by setting the tag programatically.
I think what happens here is that iOS takes a screenshot from the page when it is added to the main menu. Then this screenshot is displayed during the application loads (WebKit loads). WebKit starts rendering the page and the page itself is constructed in such a way that the page content is not instantly available, leading to a white flash which is a rendered page when page content is not yet there,
You can avoid the problem to a certain level by building your JS/CSS so that it loads the initial HTML view fast and then lazily loads / builds the rest of the resources on the background. Also you can set a custom loading screen instead of the default screenshot iOS uses from the page.
Maybe if you can take yourself a screenshot of your app and then have something like this:
<body style="background: white url('my-initial-loading-screen.png')" />
... and make sure image is available and comes from manifest.
Or even better, have loading screen which does not require any external resources to show (just plain HTML) so you know the browser doesn't need to load anything.
I loaded the Like Box iframe code generated on Facebook into an UIWebView on my iPhone App. It works well, but when I scroll, it scrolls the UIWebView itself, and not the content inside the iframe. How can I block the UIWebView from scrolling (i.e the UIWebView takes the fullscreen frame) and allow the overflowed content of the iframe to scroll instead ?
ps : I tested a simple .html in MobileSafari.app and I have the same problem
You use two fingers in the like box instead of one. Then it scrolls.
You won't have much control over a plugin that is rendered as an iframe due to cross domain restrictions and they do not give many options to customize the appearance.
You could replace it with a Facebook like button. Then below it, you could add code that reads and displays the Fan Page feed using the graph api's page's feed connection (/pageId/feed). This would give you full control over the rendering and still gives the user the option to like your page. To improve performance of this solution you could use the Facebook real-time updates API to get notified when new updates get posted to the page and then you could pull those down and cache them.