Reply

srowen wrote:

It doesn't solve the problem of writing contacts though. If you farm that out to a separate app, then it has to able to accept contact information from another app, to write. That other app didn't ask for write permission though. This is a sort of problem with per-app permissions but the ability for apps to cooperate via Intents.

An application that receives an Intent and blindly writes a contact is absolutely a bad idea. The solution to this would be not to use Intents to send the data back.

Specifically, you'd need to use android.os.Binder, probably but not necessarily by using AIDL to generate the (synchronous, IPC) interface. (It actually seems like it'd be easier to implement the interface directly, but since there is a standard mechanism...) I think, but am not certain, that this means the ZXing-library-app would need to extend Android.os.Service.

My original reply had a sketch of a secure request-reply protocol using Intents and the fact that

IBinder/Binder objects [can] be used as a unique identity (to serve as a token or for other purposes) that can be managed across processes[,]

but as it turns out this is probably not a good idea, for at least two reasons:

• Both scanning and displaying are inherently synchronous operations, and a calling application is going to sit around twiddling its thumbs in any case; one might as well use synchronous IPC.
• Unexpected failure of the scan/display app will result in the calling application twiddling its thumbs forever.

(Of course, it's probably safe enough to use Intents for display alone: one wouldn't be expecting any data back, so failure is uninteresting, no? Admittedly I haven't thought that one through.)

I think the idea of separating the apps is interesting. You're asking users to separately download another app, or else forgo this functionality. That's a cost. But it does have the benefit you suggest.

Hmm. I suspect (but can only conjecture) that this cost would be mitigated slightly if you were to package "Barcode Scanner" as a library, like Radar, instead of as an app in and of itself. Then just say 'this application requires the Barcode Scanner library, listed under Software Libraries' -- which, I note, everyone else is already going to have to say. Like that one Barcode Battlers game (or whatever it's called) already does.

This would also help users who have more than one ZXing-using application: only one copy of the library would be taking up valuable disk space. It might also encourage application writers by making them aware of the existence of a barcode scanner library qua library: at present there are only two software libraries at all, so there would be significantly fewer faces in the crowd against whom to stand out.