Android random time delayed user abortable infinite loop

by Ronoli » Wed, 22 Dec 2010 06:47:42 GMT


Sponsored Links
 Hello, can anyone show me the proper way to resolve my problem?,
I'm trying to to play a sound repeatedly but I need it to play with a
random delay.
When I grab a random number and start looping my sound, sure it plays
some random time later and continues to do so. But I want to use a new
random number for the delay between each loop.

Pseudo code:
1) Grab random number. (java.util.random).
2) Change that random number to represent seconds.
3) Pause or wait for that random amount of seconds.
4) Play sound from soundpool. (just mimic this as my soundpool is
working fine)
5) Grab new random number and repeat steps 3 through 5 and repeat this
process until the user cancels with a button.
6) Enable the user to cancel this loop at any time.

I would really appreciate a little help if someone can find the
time....
Thank you in advance,
javat...@gmail.com

-- 



Re: Android random time delayed user abortable infinite loop

by TreKing » Wed, 22 Dec 2010 12:53:32 GMT


 




I do think I understand what your actual problem is. What, specifically, are
you having trouble with given your pseudo-code description?

-------------------------------------------------------------------------------------------------
TreKing < http://sites.google.com/site/rezmobileapps/treking> ; - Chicago
transit tracking app for Android-powered devices

-- 


Sponsored Links


Re: Android random time delayed user abortable infinite loop

by Ron Richmond » Tue, 28 Dec 2010 01:51:09 GMT


 Hello and thanks for the reply,
It's really the user abortable loop that I'm having trouble with now.
Since first posting my problem, I have been researching code snippets and
have zeroed in on this one:

import java.util.Timer;
import java.util.TimerTask;
import android.app.Activity;
import android.os.Bundle;
import android.widget.TextView;

public class DelayTimer extends Activity {

    TextView mTextField;
    long elapsed;
    final static long INTERVAL=1000;
    final static long TIMEOUT=5000;

    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.main);

        mTextField=(TextView)findViewById(R.id.textview1);

        TimerTask task=new TimerTask(){
            @Override
            public void run() {
                elapsed += INTERVAL;
                if(elapsed >= TIMEOUT){
                    this.cancel();
                    displayText("finished");
                    return;
                }
                //if(some other conditions)
                //   this.cancel();
                displayText("seconds elapsed: " + elapsed / 1000);
            }
        };
        Timer timer = new Timer();
        timer.scheduleAtFixedRate(task, INTERVAL, INTERVAL);
    }

    private void displayText(final String text){
        this.runOnUiThread(new Runnable(){
            @Override
            public void run() {
                mTextField.setText(text);
            }});
    }
}

I think I should be able to replace the static long INTERVAL with a call to
java.util.random
in a way that would work for me. However, I can't even get this example to
finish/abort/end properly.
After running this example, I have to go to "Manage Apps" and click "Force
Close" to kill it.
I'm not really sure if this is example is the best way to handle it either
but it is where I seem to be
zeroing in on. Any suggestions?
Thank you sooo much for your help,
Ron






-- 



Re: Android random time delayed user abortable infinite loop

by Bret Foreman » Tue, 28 Dec 2010 02:02:53 GMT


 Well first, you need a call to finish() somewhere in order to exit the
Activty.

-- 



Re: Re: Android random time delayed user abortable infinite loop

by Ron Richmond » Tue, 28 Dec 2010 02:09:50 GMT


 Thank You,
I will be working on my problem today as I was pulled away from it for a few
days (Holidays!)
Thanks again, I really appreciate any and all help!!
Ron





-- 



Other Threads

1. Moto XOOM not loading xhdpi drawables

Hi,

I have an app that has default drawables in the drawable folder.  I
have both a drawable-hdpi and a drawable-xhdpi folder set up.  When I
launch my app on the XOOM the device seems to be picking up the
default drawables and NOT the ones in the xhdpi folder.  Has anyone
come across this?  My manifest is set up with,

    <uses-sdk
        android:minSdkVersion="4"
        android:targetSdkVersion="9" />

    <supports-screens
        android:smallScreens="true"
        android:normalScreens="true"
        android:largeScreens="true"
        android:xlargeScreens="true"
        anyDensity="true" />

I know that xhdpi was available as of sdk version 8...

Regards,
Mark

-- 

2. Whats the real point of a tablet?

I own a Galaxy Tablet and I love using the thing, I use it all the
time at home for browsing, watching videos, music, etc. It's pretty
much always with me while I'm at home.

However, one thing that was bugging me the other day was a thought I
had while contemplating adding more advanced features to my apps for
use on tablet devices.

I write audio apps for Android, and I was thinking about new features
I could add to my apps to make them more powerful for use in "live
play", etc. But then I realized something: What is the point of it? I
mean, if a musician wanted to have a portable device with some nice
software that they could use live on stage, wouldn't they just be
better off getting a tablet PC or a small notebook? Then they could
readily grab any software, even open source free software, and use
that as their DAW or live instrument.

I'm just not seeing a good reason to develop a "deep" functional app
for use on an android tablet when I'm wondering if it's really
"duplicating" software that would be better run from a PC. A PC that
would no doubt have much more power than the tablet ever would and
could give better features in the software anyway.

To me developing a fairly deep app for use on a phone is worth the
time, since the phone is extremely portable and always with you, but
for a tablet? Not so sure that's a worthy investment in time or not,
especially since you have to do better optimizations since the tablet
won't have as much capability as a PC would (less memory to work with,
slower CPU, etc)

I mean the only real advantage of a tablet is you can have a touch
screen interface with multitouch, so for some apps, yes, this is a
benefit. But for other apps that's not something that's a big deal.

What's your guys's take on it? Is it worth trying to supply a "deep"
app for a tablet when a PC variant is readily available (and laptops
are cheaper than tablets anyway?)


-niko

-- 
.

3. how to make sure that devices is connected after rebooting

4. Bug in Honeycomb solves Bitmaps with XRGB_8888

5. SQLite and Collate UNICODE

6. Reflection API:List all classes in a package that extend a specific super class

7. Test Location in Emulator