[sbwoodside]

Hi Nokia, for some reason you switched the image capture URI to "capture://image" in the Nokia 6280. Please, please don't do that on any of the other phones. Switch back to "capture://video". If you don't I'm going to have to write code into my software that says something like this:

    String plat = System.getProperty("microedition.platform");
    if( plat.startsWith("Nokia6280")
      || plat.startWith("Nokia12345")
      || plat.startWith("Nokia12346")
      || plat.startWith("Nokia12347")
      || plat.startWith("Nokia12348")
      || plat.startWith("Nokia12349") ) {
         return "capture://image";
    }
    else { return "capture://video"; }

and i'm sure you can see that leads to major pain, and you'll break my app on every new phone that you release. So don't do it. Go back to "capture://video". Thank you.

--simon

[break10ose]

YES!

Please stay compliance to JSR specification and industry norm.
Is starting to be a pain to write apps to work with Nokia.

[hartti]

I got some answers from Series40 organization
There is a good reason for having separate locators for video and images. As the camera hw is modal (you have to initialize the hw either in video mode or in still image mode) and if you want to take a picture in video mode, the hw have to be changed to still image mode first and hence serious shutter lag is experienced. With separate locators the hw can be initialized to the correct mode and the user experience is much smoother.

Instead of hardcoding a list of product names your could try other approaches:
- verify whether the getSnapshot() method is valid on a capture://video locator, and if not, attempt to use capture://image instead
- getSupportedContentTypes() can be queried for the capture:// protocol, and if "image" is returned, it can be assumed that the capture://image locator is used for taking photos.
- attempt to create a capture://image Player, and if it succeeds, use it in place of capture://video

Hartti

[Liyo]

hello hartti.... can you pls... do it in code....
im getting an empty result if a supply capture:// in getSupportedContentType...
and how will i verify if whether the getSnapshot() method is valid on a capture://video locator or not...
tnxs....

[Liyo]

ok got it..

[matpowel]

Originally Posted by Liyo

hello hartti.... can you pls... do it in code....
im getting an empty result if a supply capture:// in getSupportedContentType...
and how will i verify if whether the getSnapshot() method is valid on a capture://video locator or not...
tnxs....

Hi,

Great info in the previous post.

Liyo, this is easier anyway I think:

-- snip --
try {
// new phones with dual mode hardware need to be initialized
// to "image mode" but older models don't support this..
player = Manager.createPlayer(image_schema);
} catch (Exception ignore) {
// fall back to the old style uri
player = Manager.createPlayer(video_schema);
}
player.realize();
-- snip --

Worked for me.

//matt

[selenatan]

        try{
            mPlayer = Manager.createPlayer("capture://video");
        } catch (Exception e) {
            try{
            mPlayer = Manager.createPlayer("capture://image");
            } catch(Exception e2){}
        }

i tried the above. cant seem to work. pls help

[ykasidit]

Like matpowel said, you should check for this new "capture://image" support before checking the "capture://video".

I used a similar solution, try something like this:

try
{

Object p = null; //you can use Player instead of 'Object'
try
{
//some nokia s40 phones - try this first because capture://video would pass here but fail on taking pic
p = javax.microedition.media.Manager.createPlayer("capture://image");
}
catch(Exception e1)
{
//ok, this device doesn't use the capture://image thing
p = javax.microedition.media.Manager.createPlayer("capture://video");
}

((javax.microedition.media.Player)p).realize();

//do the rest...

//add a catch to match the outer try...