Image.file() Showing Blank When Specified File Was Explicitly Created - ios

In the iOS variant of my Flutter app, when I explicitly create a .jpg file using
File(path.join(filePath, fileName))
..createSync(recursive: true)
..writeAsBytesSync(buffer);
the widget that renders the file (by calling Image.file(), passing to it the file as an argument) results with a blank image.
No exception was thrown indicating that the file was not found or file contents was invalid. Its behaving as if the file is blank, but when I browse to the file using Finder, the file is there and when I click on the image, Preview renders the expected image.
When the same code is executed when the image comes from the device camera or device gallery, it works and when the same code is executed in the Android variant with the file being explicitly created, it works too.
The only thing I can think of is that it has to do with creating the image deep inside my iOS simulator directory structure
ie-/Users/joselitope/Library/Developer/CoreSimulator/Devices/F2AE8082-E670-498B-B2C6-9A83BE1855A4/data/Containers/Data/Application/7B01A347-69AE-4A1F-8567-7FCC256013F5/tmp/comp_image_cropper_2CC9EEFB-A126-4811-BD80-485B4C41F3A2-18523-00001C049E5AAE85.jpg
but again, the file is visible using Finder so this may not be the reason.
Maybe I have to set certain permissions when creating the file in iOS or perhaps settings applicable to iOS in my pubspec.yaml?
All help is greatly appreciated.
My environment is as follows:
Catelina 10.15.7,
Flutter 1.22.5 channel stable,
XCode 12.3,
Simulator: iPhone 12 Pro Max - 14.3,

Someone posted a suggestion that prompted me to look into this problem again. (That someone has since removed his suggestion so I am unable to thank him.)
Anyways, when I tried to reproduce the problem it wasnt happening anymore even in the exact use case it was happening previously.
So the question remains is why and the only thing I ruled out that it wasnt a race condition as this code has been running on Android for quite some time on various devices.
This is what I could come up with:
Knowing the filepath I was writing to, I realized that I was writing to the app's /tmp directory which iOS periodically empties out. I am thinking that I shouldn't be putting stuff there. Instead, I've been writing to the app's documents directory and it hasnt happened since.
The initial /tmp directory was chosen for me by a package I was using and since it was so long and Im new to iOS, I didn't really look into it all that much, caring only that the file was there, which it was.
Anyways, keeping my fingers crossed that the fix sticks.

Related

Xcode project not opening in Xcode 8 - cannot be parsed [duplicate]

I think I have made a bit of a mistake here.
I designed an app a few months ago and even got it in the App Store. Since then I have purchased a new mac. I copied my Xcode project file across to my new Mac.
I've just come back to it for the first time in months and nothing opens. I sometimes get a cannot be parsed warning. Even looking at the file sizes I think there are all just empty files. When I try and open them in TextEdit they are just empty.
Any ideas anyone, I have a particular .swift file that I really need to open.
Check if the files are empty on your old Mac. If they are empty on your old Mac then the data has been lost, there is nothing you can do.
If the files are correct on your old Mac then something went wrong when you transferred the data. Therefore just try copying them over again.
If the first situation that I stated is true then there is nothing you can do.
Can you not retrieve the original files from your other Mac?
copy and paste
Would imply that you can. Maybe you should attempt to copy the files again, alternatively, if you just need the one .swift file you could probably copy the text from it and put it into plaintext and then copy that back out into a new xcode project if xcode is having such trouble opening that particular file.
Are you sure that you're not missing out some details? Seems almost too easy to answer this one.

What's wrong with this aupreset for AUSampler?

