Cannot replay sound in J2ME - audio

I have problem restart sound in J2ME. I want to create player in constructor, then call playExplosion() to play it, but it only plays once. I'm using Wireless Toolkit.
Sound class
public class Sound () {
private Player playerExplosion;
public Sound() throws IOException, MediaException {
// Explosion
InputStream is = getClass().getResourceAsStream("/explosion.mid");
playerExplosion = Manager.createPlayer(is, "audio/midi");
playerExplosion.realize();
playerExplosion.setLoopCount(1);
}
public void playExplosion() {
try {
System.out.println(playerExplosion.getState());
playerExplosion.start();
} catch (MediaException ex) {
ex.printStackTrace();
}
}
}
MyMIDlet class
public class MyMIDlet extends MIDlet() {
public Sound sound;
public MyMIDlet() {
// Init sound object
try {
sound = new Sound(this);
} catch (Exception ex) {
ex.printStackTrace();
}
// Test
System.out.println("Start");
for (int i = 0; i < 5; i++) {
sound.playExplosion();
// My sound is less than 1 second.
try {
Thread.sleep(2000);
} catch (InterruptedException ex) {
ex.printStackTrace();
}
}
System.out.println("End");
}
}
Output
Start
200
300
300
300
300
End
For the 1st time, playerExplosion state before start() is 200 (REALIZED).
For the 2nd, 3rd, 4th, 5th times, playerExplosion state before start() is 300 (PREFETCH).
At the moment, I have to create playerExplosion again in playExplosion() method, but it's too slow in a real device.

Try after removing
playerExplosion.setLoopCount(1);

Realizing a Player can be a resource and time consuming process havint to create playerExplosion would mean calling playerExplosion.realize(); again that is why the process takes so much time
When your player is in PREFETCHED State what you need to do is just call playerExplosion.start(); but its not paying again because there is a general limitation on the number of times its should pay
Remove
playerExplosion.setLoopCount(1);
And you would be able to pay your file several times
Thanks
:)

Related

Why does the blue tooth low energy scanner need to be restarted again?

I noticed that in a couple implementations of the ble scanner that the scanning is stopped and started again after a given time period, like every 20 seconds.
Here for example here is a scanner class firing up the scanner in a separate thread. You can see in the start() method that the thread is put to sleep for a period of time, and the scanner is then stopped and restarted:
public class BleScanner extends Thread {
private final BluetoothAdapter bluetoothAdapter;
private final BluetoothAdapter.LeScanCallback mLeScanCallback;
private volatile boolean isScanning = false;
public BleScanner(BluetoothAdapter adapter, BluetoothAdapter.LeScanCallback callback) {
bluetoothAdapter = adapter;
mLeScanCallback = callback;
}
public boolean isScanning() {
return isScanning;
}
public void startScanning() {
synchronized (this) {
isScanning = true;
start();
}
}
public void stopScanning() {
synchronized (this) {
isScanning = false;
bluetoothAdapter.stopLeScan(mLeScanCallback);
}
}
#Override
public void run() {
try {
// Thread goes into an infinite loop
while (true) {
synchronized (this) {
// If there is not currently a scan in progress, start one
if (!isScanning) break;
bluetoothAdapter.startLeScan(mLeScanCallback);
}
sleep(Constants.SCAN_PERIOD); // Thread sleeps before stopping the scan
// stop scan
synchronized (this) {
bluetoothAdapter.stopLeScan(mLeScanCallback);
}
// restart scan on next iteration of infinite while loop
}
} catch (InterruptedException ignore) {
} finally { // Just in case there is an error, the scan will be stopped
bluetoothAdapter.stopLeScan(mLeScanCallback);
// The finally block always executes when the try block exits. This ensures that the
// finally block is executed even if an unexpected exception occurs.
}
}
}
Are there any benefits to stopping and restarting the scanner? Why not just let the scan continue perpetually?
There are advantages. On some devices, you would only see an advertisement from a device once per scan. On some you would see all advertisements. Also, restarting the scan cleans up some low-level stuff and is generally better than keeping the scanner active all the time.

