Hello,
I want to fetch all the images on an iOS device and display them in a GridView. I am aware of two methods for instantiating a vanilla iOS ImagePicker from Qt, but this is insufficient because I want to do multi-selection and UIImagePickerController apparently does not support this!
What I tried to do instead (using the Photos framework, because the Assets Library framework is deprecated as of iOS 9.0) was populate a QStringList with image URLs (e.g., file:///var/mobile/rest/of/path/to/IMG_XXXX.jpg) and pass that as the model to a QML view for display in a delegate, per the docs here. Worked great when the delegate was a Label. Yay! Did not work at all when the delegate was an Image. For each path, the complaint was the same: I did not have permission to access the file referenced by the URL. Boo! Hiss!
Perhaps I jumped the gun at that point, because I turned to cobbling together a minimal solution developed entirely in Xcode (v7.3.1, targeting a device running iOS 9.3.2) using objective-c. Interestingly, you can't display images using the filename in that context either, unless the image is included in your project as an asset. You have to sling the image data itself. Works alright, though there are some performance warts, which is fine for now. But I've applied the brakes, because I would really like to implement this project using Qt in order to target Android in future. So, I have a few questions before truly blazing down the pure Xcode/obj-c path.
- Did I miss something in my original efforts using a QStringList passed as the model to a view with delegate? If so, what?
- A stock QML Image accepts a url as its source, not the image data. Would subclassing QImage, for example, and registering the subclass as a QML type be a way around this? If so, what is the relationship between NSData * (which is what you get from the Photos framework, and which has a bytes property) and uchar * (which is what the QImage constructor accepts)?
- Does it make any sense at all, from a cross-platform deployment perspective, to simply launch a bunch of interconnected iOS view controllers from Qt, i.e., creating an objective-c++ class that has-a instance of the root of the view hierarchy, which spins off everything else in pure objective-c? I don't really like the sound of that, but maybe there are some different opinions?
Any insights are much appreciated.
Bookmarks