Image not displaying after capture in Offline PWA (Phone profile) using System.Image in Mendix

0
Hi everyone,I’m currently facing an issue with displaying images in an offline PWA mobile app using the Phone_Offline profile in Mendix.Context:I have an entity Photo that inherits from System.Image.The app is configured for offline-first (PWA mobile).I have enabled synchronization for the Photo entity.I use a Take Picture action to capture images from the device.Current Flow (Take Picture + Save):Here is how my nanoflow is implemented:Create object Photo (inherits System.Image)Use Take Picture activity → store image into PhotoCommit object PhotoReturn to page / display in Image Viewer (bound to Photo)Issue:After taking a picture, the image is successfully saved (record is created).However, the image is not displayed in the UI immediately after capture.The Image Viewer shows empty or broken image.Other attributes of the object are displayed correctly.Even after sync, sometimes the image still does not render.What I’ve checked:The Photo entity is included in Offline Synchronization.The Image Viewer is correctly bound to the Photo object.I already commit and refresh the object after taking picture.No errors appear in the console.Questions:Is there any limitation when using System.Image in offline PWA apps?Is the Take Picture → Commit → Refresh flow correct for offline?Is there any additional configuration required for image caching or rendering in offline mode?Are there best practices for handling images in offline-first Mendix apps?Additional Info:Mendix version: 11.7Device: Android/iOS + browserProfile: Phone_Offline (PWA)Any suggestions or guidance would be greatly appreciated. Thanks in advance!
asked
5 answers
0

Hi,


We’ve run into this exact behavior in offline apps before. What you’re seeing is not a configuration mistake — it’s how the offline runtime handles System.Image.

In offline (Phone_Offline), when you use Take Picture, the object gets committed immediately, but the file content (binary) is written and resolved separately. The UI often tries to render the image before that content is fully available locally. That’s why you see the object but not the image.

Your current flow is technically correct, but the problem is using the same in-memory object instance after capture.

What actually works

The fix is simple, but important:

Do not display the same object instance after Take Picture. Always re-retrieve it.

Working pattern

Nanoflow:

  • Create Photo
  • Take Picture → store in Photo
  • Commit (Refresh in client = Yes)
  • Pass only the object ID (or navigate away)

UI:

  • Use a Data View with datasource:
    • Retrieve from database (by ID)

This forces Mendix to load the object again from the local offline database, including the file reference, which allows the Image Viewer to render correctly.

Why this fixes it

In offline mode:

  • Attributes → available immediately
  • File content → resolved after persistence

Re-retrieving ensures the UI binds to a fully persisted object, not a partially available in-memory one.

Additional notes from experience

  • “Refresh in client” is not sufficient for FileDocuments in offline apps
  • Binding directly to nanoflow return objects is unreliable for images
  • This behavior is more noticeable on mobile devices than in browser preview

If it still doesn’t render consistently on some devices, adding a very small delay (200–300 ms) before navigation can help, but usually re-retrieving is enough.

  • This is a known offline runtime behavior, not a bug in your logic
  • Your flow is correct except for one thing: reusing the same object instance
  • The reliable approach is: Commit → Retrieve → Display



answered
0
Hi Gowtham Ramesh
Thanks for your comment. I have tried retrieve object image after take picture but it not show. What happen about it?
answered
0

If you already tried retrieve after take picture and the image still does not show, then the issue is probably not only the object instance.


In offline PWA, the object itself can be available, but the binary content of System.Image may still not be rendered correctly right after capture. So even if the record exists and retrieval works, the UI may still show an empty or broken image.


At that point, I would suggest checking these points:


  • make sure the image widget is bound directly to the Photo object that inherits from System.Image
  • commit the object after Take picture
  • open the image on a new page/data view after commit, instead of staying on the same context
  • test on a real device as well, because browser preview and device behavior can differ
  • also test with a normal FileDocument/Image flow to see whether the problem is specifically related to offline PWA rendering


If it still fails after that, then this starts to look more like an offline PWA limitation with image binary rendering rather than a logic issue in your nanoflow.


So the safe conclusion is: your flow is mostly correct, but offline PWA does not always render captured System.Image content reliably immediately after capture.


If this resolves your issue, please mark it as the accepted answer.

answered
0

One additional detail is that when I use the Phone profile, I can display images. However, when I use the PhoneOffline profile, images cannot be displayed.


Both use the same page, logic, and widgets.

answered
0

That additional detail actually makes the root cause quite clear. If everything works in the Phone profile but fails in Phone_Offline, then this is not related to your nanoflow or widget setup. Your flow (Take Picture → Commit → Refresh) is already correct. The difference comes from how offline PWA handles binary data. In Phone_Offline, the object itself is stored in the local database and its attributes are available, but the binary content of System.Image is not always immediately accessible or rendered right after capture, which is why you see an empty or broken image even though the record exists. This is expected behavior in some offline scenarios and not a mistake in your implementation. In contrast, the Phone profile works because it uses the online runtime and streams the image directly, so there is no local binary limitation. As workarounds, you can try forcing a fresh retrieve after commit and opening the image on a new page (to trigger re-rendering), adding a small delay before displaying the image, or syncing before showing it. If you need a more stable solution, loading images via URL (instead of relying on local binary immediately after capture) is generally more reliable in offline setups. So overall, your implementation is finse. This is mainly a limitation of offline PWA image rendering.


If this resolves your issue, please mark it as the accepted answer.


answered