I'm facing some problems when browsing trough our webshop using an UIWebview. It just freezes the entire app until loaded (which can take up to 15 seconds). After fast clicking to other categories my app stops responding to touches, but it seems memory and CPU stay stable (30-40mb and CPU stays very low).
I'm using multiple UIWebviews within a UITabbar controller. Anyone an idea what causes this problem? I seem to find multiple questions related to mine, but none solutions given which will also work for me.
I faced the same problem and found out it was caused by an Ajax script on my webpage which took to long. The UIWebview is not a great thing to use, but when the pages are stable, use not to many javascripts, it should work without facing high CPU.
So, take a look at your page, look at the javascript/ajax/jquery and let me know the result!
Related
I’m making an ios app using WKView and I notice that in some pages where there is a big amount of images to load, the webview feeze until the page completely loads all the images. (So, the User Can’t scroll until the page loads for 1 or 2 seconds)
In Safari mobile browser or in chrome this behavior is not happening. I’ve also add “loading=lazy” in all images, but didnt work.
Do you know how to fix this? I spent almost a week with this bug and I Didnt find any solution.
Thanks!
I am having a problem with iOS scrolling on an iPad. Every other platform tested works just fine. I love iOS, but hate it too. I was able to get the entire iframe contents scrolling within the parent, but there are two DIVs that are fixed that shouldn’t scroll within the iframe.
Before I spend a lot of time trying to work this out, I am just looking to leverage everyone’s experience for whether it, in fact, CAN be done. If it IS possible, then I will proceed to trying to work out a simple model and report it back for others. If experience shows that it can NOT be done, then you will all have saved me a lot of headache, not to mention time.
Here’s a drawing of what works on all other platforms but NOT iOS:
Simple question: Is it possible?
The simple answer is, in fact, YES.
I am creating scripted e-books running under iBooks. They do animations using JS setTimeout and/or requestAnimationFrame. After extensive debugging of why animations were running so slowly, I found that the timer was firing, instead of in the 20-50ms that I requested (and get in Chrome or Safari on the desktop), at intervals more than 10 times that long, sometimes as long as one second or more (this is setTimeout, since apparently requestAnimationFrame / webkitRequestAnimationFrame are not available in iOS or at least in the iBooks-ized version of webkit).
After doing further research, I found out this this is apparently not an iBooks issue as much as an iPad issue--I find similar granularity in Safari on the iPad. Is this just a function of a slow processor (I'm testing on an iPad 2), as discussed here?
Or is this related to setTimeout being reported to not function during scrolling as discussed here (although in my case there is no scrolling involved)?
For your information, the types of animations I am doing are not ones that can be implemented using CSS animations which would potentially be hardware-accelerated.
Bottom line, does anyone have any ideas how to get finer timer granularity in JS on the iPad, whether in iBooks or Safari?
I have found the problem was that iBooks reads through the entire book when it is first opened, opening (and running scripts on) each and every page. Furthermore, it does not appear to correctly prioritize requests from the currently open page over its background page pre-reading work, so until the pre-reading process is finished, which could take dozens of seconds on a large, script-heavy book, timer responsiveness (whether setTimeout or requestAnimationFrame) on the current page can be dramatically impacted for the worse.
I am working with some developers who are creating an iOS 5 iPad app for us. I am familiar with coding but my no means an expert. The developers have hit a wall in their code and so I am turning to you guys to check, that there really isn't anything left to try to resolve this problem, before we give up. I've looked around and can't seem to find a straight forward resolution anywhere else, so here's the question to you guys:
The App always has to have four UIWebViews loaded. The UIWebViews need to be able to contain any website out there, be it YouTube, or whatever you can think of (i.e. something like tabbed browsing). We've tried having them on screen and off screen but either way we always run into memory problems.
I know looking to Safari isn't helpful as it's created by the mothership directly, but we're only talking about four UIWebViews here, surely this shouldn't be such a problem? Any ideas...?
Many thanks,
M
There is only one true solution: Create your own equivalent to UIWebView that has only the features that you need, and therefore has a much smaller footprint than Apple's class. I've written such a thing, but it is not public, sorry.
Does anyone know if the iPad has any limitations on the canvas tag?
Currently I'm working on a creative that uses a flipbook and audio tag combination to simulate inline video content. The animations are drawn to the canvas element and synced with the audio content being played. There are 4 short video clips that get played when someone clicks on the four buttons below.
http://cs.sandbox.millennialmedia.com/~tkirchner/rich/K/kungfupanda2_test/
The problem I'm having though is in iPad. After playing a few animations, mobile safari just suddenly crashes. It never happens when I play it on my iPhone but it happens every time on the iPad. Its not one particular animation either because if I click a different combination of buttons, the previous clip that it crashed on plays fine, and then it decides to crash on another clip.
I think the problem might have to do with the amount of memory Safari gives individual page views. I found a blog post that explains that problem pretty well.
http://roblaplaca.com/blog/2010/05/05/ipad-safari-image-limit-workaround/
According to that post, once mobile Safari reaches a particular threshold of memory, images begin to return blank. This is consistant with my finds so far. The iPad that I'm testing this all on is running iOS 3.2.1 (and before anyone tells me that I should just explain to my boss that nobody uses 3.X anymore, I tried... they still want me to investigate this). I borrowed a co-workers iPad running iOS 4.2.1 and that device didn't crash, but some of the images weren't being drawn to the canvas.
I'm pretty sure its a problem with the canvas tag too, because I tried experimenting with running the animation without drawing anything to the canvas element, and the page never crashed.
Thats why I think maybe its a limitation with Safari's support of the canvas tag. Of course, I'm open to anybody else's suggestions.
Feels kinda weird answering my own question again, buuuut I figured if anyone did a search on this kind of question, an answer would be helpful.
I believe my original hypothesis was correct. The total amount of images that the aniamtions were using was around 600+. I think the older iPad loaded as many as it could and then when it ran out of cache and the canvas tag was trying to draw images that weren't really there anymore, it crashed.
Eventually we ended up serving the ad to devices with iOS 4.2 and higher, since the problem didn't seem to occur on those newer devices. Plus, we compressed the image sizes further, so that helped reduce the amount of images we were storing into memory.
If anybody knows approximately what the cache threshold in iOS 4.2 or higher browsers are, I'd appreciate it if you commented. Just want to get an idea of how many KB of image data I can safely load.