How do I delete pictures from the camera roll

When using the Rho api take_picture, I noticed that the photograph that was taken, is stored in the camera roll as well as in the Rho db directory.

As the save_to_shared_gallery option is not supported for Android, how do I delete the pictures that are stored in the camera roll??

Michael Toews
Rob, Have you tried the

Rob, Have you tried the deleteFile method of the RhoFile API?

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Rob Geraedts
Michael, thank you for your

Michael, thank you for your comment.

I have looked at the File API. What I can figure out, though, is how to get the path to the Camera roll directory. Do you know if there is a way to fetch that, somewhere?

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jon Tara
In most OSs, there is no

In most OSs, there is no "camera roll directory", at least as far as applications are concerned. You have to work through a native camera API. Applications don't get direct access to the camera roll directory.

deleteFile will let you delete the image stored in your Rho db directory.

There does not seem to currently be any provision in the camera API for removing an image from the camera roll.

Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Rob Geraedts
Jon, Thanks for your

Jon, Thanks for your elaboration.

This is what I feared.

In Rho, we use the camera API to take pictures. These pictures are stored within the Rho app, but they also get a copy in the Camera "space". When deleting the picture within Rho, the other copy of the picture remains. As Rho deleteFile API does not allow us to delete the picture copy in the camera space, our customers are faced with the problem that they have to go into the "Gallery" app and delete them manually.

For a business app, this is unwanted behavior! Our application is for law enforcement and it is not allowed to store pictures of vehicles or people on a device, unmanaged.

So, please....eh...Zebra, can you fix this!!

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Kutir Mobility
Hi RobIts interesting to the

Hi Rob

Its interesting to the reason from business app perspective.

I just checked it with whatspp, facebook kind of apps and its does store a copy in "camera role/gallery" space.

May be its a feature by default ?

Visnupriya R

Kutir Mobility

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jon Tara
Rob, did your app put the

Rob, did your app put the photos on the camera roll?

Our apps store photos, but when we take a photo from within the app, they are stored only within the app. Of course, if we choose a photo from the photo roll, then that photo also remains on the photo roll iif/when it is deleted in the app.

We currently only develop for iOS, so don't know how Rhodes acts on other platforms.

Can't speak for other OSs, but in iOS, there is no way to correlate your internal photo with one on the photo roll. All interaction with the Photo roll must be through system-provided dialogs that let the user choose photos to copy or delete. There's no way to do it without using the system dialog (so the user is always in control, not the app). So, there's no ID or other kind of "handle" to give you a reference that you can come back later and use to delete the photo. There's no need, since Apple insists the user must control this. Similar to how they handle SMS, which I know has frustrated some developers here: they will not allow an app to send an SMS without user interaction through a system-provided dialog, thus preventing any app from sending any unapproved SMS. There are some things that Apple will simply not permit blanket-permission. Getting the user's location: check. Sending SMS or deleting photos without a system dialog? No, not even with permission from the user.

Other OSs may handle it differently.

Vote: 
Vote up!
Vote down!

Points: 1

You voted ‘up’


Rob Geraedts
Jon,Our app does not put the

Jon,

Our app does not put the photo's on the cameral roll (not intentionally, that is...). As soon as we use "take_picture" we see that, apart from having stored the photo in our app, the photo is also saved in the gallery.

We develop on Android and the only thing I can think of, is that the API behaves differently on Android. The documentation states that the "save_to_shared_gallery" option is not supported on Android and that it is default False. I'm starting to suspect that it could be default True on Android.

I hope Mot.... eh Zebra can shed some light on this. Is this "default" behavior for Android?

Rob.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Robert Galvin
Rob,Are you using this

Rob,

Are you using this version of the API: Rhomobile | Camera API

Also what specific device and version of Android are you using? Can you also share a screen shot of the Camera app?

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Mark Nongkhlaw
>We currently only develop

>We currently only develop for iOS...

Jon, just curious here, if you don't mind, if you're developing only for iOS, why have you chosen Rhomobile instead of Objective C or Swift? Is it because of experience in Ruby & Rails or something else which Rho gives you and which other tools, including the afore-mentioned don't?

Thanks.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jon Tara
Mark,Development of the

Mark,

Development of the products I work on goes back 3-4 years. I didn't choose the platform, as the project pre-dates my involvement. I had other Rhodes experience before, though, and in that case I'd chosen Rhodes because of the similarity to Ruby/Rails.

