This can happen when the object does not match entity access constraints. The device will then not be able to link the uploaded file to the Mendix Object.
For example: the user may only see objects related to their account through some association to Account or User. If the app does not set the association, the object is created but cannot be seen anymore, causing this error. The same can happen when the user may only see objects with a certain enum value. Note that objects created in an offline app do not receive defaults specified in the domain model. You have to explicitly set them.
Edit:
If it is intermittent it may be a connection issue. I have that in an app which uses the default image uploader. The app is used on devices in the browser but is not a hybrid app. Every now and then an image upload just fails, The page uses a microflow button as save button. In the microflow I check whether the hasContents flag is set. If not, I kindly request the user to re-take the picture.
Maybe you can check in your commit microflow that is connected to the camera widget whether the image object hasContents flag is set.
Hope this helps.
Monique,
Sounds like the Camera Widget may not have permission to store files on the phone. Maybe you can test a scenario where the user hasn't granted access to the app to access local pictures and see if you get the same error. Another idea: maybe phone storage is full so the picture can't be saved?
Mike
Last week I executed some tests to see the impact of the image quality setting of the camera widget. The default value for the image quality settings of height and width are set to 0. This means the image will be saved full size.
If you choose to upload a 3024x4032 picture with size 2,03MB, then it the system needs to transfer 323,99KB over the network. However if you change the image quality to 500, then it the system needs to transfer only 4,93KB.
Given the top smartphone snappers around, these devices make awesome pictures nowadays, but in most use cases there's no need to store the full sized image in your database. So it's a best practice to limit the size of the picture.
Also please note that the description of the image quality in the read me is not correct. The image quality is used to scale the image, and not a number between 0 and 100. I have created a pull request for an update of the readme.
The HasContents gets set by the system when the object gets stored, such as the binary file for the image. Checking it lets you know if the image actually got stored or if it got lost during a connection failure. What Marcel is suggesting is spot on. Your users are trying to upload large image files which can easily fail. Wilfried's suggestion to limit the size in your app is a very sound one if possible though we don't know the requirement of the app. If you need to store hi-res images that are large in size, I suggest designing a UX process that informs the user of the challenges and then gives them the option to sync on cellular and do the HasContents verification, or give them an option to sync when connected to WiFi only. Takes a bit of engineering but will result in a better experience for your users and app designers.