Blackberry Thread Image from JSON

I am looking for a way to display images on my ListField from a background thread. First in my drawListRow i try this
path = (String) imagePaths.elementAt(index);
bit = connectServerForImage(path);
g.drawBitmap(xText, y + yText, 80, 200, bit, 0, 0);
but can't scroll smoothly throughout the list, and they say do not do networking or other blocking operations on the UI. But i also try this
private class imgConnection extends Thread
{
public imgConnection() {
super();
}
public void run() {
try {
for (int i = 0; i < imagePaths.size(); i++)
{
final int index = i;
String path = imagePaths.elementAt(index).toString();
bit = connectServerForImage(path);
image.addElement(bit);
}
}
catch (Exception e)
{
System.out.println(e.toString());
}
UiApplication.getUiApplication().invokeLater(new Runnable() {
public void run() {
_list.setSize(image.size());
subManager.add(_list);
screen.invalidate();
}
});
}
}
public void drawListRow(ListField list, Graphics g, int index, int y, int w) {
bit = (Bitmap) image.elementAt(index);
g.drawBitmap(xText, y + yText, 80, 200, bit, 0, 0);
}
but nothing happens. Any idea, comments.
You are right, i just started java development 2 weeks ago particularly BB development and i try this link. I want to add a background thread to download image after i got the path url from json return.
first thread:
_connectionthread = new Connection();
_connectionthread.start();
private class Connection extends Thread
{
public Connection()
{
super();
}
public void run() {
try {}
catch (Exception e) {}
}
}
second thread:
_imgConnectionThread = new ImgConnection();
_imgConnectionThread.start();
private class ImgConnection extends Thread
{
public ImgConnection() {
super();
}
public void run() {
try {
}
catch (Exception e)
{
}
}
}
how to update images on ListField?
Answer is based on code from - pastebin.com/90UKTHzP
Terrible code! It's really hard to read and undersand! It looks like you copy pasted several examples from different locations. Also you overriding default behavior with same behavior. Also MainScreen already has VerticalManagerField. Also you're adding list every iteration to manager which will cause IAE. And main one thread is depended on result of second one. They start at the same time, but getting json from server and it's processing could take longer time, so image thread most probably will finish his run without any result.
So main recommendation to fix it - read clean code book! Read more about java development - conventions, multithreading. Read about BB development - UI api, networking.
And finally - start only one thread to get and parse json. After you get it finished - start another thread to get images.
There some minor things that could save you more battery and processor time also - start loading images on demand - when it painted or going to be painted (user scrolls list).
By convention, Java class names start with a capital letter, so imgConnection should really be ImgConnection.
In your sample code, I don't see imgConnection being instantiated anywhere, and I don't see any call to Thread.start(), which is the way a thread i started. Without Thread.start() it is not surprising nothing is happening - the thread is never starting.

Unable to open camera on samsung phone in j2me