We support "bring your own device", and the original intention was to support iOS and Android. Over that time, we've found Android bring-your-own-device to be difficult to support because of the variety of devices and reluctance of Android users to update the OS and inability to update depending on device. So, then, we had to modify from bring-your-own-device to bring-your-own-approved-device with a small number of selections. Ultimately, we found most users just preferred iOS devices. We put some considerable effort into supporting iOS well (taming the Forms Assistant and intrusive scrolling of the WebView during form-filling) with iScroll, which would require further work on Android.

I think that many Rhodes developers developing for Android do not face the severe problems of bring-your-own-device, because they are writing for a specific Motorola device or family of devices. In that scenario, I'd think twice before also supporting BYOD. (That might commonly occur with some specific device doing some data collection, and then management BYOD.) Get management a dedicated tablet that is known to work well!

We may support Android again in the future.

I would currently start any similar project in Rhodes, as well, though, even if only single-platform iOS. It is a unique platform with unique capabilities and well-suited to this type of app. (It is a LARGE form-filling app - 6 apps, actually, with much common code) with many, many models. The effort to create a native app would be prohibitive. I recently took a look at Xamarin with a potential client, and don't find that an attractive solution at all. IMO it takes nearly the effort of native.

Yes, I have a Ruby on Rails background, which certainly is one of the attractions of the platform for me. It allows me to leverage techniques I already knew. As well, there is a large codebase of open-source Gems that can be drawn upon. (This, as well, is one of the strengths of Xamarin, as there is a huge amount of C# code available.)

I do not find the Javascript-only solutions attractive, though I have done PhoneGap projects. I haven't done a PhoneGap project big enough to use an MVC platform, and that's where I would draw the line on PhoneGap. Apple has made changes in iOS8 that make PhoneGap more attractive, though, because they have taken the WebView out of the "no compilation to machine code" penalty-box (vs. Mobile Safari). Until iOS8, Rhodes has a considerable advantage, because even though bytecode, Rhodes Ruby code runs very fast on iOS vs. Javascript. For my purposes, it is "close to native" speed.

(Sorry for the topic drift, I thought it would be interesting for others.)

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Mark Nongkhlaw
Ok, thank you for the

Ok, thank you for the insights, Jon. I was wondering, because for many people (me included), the cross-platform capability was what attracted them to Rho. And I believe the original creators, Adam et al, had this in mind. Its rather sad that that has taken a kinda beating lately, especially after the acquisition by Moto. Not to sound offensive, though, I believe they have their priorities. I just hope the cross-platform capability is strengthened rather than diluted in the future and that Ruby will continue to be supported.

Sorry to the OP, I did not intend to hijack this thread.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Dmitry Soldatenkov
Hi,Comment this code (line

Hi,

Comment this code (line about 350) :

  try {

  if (uri != null) {

  osCommon = getContentResolver().openOutputStream(uri);

  }

  }

in [rhodes root]/platform/android/Rhodes/src/com/rhomobile/rhodes/camera/ImageCapture.java

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Robert Galvin
RobChange the code Dmitry

Rob

Change the code Dmitry mentioned to:

OutputStream osCommon = null;

  try {

  if (uri != null) {

  // osCommon = getContentResolver().openOutputStream(uri);

  }

  }

and make sure you do a "clean build". This will prevent the file from being saved in the Android Gallery by default. We will look to expose this capability in a newer Camer API we are working on.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Rob Geraedts
Thanks Gavin!We will give it

Thanks Gavin!

We will give it a shot.

Rob.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Rob Geraedts
Rob,  Thanks for the solution

Rob, 

Thanks for the solution!

We've commented that line of code. It seems there are no images saved to the gallery (at TC55 anyways).

How can we make that changes persistent / make sure all the developers have this modified part of the code?


Rob

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Rob Geraedts
Thanks Dimitry, we'll have go

Thanks Dimitry, we'll have go!

Rob.

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jan van Dijk
We've commented that line of

We've commented that line of code. It seems there are no images saved to the gallery (at TC55 anyways). How can we make that changes persistent / make sure all the developers have this modified part of the code?

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Jan van Dijk
Hmm... there are still black

Hmm... there are still black images with size 0,0 saved to the gallery... which is a bit better (space & privacy wise) but still not ideal...

How can we prevent the creation of these black empty images?

Vote: 
Vote up!
Vote down!

Points: 0

You voted ‘up’


Log in to post comments