I created this aupreset to be loaded into an AUSampler in iOS. I followed the process outlined here and used the EPSSampler class for the same post. So, if I run my app in the iOS simulator, on iOS 9, the aupreset loads and I get to play notes. If I run the same app on a device running iOS 6, the preset loads but I get no sound. I have used the same process on simulator and device in the past, but always by filtering the built-in sine wave generator, never with audio samples. Can someone spot what I'm doing wrong?
EDIT I have no way of testing the app on any device running iOS above 6, at least for now.
EDIT 2 To clarify further, this is how my project looks in Xcode, so you know that my files are going to the right places – i.e. the audio files are going to the Sounds folder within the app bundle (I double checked, just to be sure).
EDIT 3 So, I took the Trombone.aupreset from LoadPresetDemo and manually plugged my audio files into it. Magically, it worked. So I figured I'd load it into the AUSampler's GUI through AU Lab, and make whatever changes I needed to make it sound right – i.e., increasing the release time. It stopped working. So, i manually tweaked the working copy to roughly match what I needed (the docs on aupresets plists are surprisingly unhelpful) and I'm rolling with it. It would seem that AUSampler is messing up the preset, at least for iOS 6 on device, which, currently, is the only device I have to test on. Insights?
I didn't really look that deeply, but the file://localhost//Library/Audio/Sounds/C.caf in your file references looks a little fishy. Mine looks like this /Users/dave/Library/Audio/Sounds/C6.wav. Maybe the file:// part is throwing it off.
Create a directory in your iOS project named Sounds (just like your image shows) and put your caf files in there. The URLs will be groked by iOS.
Here is a post that goes into detail.

Is application bundle fully replaced on upgrade from App Store?

The following use case:
create a strings file (not localized) and deploy the application to your test device
localize the file (en.lproj or similar), make some changes to the new file and remove the original file
deploy the application on the device
What I noticed that very often (always?) the application will still use the old non-localized file. The reason is that apparently the file is still in somewhere the application bundle, even though it has been removed from the project. iOS's logic is that if a file of a specific type is looked up, it first checks in the root of the bundle for the non-localized version, and only if it doesn't find it does it go deeper into the localized folders. (Is it just me, or is this logic kind of backwards? I'm used to first looking for language specific file, and then falling back to some defaults, but it might be my Java background.)
Sometimes (always?) removing the app from the device completely doesn't help either. What does in this case is a CMD+SHIFT+K, which cleans the build folder, and after the app is built and deployed again, the correct file is used.
A worse problem would be if such a thing leads to an app crash, like some strange issues with Nibs or whatever - I have seen those as well...
The question is: what would happen if the first version of my app in the apple store had the non-localized file, and the second version localized it? When the user upgrades the app, would they get the same behavior as me during development (i.e. outdated, non-localized file used)?
I can't imagine because I think this would be a cause of a lot of grieving and bug requests, but I can't tell for sure as I haven't yet published any iOS app.
If the behavior is correct when upgrading from the store, why is it? What is so different? Are the files stored locally on my computer somewhere and used when I deploy?
Can anybody share their experiences?

CFBundleCopyResourceURL returns NULL in device, but not on simulator

I'm using CFBundleCopyResourceURL to get the path of a shader file in iOS. It returns NULL when run on the device, but works fine on the simulator. What's worse is that this works on another app setup exactly the same way to copy resources. Here are the answers to potential questions that will come my way..
The file is in a folder (shaders/shader.vsh), the folder is in my project as a reference (blue color folder in the workspace under the project). The copy bundle resources build phase has an entry for the folder (shaders)
The first parameter being passed in (bundle) is a valid main bundle which I get by calling CFBundleGetMainBundle(). I confirmed in the debugger that it is valid
I've looked at the package contents for the app image and found the files there. I also looked at the copy commands for those files in the build log and they seem fine.
So clearly, the files are getting copied into the bundle, but for some reason the function fails only on the device in one particular case.
Am I overlooking something else?
The problem turned to be case sensitivity. OSX is case insensitive and iOS is not.
Thanks to Ian Henry for mentioning it.

iOS app suddenly can't find file

Original post:
I've got an iOS app which happily loads files successfully a few times and then all of a >sudden, with no apparent reason, fails to load the files again. The paths all seem correct >seeing as they load successfully to start with... does any one know of any reason this could >happen?
I first noticed this running the app on an ipod touch but it also happens in the iphone >simulator as well. I'm using XCode 4.2 and iOS6.
Edit:
It turns out that the audio system I was using wasn't releasing the audio player objects properly so presumably they ended up keeping file handles open or something, resulting in new files failing to open. Adding in a release to the audio players when they finished seems to have solved the problem or at least significantly reduced the likelihood of it happening!
If you run into similar problems where files won't open you can check to make sure file handles aren't being left open (each fopen should have a fclose with it when the file is no longer needed).

Resources