I have written following piece of code. It is used to create camera player. I tested it on nokia phones. It's working fine and I am able to see camera and use its functionality.
But the issue is that when the code is tested on samsung phone it throws Media exception and eventually have to make an exit from the application. Due to this code, my inbuilt camera functionality (i.e. on samsung phone) also stops working. So what's the reason to it?
public void startCamera()
{
try
{
try
{
// if player==null
player = createPlayer();
}
catch (Exception ex)
{
ex.printStackTrace();
ErrorDialog.show(ex, "We are exiting the application.",
"Exit", new com.auric.qrev.scanqrcode.lwuit.ui.Action(){
public void actionPerformed() {
m_objMIDlet.exitApp();
}
});
}
try
{
player.realize();
player.prefetch();
}
catch (MediaException ex)
{
ex.printStackTrace();
ErrorDialog.show(ex, "We are exiting the application.",
"Exit", new com.auric.qrev.scanqrcode.lwuit.ui.Action(){
public void actionPerformed() {
m_objMIDlet.exitApp();
}
});
}
//Grab the video control and set it to the current display.
videoControl = (VideoControl)(player.getControl("VideoControl"));
if (videoControl == null)
{
//discardPlayer();
stopCamera();
ErrorDialog.show("Unsupported:\n"+
"Can't get video control\n"+
"We are exiting the application.",
"Exit", new com.auric.qrev.scanqrcode.lwuit.ui.Action(){
public void actionPerformed() {
m_objMIDlet.exitApp();
}
});
}
mediaComponent = new MediaComponent(player);
mediaComponent.setFocusable(false);
m_cameraScreen.showCamera(mediaComponent);
start();
}
catch(Exception ex)
{
ex.printStackTrace();
//discardPlayer();
stopCamera();
ErrorDialog.show("Sorry,Resources unavailable.\nWe are exiting the application.",
"Exit", new com.auric.qrev.scanqrcode.lwuit.ui.Action(){
public void actionPerformed() {
m_objMIDlet.exitApp();
}
});
}
}
private Player createPlayer()throws MediaException, Exception
{
Player mPlayer = null;
// try capture://image first for series 40 phones
try
{
mPlayer = Manager.createPlayer("capture://image");
}
catch (Exception e)
{
e.printStackTrace();
}
catch (Error e)
{
e.printStackTrace();
}
// if capture://image failed, try capture://video
if (mPlayer == null)
{
try
{
mPlayer = Manager.createPlayer("capture://video");
}
catch (Exception e)
{
e.printStackTrace();
throw new MediaException("Sorry,Resources unavailable.");
}
}
if(mPlayer == null)
throw new Exception("Sorry,Resources unavailable.");
return mPlayer;
}
First things first, you have to realize that printStackTrace() is pretty much useless outside of the emulator unless you are using a Symbian phone.
You can also use java.lang.Throwable instead of separating Exception and Error
You can figure out exactly what happens by gathering information as a String and appending it to a simple lcdui Form while you are testing:
try {
// do something that could potentially fail
} catch (Throwable th) {
myDebugLcduiForm.append("potential failure number xx." + th + th.getMessage());
// if necessary, throw a new RuntimeException
}
You might want to update/repost your question once you know exactly what line of code throws what exception.

Blackberry multi threading issue

