I preview docs in my app using a UIDocumentInteractionController. However, sometimes documents show fine, other times the interactioncontroller displays a message "Error while reading the document". I know it is not an issue with the document, because the same document sometimes shows and sometimes doesn't.
Restarting the device solves this problem temporarily - so it would appear to be a memory issue, but strangely I am not getting any memory warnings. Any ideas on how to get this to work reliably please?
Notes:
The documentinteractioncontroller preview is dismissed and the
controller released when finished to ensure prior previews do not
remain in memory
I had the same issue using the quicklook controller
After much testing it appears this issue is limited to iPad 1. The only workaround is a restart.
Since you believe that the document in question is correct, and you believe your code is correct, you have to start looking for other factors. Two that come to mind are:
The state of the application. Is there something about the current state of the app that could be preventing the preview from working? You mentioned that you don't get any memory warnings, but have you looked at how much memory the app is using when the preview succeeds and when it fails?
The state of the document. Is it possible that the file can't be opened for some reason, such as the file already being open? Can you open the file by any other means?
It's possible that your app is trying to display the doc before the os has finished writing it to the sandbox dir. The speed of this operation will be somewhat dependent on what else is going on the the background (other apps, email downloading, iOS checking for updates, etc.). This would also explain why restarting the device can seem to fix the problem temporarily.
To check this, you could check for this error and then try again to open the doc after a few seconds.
Without specific code or or logs, it's tough to say much more.
Related
This question is not a duplicate to another question that asks about the same message, but in another context. The context of this question is just about uploading screenshot images and getting the message.
Today, I had a new message when uploading images to App Store Connect:
Invalid GeoJSON: Your routing app coverage file is invalid.
This makes absolutely no sense since, at this time, I had not even chosen a build for the upload.
Retrying to upload the images, it worked. But unfortunately, the message appeared for each language and format.
Is this a bug by Apple or am I missing something? I would guess that uploading images has nothing to do with GeoJSON.
I used Safari. Others seem to have the problem with Chrome. So it occasionally seems to happen on all browsers.
I had this same problem today while uploading App Store Icon on Preparing for submission page. Solved it by removing "-" from my image name.
This is an unusual bug. Apple might be already working on it. It's not coming on any specific browser. It occurs mostly when we are trying to upload more than one images at once.
Apple always keeps their live site maintenance work active, so this is most likely a bug occurring in their live site maintenance. It will be fixed soon.
For now, if you are finding difficulties handling screenshot uploads, you can try to upload them one by one rather than uploading in a bulk.
Important Note:
I am stating this on basis of the last few uploads I have experienced. Also, the solution I have given is tried from my side and it worked for me well. So, you can just try it out and I'm sure that it's not a browser issue. It can occur on any browser.
It did not work for me even if I provided English file names. It kept giving the above error.
Only thing that worked for me was to remove all underscores. So instead of iphone_xs_max_1.png, it worked when I renamed it to iphone1.png and uploaded.
Make sure screenshot files name in English.
Make sure screenshot files all the directory path(and folder name) in English.
it worked for me.
I had the same bug today. Some of the images uploaded without problems, others didn't.
I was uploading in Chrome when I got the issue. Opening the site in Safari and uploading the images there, solved the problem.
What solved this for me was removing strings of numbers and periods from the filenames. It appears the system is running the filenames through some kind of geocoder, and if there are strings of characters that could be interpreted as locations, it will error out.
Make sure after editing the image you save the file with an extension like myimage.png or myimage.jpg
In my case, I forgot to save the file with extension after removing alpha and transparency properties and no need to change browser etc.
So based on my searches this has been a long-standing bug on iOS/Apple’s end. As of yet I haven’t been able to confirm a workaround so would like to see if I’m up to speed on this.
I incorporated a new favicon on my site with the help of realfavicongenerator, and it’s showing up everywhere except Safari iOS where a faulty cache seems to force the old image to show when the site is favorited or bookmarked. Adding to homescreen works fine, MacOS favoriting/bookmarking works fine, Safari iOS doesn’t.
I remember having a similar issue when incorporating the first apple-touch-icon a few years ago, also using realfavicongenerator: when favoriting/bookmarking in Safari iOS the icon was empty instead of showing the image. Eventually it showed up but I don’t recall how or exacty when, but it definitely took a lot longer than it should have.
I’ve obviously tried clearing cache and website data/history through Safari settings, restarting my phone, appending a variable to the apple-touch-icon URL, using both absolute and relative paths, and tinkering with different image size specifications, none of which worked.
I saw a suggestion somewhere that resetting the phone may work, but my question in that scenario is what exactly to reset and whether this would compromise other data.
Are there any workarounds/fixes I’m not aware of?
I’m using an iPhone 7 with iOS 12.2. The code being used is straight from what realfavicongenerator provides.
RealFaviconGenerator's author speaking.
As you noticed, iOS Safari is quite lazy regarding favicon reloading. It is not the only one.
The trick is to force it to reload the icon by providing a URL it never encountered before. A simple way of doing this is to suffix the existing icon URL with a dummy parameter. For example, change /the_icon.png to /the_icon.png?v=2.
To do so with RealFaviconGenerator, generate your icons again. This time, make sure to open the Version/Refresh tab in the Favicon Generator Options panel, and select the second option, as below:
Note: You might want to edit manually the code already created by RealFaviconGenerator and append the version yourself. This might be a bad idea. For example, if you put your icons in your root folder, some HTML lines were not generated (because of conventions RFG is taking advantage of). But suddenly, these lines must be added to specify a version. This is definitely not something you can guess at first sight.
New favicon showed up today, with no intervention on my part (versioning had also been removed). Not sure why. Guess it may be due to a time interval.
I'm taking over an app for a friend who had a developer stop working for him. We want to change the icons of the characters in cocos2d. It's a small running game like temple run. We had a graphic designer create another image with the same size and same file name.
We then simply drag and dropped the image to replace the old ones. At first it was running fine, then when we switched a few more, the game crashed.
just posting as an answer so it may help others too.
What it may be :
hitting the logs would let you know that "failed to load data from xyz.png" which means the file you are referring is not present in the project which in your case may be due to excessive refactoring.
Also, check the extensions ".png" vs ".PNG".
I am using Howler.js on my PhoneGap application. Because my audio files are large (more than 10Mb) im an setting the buffer attribute to true (forcing HTML5 Audio).
var theSound = new Howl({
urls: ['assets/Sound.m4a'],
buffer: true,
sprite: {
scene0 : [ 1966000, 27000] }
When I test my application on the emulator and my iPad Mobile Safari everything works well. But when I run the application on the iPad as an app, the audio never starts. Using the web inspector I have noted that the audio file tries to load again and again like an not ending loop. You can see an attached screenshot of the resources tab on the web inspector both both the emulator and the iPad, running the same PhoneGap app.
Any idea on what could be the problem?
I've been looking into this for a while.
From what I've gathered, Howler defaults to Web Audio API, and this SO answer says you need a "user input event" to make it work on iOS, because by default it mutes everything. I even tried Howler's own interactive demo on my iPad 2 with iOS 5 (I still haven't updated) here and NONE OF THE SOUNDS WORK. My first link has a link to Apple's documentation, and I haven't tried it yet, but it looks like the convenience of Howler has to be replaced with a lower level implementation that takes about 5-10 lines with XMLHTTPRequest (see the Apple link), or another more versatile library. I'm still learning about what exactly I need, but I have a very similar problem I've been working on resolving today.
But then Howler falls back to HTML5 Audio. OK so I'm just googling that now, and this link comes up, and it's just reminding me of the pletora of compatibility considerations between OGG ACC MP3 etc on various browsers vs. browser layout engines vs. operating systems. So I'm left believing your file format M4A, related to MP3 as far as I can tell, isn't working in the target brower on the target iPad OS. I'm not familiar enough yet to give exact specifics but certainly since Howler doesn't work on my iPad that proves there's at least a problem with that.
The whole point I chose Howler to use was to abstract all the above away! I'm going to go look for another more comprehensive library now =D
the problem might be file size. IPad has a limited cache memory size and if you overflow it assets will not work. The only solution to this problem is smaller file size. Another possibility is html audio will not load or play except in a user event (touch). Web Audio will load but starts muted and only unmutes with a play call inside of a user event.
SoundJS is a library I help develop that handles as much of this stuff as possible. In particular I think you would find the Mobile Safe Approach useful. It is well tested on iOS and Android devices. Unfortunately we do not support sound sprites yet.
Hope that helps.
I'm making a website where a user can say which items he wants to cache. Based on this, a manifest file is generated. By doing this the user can still browse in the website when he is offline. This is all working fine in google chrome. But on iPad it's not working as it should.
Sometimes things get cached sometimes not, not even the pages i visited.
We have been testing with 2 iPads all morning, but we haven't been able to get the same result on both iPads. Even if we do exactly the same, we sometimes get different results.
So what we do:
turn WiFi on
browse to the website
make some settings so some pages/images/... are added to the manifest file
turn WiFi off
go back to safari refresh/browse to pages that should be cached.
Sometimes on one iPad (this is an iPad 1) it works exactly as it should, but sometimes it doesn't work at all.
On the other iPad (this is an iPad 2) it never works completely as it should. Just some random results.
It also looks like the results are different when we completely shutdown safari, and then clear the cache and then do the whole process of downloading and caching stuff...
Somebody can help me with this problem? It's a real pain in the ass at the moment... :(
Open web server (IIS)
Select website
Open MIME type
Add or edit to text/cache-manifest
Reset iis at command prompt iisreset
It works for me.
I've encountered some problems as well with ipad caching.
MIME type of the manifest file is not set right due to windows hosting. The standard MIME type on a windows server is "application/x-ms-manifest". This was created when the ClickOnce applications came to life. The MIME type that is necessary to work on safari is: "text/cache-manifest"
Cache size is too small on ipad (you should get a warning to enlarge it)
the Ipad needs time! I've noticed that the cache is not filled when you see all assets or when the website is "loaded". Give it twice the normal time to load before you place the website to your homescreen.
Cache of the cache :) The iPad only reloads the files when the modified date on the server is changed. So when you really want to test, clear all cache on the iPad, remove the link on the homescreen and upload all your files again.
Conclusion: Time consuming!
Hint: Turn on the debug console in safari on your desktop or iPad. It gives a fair idea if you did something wrong or if it is a cache problem on the iPad.
It looks like the problem didn't have anything to do with the application cache. It was somehow a problem with the cookies/the way i was dynamically building the manifest file.
I'd like to slightly echo Pieter-Paulus Vertongen, I had a similar experience with Windows hosting.
According to the debugging console in Safari, the mime type for the manifest file was being misread and nothing was being downloaded as a result.
I copied all of my files, including the .htaccess file, over to a linux server without changing any content within the files...and then the caching worked beautifully.
So yes, it's possible this may be an issue of where the files are hosted. Use the debugging console and Jonathan Stark's code to find out:
http://jonathanstark.com/blog/debugging-html-5-offline-application-cache?filename=2009/09/27/debugging-html-5-offline-application-cache/