Learn what Felgo offers to help your business succeed. Start your free evaluation today! Felgo for Your Business


OverviewFelgo 3 Support (Qt 5) › How to deal with partially loaded DownloadableResource?

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #23779



    I`m using DownloadableResource to store images in cache folder.

    But, as it is an image, and can be used in ListView, and delegate can be destroyed before DownloadableResource is actually loaded.

    As an error, when AppImage loads such an image, I have string in logs:

    Corrupt JPEG data: premature end of data segment

    In this case there is no Image.Error status when image loads file from local fs.

    And there is no (visible for me) method to determine is image was really loaded.

    remove() in Component.onDestruction when DownloadableResource  status is Downloading also does not help.

    Also, DownloadableResource status===Available does not mean file is ready (for me, dont know why), its become available after downloadFinished signal, is it correct?

    1) How can I validate jpeg before loading?


    2) How can I detect and remove partially-downloaded file, if DownloadableResource component is destroyed while downloading?


    Felgo Team


    as a first approach, would it be possible t avoid destroying the DownloadableResource item, because it is effectively not designed to just be destroyed mid-download. E.g. have a download manager class in your app root that takes care of the downloads and is not destroyed at runtime.

    Other than that, you’d probably need to analyze the image yourself. As far as I know, Qt uses libjpeg to decode images. Since the AppImage (using a Qt Image internally, which is derived from QImage) does not display an error, Qt does not seem to report possible decoding errors the image. This is just guessing though.




    I’m trying to do the same thing with a SwipeView. I want to use an AppImage then when it fails to load (i.e. AppImage = Image.Null or Image.Error) then my resource manager creates a DownloadableResource and kicks off a download. When it is done it is signalled back to the AppImage to update the source.

    The problem I have is how to set the source on AppImage correctly? It doesn’t know about DownloadableResource (where you’d normally use storagePath) since that it created dynamically after the image fails to load but I need the source in order to attempt loading the image in the first place.

    I can’t build the path used for source myself either. The default storageLocation is FileUtils.AppDataLocation which, on Windows, points to c:\Users\Blah\AppData\Roaming\MyApp. However, if you instantiate a DownloadableResource the storagePath includes an additional ‘\_packages’ subfolder and I don’t know where the _packages subfolder comes from or whether this is cross platform.

    Whilst writing this I’ve realised the only thing I haven’t tried is dynamically creating the DownloadableResource when the AppImage is created and have the download manager check for it’s existance before doing a download. If it’s there then I can emit a signal with the path almost immediately but my concern is as I swipe left and right the performance might not be great as it will always create a DownloadableResource when all I really needed was the path.

    Maybe having a dictionary will help too? That will map the image name to the storagePath then the AppImage can reference that, if it doesn’t exist ask the download manager to create a DownloadableResource and when that’s ready signal to the AppImage (although a change to the dictionary might be bound to the source property of AppImage so it might update automatically.

    I’ll leave this rambling here in case it’s useful to anyone but will try this and reply.


    Felgo Team

    Hi Jon,

    I think following the approach of a global DownloadManager that handles the downloads is still the preferred solution. This keeps the download logic away from the UI code and makes sure the DownloadableResource object is not destroyed when e.g. relevant items or pages are closed in the UI.

    To map a certain download request with the respective file paths a dictionary sounds good. The UI can then ask the download manager to request an image and get the local path of the download.




    I’ve been trying this all day. The AppImage doesn’t load properly when the DownloadableResource becomes available; I end up with unexpected token errors that QtCreator links to in the image itself. If I browse to the image they open fine so they’re not corrupt or partially downloaded at all.

    The array of DownloadableResources was created as a property var resources: { () } and this seems to be a problem. If I use a static DownloadableResource then I can use storagePath and it’s fine so there’s a problem with what is stored in that var array.

    However, I’ve sorted out the problem:

    In AppImage Component.onCompleted make a call to the downloadable resource manager to create a new DownloadableResource with the given url. The manager then needs to create a DownloadableResource using an incubator. When it is ready, start the download. When the download completes, emit a signal with the storagePath and the AppImage handles that by updating its own source.

    I’m not sure why the other method didn’t work but since incubators create instances asyncronously is it possible that with the old method something goes out of scope when the function exits? I’m not sure but at least it works.

    How about creating a DownloadableResourceManager in the next Felgo release?


    Felgo Team


    glad to hear you got it working!

    We’ll have a look if it makes sense to add a download manager as a generic component to Felgo. What is your exact use-case? From what I get you are using a SwipeView to display images, which are loaded on-demand when they are first required in the UI? And at later app-starts they then don’t need to be loaded again if they were already loaded as a resource?


Viewing 6 posts - 1 through 6 (of 6 total)

RSS feed for this thread

You must be logged in to reply to this topic.

Qt_Technology_Partner_RGB_475 Qt_Service_Partner_RGB_475_padded