Native Camera Logic
Dustin Lam
capturing, and I stumbled on this snippet of code, which is part of a
full solution in
http://stackoverflow.com/questions/3442462/how-to-capture-an-image-and-store-it-with-the-native-android-camera
.
------------------------------------------------------------
Uri outputFileUri = Uri.fromFile(sdImageMainDirectory);
Intent intent = new Intent("android.media.action.IMAGE_CAPTURE");
intent.putExtra(MediaStore.EXTRA_OUTPUT, outputFileUri);
startActivityForResult(intent, 0);
-------------------------------------------------------------
It looks like we can take a picture, save it to external space (or
possibly in temp media which might be on the phone?), retrieve the URI
and then pass that to other activities as a String, which is very
convenient and lets us get around having to use persistent activities
or layouts that could clog up performance, but I think
MediaStore.EXTRA_OUTPUT gets ignored on some phones because they
handle the IMAGE_CAPTURE intent differently.
So it looks like we'll have to either write our own camera activity
--OR--
Create something like an invisible TabHost or ActivityGroup and have
all of the activities with the wound image running at the same time.
This is probably less work, but it'll also result in a bunch of ugly
wound pictures being saved onto our poor volunteer's SD Card and
slower performance.
Thoughts? I think most of the newer android phones handle the intent
properly though.
Jon VanAlten
> I've been thinking about details of the workflow for the image
> capturing, and I stumbled on this snippet of code, which is part of a
> full solution in
> http://stackoverflow.com/questions/3442462/how-to-capture-an-image-and-store-it-with-the-native-android-camera
> .
>
> ------------------------------------------------------------
> Uri outputFileUri = Uri.fromFile(sdImageMainDirectory);
>
> Intent intent = new Intent("android.media.action.IMAGE_CAPTURE");
> intent.putExtra(MediaStore.EXTRA_OUTPUT, outputFileUri);
>
> startActivityForResult(intent, 0);
> -------------------------------------------------------------
>
> It looks like we can take a picture, save it to external space (or
> possibly in temp media which might be on the phone?), retrieve the URI
> and then pass that to other activities as a String, which is very
> convenient and lets us get around having to use persistent activities
> or layouts that could clog up performance, but I think
> MediaStore.EXTRA_OUTPUT gets ignored on some phones because they
> handle the IMAGE_CAPTURE intent differently.
>
Yep, a common way to pass information between activities is a URI. We
definitely want to use the EXTRA_OUTPUT to specify a location for the
image file produced. The default would be to appear in the gallery,
which I agree we want to avoid.
> So it looks like we'll have to either write our own camera activity
>
Yes we want an activity that wraps around the IMAGE_CAPTURE activity.
I just wanted to avoid using the Camera directly...
> --OR--
>
> Create something like an invisible TabHost or ActivityGroup and have
> all of the activities with the wound image running at the same time.
I'd rather stick to the traditional Activity stack. An object
containing the wound information (personal data, location/size
information, etc) can also be serialized and passed as URI between
activities, also containing the URI (or URIs, we may want to one-time
process the image in a few standard sizes) for the associated image.
Of course, if you have some compelling reason why using some other API
class in perhaps unconventional ways would be beneficial, I am all
ears.
> This is probably less work, but it'll also result in a bunch of ugly
> wound pictures being saved onto our poor volunteer's SD Card and
> slower performance.
>
If we do things properly, the file can be deleted when we are done
regardless of how stored. I suppose user could forcequit or phone
could crash and in that case the file from the capture in progress
would remain. But that is not a problem I think we can
programmatically avoid. Also it is likely that in the field,
organizations would keep a fleet of inexpensive devices to issue to
volunteers, rather than having each use their personal phones. I am
not that worried about performance, one image is not a lot of data to
access from flash memory.
> Thoughts? I think most of the newer android phones handle the intent
> properly though.
Yeah, let's program to the API spec and not worry about specific
devices for now :)
Maybe this (EXTRA_OUTPUT) is something that was introduced in a
specific API version? Can you find out about that?
cheers,
jon
Dustin Lam
I've never really worked with the native camera application, so I
can't really say. But It's my understanding that in order to get a URI
to where the picture is stored after being taken, we need to pass an
EXTRA_OUTPUT, which we can then grab the URI from in future
activities / when we delete the picture.
I think if we just take the picture, and return the bitmap from the
native camera intent with a startActivityForResult , we only get a
small thumbnail and lose the URI to the original image... which gets
stored in some default directory.
So the idea is to load all of the views with the image in the
background and make them invisible until a button is pushed.. which
actually runs pretty smooth. Of course, if we can retrieve the URI
somehow without PUT_EXTRA, then it'll be the ideal solution for sure.
I'll look into the issues surrounding EXTRA_OUTPUT a little later when
I get some time, cause right now it's FRIDAY FRIDAY and I GOTTA GET
DOWN.
On Jun 10, 10:31 am, Jon VanAlten <vana...@gmail.com> wrote:
> > I've been thinking about details of the workflow for the image
> > capturing, and I stumbled on this snippet of code, which is part of a
> > full solution in