I am developping a BlackBerry application which communicates with the server via HTTP requests(javax.microedition.io.HttpConnection). On device, user clicks some UI items, and device sends the requests to server, when the response comes, UI changes. Communication takes place under new thread, while UI thread pushes and pops ProgressDialogScreen.
The problem is sometimes, when response comes and ProgressDialogScreen is popped, UI does not change but after couple seconds UI changes. If you have requested in between when ProgressDialogScreen is popped and when new Screen is pushed, there comes the mess. First oldest new Screen is pushed, and the newest new Screen is pushed. And this situation can be observed like server responsing wrong requests. This problems occur on simulator and device.
The other problem is, sometimes two same response returns for one request. I was able to see these two problems on simulator at the logs, but i have not able to see this issue on device since i can not see the logs.
EDIT:
String utf8Response;
HttpConnection httpConn = null;
try{
httpConn = (HttpConnection) Connector.open(url);
httpConn.setRequestMethod(HttpConnection.GET);
httpConn.setRequestProperty("Content-Type", "text/html; charset=UTF8");
if(sessionIdCookie != null){
//may throw IOException, if the connection is in the connected state.
httpConn.setRequestProperty("Cookie", sessionIdCookie);
}
}catch (Exception e) {
//...
}
try{
httpConn.getResponseCode();
return httpConn;
}catch (IOException e) {
// ...
}
byte[] responseStr = new byte[(int)httpConn.getLength()];
DataInputStream strm = httpConn.openDataInputStream();
strm.readFully(responseStr);
try{
strm.close();
}catch (IOException e) {
// ....
}
utf8Response = new String(responseStr, "UTF-8");
If this code successfully run, this piece of code runs and new screen is pushed:
UiApplication.getUiApplication().invokeLater(new Runnable() {
public void run() {
Vector accounts = Parser.parse(utf8Response,Parser.ACCOUNTS);
if (accounts.size() == 0){
DialogBox.inform(Account.NO_DEPOSIT);
return;
}
currentScreen = new AccountListScreen(accounts);
changeScreen(null,currentScreen);
}
});
public void changeScreen(final AbstractScreen currentScreen,final AbstractScreen nextScreen) {
if (currentScreen != null)
UiApplication.getUiApplication().popScreen(currentScreen);
if (nextScreen != null)
UiApplication.getUiApplication().pushScreen(nextScreen);
}
EDITv2:
private static void progress(final Stoppable runThis, String text,boolean cancelable) {
progress = new ProgressBar(runThis, text,cancelable);
Thread threadToRun = new Thread() {
public void run() {
UiApplication.getUiApplication().invokeLater(new Runnable() {
public void run() {
try{
UiApplication.getUiApplication().pushScreen(progress);
}catch(Exception e){
Logger.log(e);
}
}
});
try {
runThis.run();
} catch (Throwable t) {
t.printStackTrace();
}
UiApplication.getUiApplication().invokeLater(new Runnable() {
public void run() {
try {
UiApplication.getUiApplication().popScreen(progress);
} catch (Exception e) { }
}
});
}
};
threadToRun.start();
}
By the way ProgressBar is extended from net.rim.device.api.ui.container.PopupScreen and Stoppable is extended from Runnable
I preferred to pop progress bar after new Screen is prepared and pushed. This way there will be no new request between request and response.
Why not do:
private static void progress(final Stoppable runThis, String text,boolean cancelable) {
progress = new ProgressBar(runThis, text,cancelable);
UiApplication.getUiApplication().pushScreen(progress);
[...]
Seems like you are parsing on the UI Thread. Please remove Vector accounts = Parser.parse(utf8Response,Parser.ACCOUNTS); from ui thread and do it in a separate thread.

j2me problem with playing multiple sound files

I have a problem with playing more than 2 sound files in a game I'm developing now in j2me MIDP2 in eclipse.
Please advice me the best way for playing multiple "wav" sound files.
I created the following method that is called once when the program starts
public void setSound()
{
System.out.println("Sound on");
try {
p1=Manager.createPlayer(is1, "audio/X-wav");
p2=Manager.createPlayer(is2, "audio/X-wav");
p3=Manager.createPlayer(is3, "audio/X-wav");
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (MediaException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
and every time I need to play one of the sounds I stop the two other players (to insure that no one of them is running p2.stop(); p3.stop();) and start the third one (p1.start();) and every time I have two players stopped (being in PREFETCHED State) the third one is not running and exceptions are thrown.
The Java ME spec is not specific about this, but on actual devices you can usually have only one allocated player at a time, so just stopping a player is not enough. See also this forum post. I found it is a challenge even to deallocate a player properly before playing a new one, so in my own code I resorted to waiting for one sound to end before trying to play a new one.
in j2me there is only one player.More than 1 players are not supported.How execute the sound one sound after another or any other.If u want playing multiple sounds means then u follow the below coding
public class AudioPlayer implements javax.microedition.media.PlayerListener{
Player player;
int count=0;
public void playMedia(){
try{
player = Manager.createPlayer(getClass().getResourceAsStream(audioFiles[count]),"audio/x-amr");
player.addPlayerListener(this);
player.start();
}
catch (Exception e) {
return ;
}
}
public void playerUpdate(Player p,String event,Object eventData)
{
//Playing next audio file after completion of current audio.
}
}

Resources