When creating a NSAttributedString from an HTML string which contains an image link (https), somehow the downloaded image is cached. How did I came up with this fact?
Install app.
Open the app. Image is there.
Close the app (terminate). Go for Airplane mode.
Open the app. Image is still there.
Delete the app completely, and reinstall.
Open app while still in airplane mode. No image.
Caching the image is actually what I want. But I want to know deeper, how and where the image is cached. Since my app should work offline, I have to be sure that the image is cached or not. I dig into the docs and couldn't find anything. Can someone enlighten me? Thank you.
EDIT to clarify:
I am not using NSTextAttachment directly. I'm initializing NSAttributedString from a String, using UTF8 encoded data. Why I am talking about NSTextAttachment is I guess its automatically creating an NSTextAttachment for "img" tags in the HTML String.
As the docs don't state that the images will be cached, it's best to assume that there is no caching. Therefore, the best solution to your situation is to download the file with URLSession and store the file on disk, so when the device is offline, the image can be displayed.
Some digging into the simulator data proved that my image is really cached.
/Users/<username>/Library/Developer/CoreSimulator/Devices/<simulator-id>/data/Containers/Data/Application/<app-id>/Library/Caches/<app-bunle-identifier>/Cache.db file is a SQLite file holding the cache info. And there is my image, with its link and its data.
Its odd that Apple didn't documented this, and I still don't know how / when it caches.
Related
I'm experiencing a large issue right now with XCode and just MacOS/iOS in general.
For background, the website application framework I'm using is laravel and the image editor I use to crop profile images is called image intervention, a quite popular extension for laravel.
To skip straight into it- I'm creating a basic companion application for my website, which, like pretty much all other websites, stores images on the server. This can be reached with the www.mywebsite.com/storage/ base URL, with the addition of the file name on the end. There is a bit more to it, but none of that is the issue.
I've been using it many times already, as there are multiple folders for different image relationships. One folder, lets just call it postimages (so link is now www.mywebsite.com/storage/postimages), returns images with no issue, and I've been using it multiple times up to this point. The code I use in swift to return the different images is as follows (in my specific views)
func getPic(urlLink: String)-> Image? {
let baseURL = "https://www.mywebsite.com/storage"
let url = URL(string: baseURL + urlLink)
let data = try? Data(contentsOf: url!)
let image = UIImage(data: data!)
let image2 = Image(uiImage: (image ?? nil)!)
return image2
}
So this might be badly written or whatnot, but that's definitely not the source of any issue, so approach it as you wish. Anyways, again, I've used this function in multiple views to retrieve multiple different images from different folders on the storage endpoint.
The issue just came up when trying to retrieve images from a different endpoint, specifically my /profileimages endpoint. Up until now, as I've stated, this function has never had an issue. Now, when I try to use it to get profile images, it crashes the app with the error
"Unexpectedly found nil while unwrapping an Optional value"
around the line where it is let data = try? Data(contentsOf: url!).
Now this gave me much grief because the URL (when hovered) showed the
correct URL link, and when I entered them into the browser it returned
the image in question. So why is the image somehow returning nil? I
don't know.
To add to the mystery, I've been trying to work around the issue, by downloading the default profile image and just changing the function to return the default image if there was no data at the URL (even though there should be, 100% of the time).
When I tried to download the default profile picture, by using the https://www.mywebsite.com/storage/profileimages/blank.jpg link, I tried adding it to XCode as an asset and it had a big red exclamation point over it. Trying to open it with preview gave me the error "The file "blank.jpg" could not be opened. It may be damaged or use a file format the Preview doesn't recognize." This is surprising because on my Windows computer, trying to do the same thing has no issue at all.
My suspicion is that because I used the extension to crop and fit the profile images to a square size, somehow in that process of saving it, image intervention corrupted the file, and while Windows recognizes it as JPEG, Swift does not.
I ask any of those who are more experienced with image manipulation please help me understand this, obviously displaying user's profile pictures is vital to creation of a website mobile companion application, and right now I can't do anything besides basic text tabviews without this working as intended.
I'm going to post my own answer as I've been able to solve the mystery. The first problem was the default image was, indeed, corrupted. I made a new one with GIMP and have been using that one instead. Why Windows could still open it and MacOS couldn't is beyond me, perhaps they have stricter guidelines for what constitutes a JPG file and therefore the file sneaks past Windows but not Mac, whatever the issue, obviously replacing the file solved my problem. The second issue was returning nil, which I found out was because I wasn't percent encoding the URL link. Some users post pictures with spaces in it, so I needed to add percent encoding in order for it to work (for some reason). Both of those solutions combined has removed the entire problem I was facing and I no longer have pictures returning nil.
I am facing same issue but I found solution, The image is in webp format, which is specially designed by google for chrome. iOS wont support webp.
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.
I am using transloadit to generate a thumbnail image sent from an iOS app that saves both the original image and the thumbnail to Amazon S3. The files get get saved out correctly with one exception. The file name for the thumbnail does not retain the capitalization of the original filename for the file extension, i.e. JPG vs jpg. Here is my template:
I am using the fields to generate the custom path I want--which works fine, however, the output from the "store_thumb" step has this difference:
Is there any way to retain the capitalization? I realize I can just force all of my filenames from the app to lowercase, however, I thought maybe I am just doing something wrong. Any suggestions?
I'm part of Transloadit's developer support team.
First of all, let me assure you there's nothing wrong with what you're doing. Secondly, I've asked our engineers about the issue and we realized it's a limitation caused by our special usage of some of the conversion tools.
We'll do our best to address this on future versions, but we cannot commit on a date. So for now if it's causing you trouble, we recommend using lowercase letters.
I am attempting to use Imagemagick to manipulate images that are uploaded by a user. Right now I have a simple set of Imagemagick.convert[ ] commands server side that preform a variety of tasks on the uploaded image. My problem comes from Imagemagick needing the file data to be read into meteor and not from a url. What I end up doing is writing the uploaded file to the /public folder where Imagemagick is able to manipulate the image. However because the list of Imagemagick.convert commands (saving and writing to /public), the application keeps refreshing, breaking up the processes and sending it into an infinite refreshing cycle. I don't think assets is a viable solution, but I need some folder that I can write to in meteor that will not interrupt the various Imagemagick processes through a refresh. I have tried the .folder for a hidden folder, but meteor gives me an error: "You can’t use a name that begins with a dot “.”, because these names are reserved for the system. Please choose another name." Any thoughts?
#Nate I wrote a little example app that solves this problem by using a temporary directory (as others have suggested):
https://github.com/ideaq/image-uploads
My solution gives you:
Easy image uploading in any Meteor app
Images are re-sized to Thumbnail, Mobile Optimised and Full-size Original
Images are uploaded to AWS S3 for CDN delivery (scalability and speed)
A thumbnail of the image is displayed on to the user without refreshing the page
if you found a better way of doing image uploads in meteor, please share! thanks. :-)
I've localized my images, but when I change the device language on the fly, the text changes but not the image. If I delete the app and then reinstall I can see the localized image.
Is this just how localization of images works? Or is there a way to make it so that the images change on the fly if the language does?
My guess, based on behaviours I've observed with UIImages and the docs I've read:
When an image is first requested by the app, it's loaded and cached internally by UIImage. At first load, it's path is looked up in your app's resources. This will load the correctly localised image for your current language. This is then cached using some cache key.
I presume the cache key used by UIImage doesn't include the language, and so when you change the language of the phone UIImage still happily returns the cached image. Therefore, the app needs restarting before the newly localised images are loaded so that the resource path is discovered for the new language.
Remember this is conjecture based on my observations!