I'm working on a presentation app, which displays different images. There I wanted to to let the presentation slide through my List of images, video and pdf files, after a short amount of time.
I start my different views through intents, startActivityForResult(intent, RESULT_OK);
Starting videos and closing videos was not an issue. I used onPreparedListener and setOnCompletionListener and everything worked like a charm.
With pictures however, this was completely diffrent.
I created a new Thread in my ImageView and did put that thread to sleep(), after that I called the setresult() method and finish(). But instead of waiting, the picture wasn't shown at all and the presentation was stuck there, without setting the result and finishing the activity.
So I started searching for some explanation of time in android and found this explanation:
Explanation
I read through it and tried to get a good grasp on whats explained there. But the more I thought about it, the more I got insecure, which is the best way to implement the waiting behavior for my intended purpose.
So instead of some code, I am much more interested in, what you would advise me to use and why with a, if possible, detailed explanation.
elapsedRealtime()?
uptimeMillis()?
System.currentTimeMillis()?
From android docs:
• System.currentTimeMillis() is the standard "wall" clock (time and date) expressing milliseconds since the epoch. The wall clock can be set by the user or the phone network (see setCurrentTimeMillis(long)), so the time may jump backwards or forwards unpredictably. This clock should only be used when correspondence with real-world dates and times is important, such as in a calendar or alarm clock application. Interval or elapsed time measurements should use a different clock. If you are using System.currentTimeMillis(), consider listening to the ACTION_TIME_TICK, ACTION_TIME_CHANGED and ACTION_TIMEZONE_CHANGED Intent broadcasts to find out when the time changes.
• uptimeMillis() is counted in milliseconds since the system was booted. This clock stops when the system enters deep sleep (CPU off, display dark, device waiting for external input), but is not affected by clock scaling, idle, or other power saving mechanisms. This is the basis for most interval timing such as Thread.sleep(millls), Object.wait(millis), and System.nanoTime(). This clock is guaranteed to be monotonic, and is suitable for interval timing when the interval does not span device sleep. Most methods that accept a timestamp value currently expect the uptimeMillis() clock.
• elapsedRealtime() and elapsedRealtimeNanos() return the time since the system was booted, and include deep sleep. This clock is guaranteed to be monotonic, and continues to tick even when the CPU is in power saving modes, so is the recommend basis for general purpose interval timing.
If the time interval, you're going to measure, is relatively short, you can use pretty much any method which gives you correct time. I prefer currentTimeMillis(). In case the time interval is really long, the recommended method is to use elapsedRealtime().
Also, if you only want to do something with a delay, simply use: http://developer.android.com/reference/android/os/Handler.html#postDelayed(java.lang.Runnable, long) . It's simple and works great.
Simplest way to achieve that is CountDownTimer
private final class CountDownTimerImpl extends CountDownTimer {
//5 sec.
private static final long TIME_INTERVAL = 5000;
private final ImageView imageView;
private final List<Drawable> images;
public CountDownTimerImpl(ImageView imageView, List<Drawable> images) {
super(TIME_INTERVAL, TIME_INTERVAL);
this.imageView = imageView;
this.images = images;
//set first image from images array to imageView
imageView.setImageDrawable(images.get(0));
}
//this method is executed after TIME_INTERVAL (5 sec.)
public void onFinish() {
//remove drawable from imageView
imageView.setImageDrawable(null);
//remove this drawable from array
images.remove(0);
//if array is not empty start another count down
if (!images.isEmpty()) {
new CountDownTimerImpl(imageView, images).start();
}
}
public void onTick(long millisUntilFinished) {
//nothing to do here
}
}
You should start this CountDownTimer by:
new CountDownTimerImpl(imageView, images).start();
where images is of course an drawables array of your presentation images.
I have no time to test this solution but it should work - if not please leave a comment and I will update it later.
You can use TimerTask
int counter=0;
final Handler handler = new Handler();
Timer ourtimer = new Timer();
TimerTask timerTask = new TimerTask() {
public void run() {
handler.post(new Runnable() {
public void run() {
counter++;
//you can do stuffs here say like if (counter==15) { do something}
}
});
}};
ourtimer.schedule(timerTask, 0, 1000);
You can do this in a different way writing a callback module
Create a activity call it BaseActivity and let all you activities to extend it
Now declare a method call is void callback(){} keep the body empty
now in onCreate create a timer as above and call the callback function your code will look like
onCreate(){
final Handler handler = new Handler();
Timer callTimer = new Timer();
TimerTask timerTask = new TimerTask() {
public void run() {
handler.post(new Runnable() {
public void run() {
callback();
}
});
}};
callTimer.schedule(timerTask, 0, 1000);
}
Now in you activity override the callback method which will be called after the time you specified in timer,
Ex
Class a extends BaseActivity(){
#Override
onCreate(){
// playVideo
}
#Override
void onCallBack(){
//navigate to another activity
}
}
Related
So, I borrowed a timer approach from this excellent post:
Android timer? How-to?
which was very well-written and well-upchecked. However, I find that it fires approximately every 106-114msec, not the desired 100msec. Does this make sense, or does it seem slow? If I wanted to make this closer to an exact 100msec (I am using it in some places to measure durations), what change should I make?
My code is below
Handler timerHandler = new Handler();
Runnable timerRunnable = new Runnable() {
#Override
public void run() {
TickTimer_Elapsed();
timerHandler.postDelayed(this, 100);
}
};
void TickTimer_Start() { timerHandler.postDelayed(timerRunnable, ); }
void TickTimer_Stop() { timerHandler.removeCallbacks(timerRunnable); }
void TickTimer_Elapsed()
{
m_FSM.Tick_10Hz(); // actually a bit slower than 10Hz
}
Timer is overloaded term in English, meaning either a device that measures time (e.g. a stopwatch), or a device that triggers after a time (e.g. egg timer).
In Android, the timer is for the latter only, and it does not promise absolute accuracy.
"I am using it in some places to measure durations"
In real life, to tell how much time has passed, you would not to watch a clock and count the seconds ticking by! You'd get nothing else done in that time. An efficient way would be to look at the clock just twice and subtract the two times. The same is true with computers:
e.g:
long startTimeMs = System.currentTimeMillis();
Later:
long durationMs = System.currentTimeMillis() - startTimeMs;
i currently work on an app that needs a lot of battery in order to support background gps tracking. my experience shows that people just forget about the app runnning in the background when they dont really need the tracking anymore. therefore i setup some code that should close the application after 4 hours.
public class SelfDestructor {
private static SelfDestructor instance;
private final long IDLE_TIME_UNTIL_AUTO_DESTRUCT = 4 * 60 * 60 * 1000; // 4 hours
private Handler handler;
private Runnable closeApp = new Runnable() {
#Override
public void run() {
System.exit(0);
}
};
public static SelfDestructor getInstance() {
if (SelfDestructor.instance == null) {
SelfDestructor.instance = new SelfDestructor();
}
return SelfDestructor.instance;
}
public void keepAlive() {
if (handler == null) {
handler = new Handler();
}
handler.removeCallbacks(closeApp);
handler.postDelayed(closeApp, IDLE_TIME_UNTIL_AUTO_DESTRUCT);
}
}
now in my main activity i call keepAlive().
#Override
protected void onResume() {
super.onResume();
SelfDestructor.getInstance().keepAlive();
}
#Override
protected void onStart() {
super.onStart();
SelfDestructor.getInstance().keepAlive();
}
now if i set the time to an hours or so and debug the that functionality everything works fine. if i set the time to 4 hours the System.exit(0); is never called. i am assuming the app thread with the close callback is just put on hold by the android system after a while and therefore will not be executed anymore while gps will continue to run. any ideas how to properly get this to work?
handler and postDelayed are not suited for long timers. At most they should be used within a few seconds and personally I think I never used one for anything more than 2 seconds.
Said all that, Android have an appropriate class for "stuff that should happen after a long time", it's called AlarmManager: http://developer.android.com/reference/android/app/AlarmManager.html
you can get the references to the system service AlarmManager by calling Context.getSystemService(Context.ALARM_SERVICE)
and then set it by calling am.set(AlarmManager.ELAPSED_REALTIME, IDLE_TIME_UNTIL_AUTO_DESTRUCT, operation)
the operation is a PendingIntent to a BroadcastReceiver that you register in the AndroidManifest.xml via the <receiver> tag. Then you do the close application code inside this broadcast receiver.
Also I should add that it's NEVER good to call System.exit(0);, as this just destroy the VM without much of a warning. It's a better, more organised/structured shut down if you pass a command to the Service that is holding the GPS (I believe you're running a service), then this service will cancel the GPS request, and call stopSelf();
I'd like to implement several timers (to create a multiple-stopwatches application), and CountDownTimer seems to be the obvious choice, however I'd like to provide the ability to pause one or all of the stopwatches.
From the documentation provided on CountDownTimer I don't see an obvious way to pause the countdown after it has begun, only to stop it or to increase/decrease it by a set amount.
Thanks!
I don't know much about using the CountDownTimer but I know that when I had to make a timer I used the built in Java Timer class with a TimerTask. If you were wanting to make several timers count down and pause them individually you could do something like this
task1 = new TimerTask() {
public void run() {
time1--;
}
};
task2 = new TimerTask() {
public void run() {
time2--;
}
};
Timer1 = new Timer();
Timer2 = new Timer();
Timer1.scheduleAtFixedRate(task1,0,1000);
Timer2.scheduleAtFixedRate(task2,0,1000);
#Override OnClickListener(stopButton1)
{
Timer.Cancel();
}
#Override OnClickListener(startButton1)
{
Timer1 = new Timer();
Timer1.scheduleAtFixedRate(task1,0,1000);
}
This isnt exact syntax but I think it relays the idea. Just a heads up but if you go this route you can't update the UI in that task normally, that would look like this.
Activity_name.this.runOnUiThread(new Runnable() {
public void run() {
text.setText("Level " + Integer.toString(level)+ " will start in " +Integer.toString(time) + " seceonds." );
}
});
which you would put in the "Run" part of the task. This doesn't really have to do with the exact question but I was stuck for days on updating the UI part until someone here helped me out.
I started out using CountDownTimer (but switched to Runnable and Handler.postDelayed).
On timer ticks I decremented a counter. To pause, I canceled the timer. To resume, I created a new timer using the saved counter value. It seemed a little kludgy, but it seemed the only option.
(I don't recall why I made the switch, unfortunately. IIRC at the time there was a reason, but I don't know if it was a limitation of CountDownTimer, or my particular needs.)
I'm making a document reader app and I want a user to be able to ask the app the auto-scroll a document instead of the manual scrolling. Please could anyone give me ideas on how to make a ScrollView "Auto-Scroll" vertically? Sort of like credits at the end of a movie. I set up a TimerTask to this below but my problems are:
How do I get the increment value to feed into the TimerTask i.e the new position the scrollbar should go to each time the TimerTask is run.
Are there any better ways to achieve this auto-scroll feature?
My code is below, I achieved the auto-scroll but the scrolling wasn't even...(totally new to both Java and Android..smile)...thanks!!!
Timer scrollTimer = new Timer();
Handler handler = new Handler();
ScrollView scrollView = (ScrollView) findViewById(R.id.hse);
int scrollSpeed = 5; // this is set by the user in preferences
TimerTask scrollerSchedule = new TimerTask() {
#Override
public void run() {
handler.post(new Runnable() {
#Override
public void run() {
//Here I want to increment the scrollbar's vertical position by 10
//scrollView.smoothScrollBy(0, scrollView.getScrollY() + 10);
new moveScrollView().execute();
}
});
}
};
scrollTimer.schedule(scrollerSchedule, 0, scrollSpeed * 100);
}
private class moveScrollView extends AsyncTask<Void, Void, Void> {
protected void onProgressUpdate(Void... progress) {
// show the user some sort of progress indicator
// like how many minutes before scroll is completed
}
protected Void doInBackground(Void... params) {
// TODO
int scrollPos = (int) (scrollView.getScrollY() + 10.0);
scrollView.smoothScrollTo(0, scrollPos);
return null;
}
}
Changes: Like #Kurtis suggested, I added the AsyncTask to carry out the scroll, and then used the TimerTask + Handler to do the repetition. Now when run the scroll code
int scrollPos = (int) (scrollView.getScrollY() + 10.0);
scrollView.smoothScrollTo(0, scrollPos);
in the AsynTask, I get an error, but when I run the code directly in my Runnable it works as expected. I'm still concerned about efficiency and would really want to use the AsynTask. Any tips on fixing my AsyncTask code?
BTW: This was my observation (for newbies like me). Previously I used
scrollView.smoothScrollBy(0, scrollView.getScrollY() + 10);
and the scroll start jumping unevenly, sort of incrementing the scroll value like +5, +10 +15 +.... instead of an even repetition like +5, +5, +5.... What I found out was that if I wanted to compute the incremental value like scrollView.getScrollY() + 10, then I should have used smoothScrollTo() instead of smoothScrollBy().
scrollView.smoothScrollTo(0, scrollView.getScrollY() + 10);
This is Slideshow demo I created to show the credits for one of my apps. Its source will give you an idea of how to proceed.
You can download the source and import the project to eclipse to try it out.
You should use a combination of AsyncTask to do the scrolling for you and the AlarmManager to do the repeating for you. At a high level, what you should do is create a PendingIntent that is a broadcast. In your activity create a broadcast reciever that recieves the type of broadcasts the PendingIntent will have. Every time that reciever recieves the broadcast is should launch an AsynTask whose doInBackground method is just:
scrollView.smoothScrollBy(0, scrollView.getScrollY() + 10);
Be careful though. Make sure to shut off the Alarm you create with the Alarm manager when ever your activity pauses (i.e. in the onPause method). If you don't you'll be firing off a bunch of broadcasts that never get use. This will drain the users battery. You should then also turn the Alarms back on in the onResume method.
Some other notes, make sure to use ELAPSED_REAL_TIME when setting your alarm in the alarm manager. Otherwise you're scrolling rate will vary with the speed of the processor on the device. You can adjust the time interval at which the broadcasts are sent out to make the view scroll faster or slower.
P.S.
For more advice on threading, checkout the Painless Threading article.
I have a minor problem in one of my apps. It uses a BroadCastReceiver to detect when a call finishes and then performs some minor housekeeping tasks. These have to be delayed for a few seconds, to allow the user to see some data and to ensure that the call log has been updated. I'm currently using handler.postDelayed() for this purpose:
public class CallEndReceiver extends BroadcastReceiver {
#Override
public void onReceive(final Context context, final Intent intent) {
if (DebugFlags.LOG_OUTGOING)
Log.v("CallState changed "
+ intent.getStringExtra(TelephonyManager.EXTRA_STATE));
if (intent.getStringExtra(TelephonyManager.EXTRA_STATE)
.equalsIgnoreCase(TelephonyManager.EXTRA_STATE_IDLE)) {
SharedPreferences prefs = Utils.getPreferences(context);
if (prefs.getBoolean("auto_cancel_notification", true)) {
if (DebugFlags.LOG_OUTGOING)
Log.v("Posting Handler to remove Notification ");
final Handler mHandler = new Handler();
final Runnable mCancelNotification = new Runnable() {
public void run() {
NotificationManager notificationMgr = (NotificationManager) context
.getSystemService(Service.NOTIFICATION_SERVICE);
notificationMgr.cancel(12443);
if (DebugFlags.LOG_OUTGOING)
Log.v("Removing Notification ");
}
};
mHandler.postDelayed(mCancelNotification, 4000);
}
final Handler updateHandler = new Handler();
final Runnable mUpdate = new Runnable() {
public void run() {
if (DebugFlags.LOG_OUTGOING)
Log.v("Starting updateService");
Intent newBackgroundService = new Intent(context,
CallLogUpdateService.class);
context.startService(newBackgroundService);
}
};
updateHandler.postDelayed(mUpdate, 5000);
if (DebugFlags.TRACE_OUTGOING)
Debug.stopMethodTracing();
try
{
// Stopping old Service
Intent backgroundService = new Intent(context,
NetworkCheckService.class);
context.stopService(backgroundService);
context.unregisterReceiver(this);
}
catch(Exception e)
{
Log.e("Fehler beim Entfernen des Receivers", e);
}
}
}
}
Now I have the problem, that this setup works about 90% of the time. In about 10% of cases, the notification isn't removed. I suspect, that the thread dies before the message queue processes the message/runnable.
I'm now thinking about alternatives to postDelayed() and one of my choices is obviously the AlarmManager. However, I'm not sure about the performance impact (or the resources it uses).
Maybe there is a better way to ensure that all messages have been processed before a thread dies or another way to delay the execution of those two bits of code.
Thank you
I'm currently using handler.postDelayed() for this purpose:
That's not a good idea, assuming the BroadcastReceiver is being triggered by a filter in the manifest.
Now I have the problem, that this setup works about 90% of the time. In about 10% of cases, the notification isn't removed. I suspect, that the thread dies before the message queue processes the message/runnable.
More accurately, the process is terminated, taking everything with it.
I'm now thinking about alternatives to postDelayed() and one of my choices is obviously the AlarmManager. However, I'm not sure about the performance impact (or the resources it uses).
It's not that bad. Another possibility is to do your delayed work in an IntentService -- triggered via a call to startService() -- and have it sleep on its background thread for a couple of seconds.
Let's try a new way of doing this. Using RxJava. It's much simpler to prototype and easier to manage lots of threads if you want to ever run hundreds of such delayed tasks concurrently, sequentially, coupled with async tasks, chained with synchronous chained async calls etc.
Firstly, set up the Subscriber. Remember new on Subscriber should be done only once to avoid memory leaks.
// Set up a subscriber once
private Subscuber<Long> delaySubscriber = new Subscuber<Long> () {
#Override
public void onCompleted() {
//Wrap up things as onCompleted is called once onNext() is over
}
#Override
public void onError(Throwable e) {
//Keep an eye open for this. If onCompleted is not called, it means onError has been called. Make sure to override this method
}
#Override
public void onNext(Long aLong) {
// aLong will be from 0 to 1000
// Yuor code logic goes here
// If you want to run this code just once, just add a counter and call onComplete when the counter runs the first time
}
}
The snippet below will just emit the 1 in the onNext() of the subscriber.
Note that this is done on the Computation Threadpool created and managed by the RxJava library.
//Now when you want to start running your piece of cade, define an Observable interval that'll emit every second
private Observable<Long> runThisAfterDelay = Observable.just(1).delay(1000, TimeUnit.MILLISECONDS, Schedulers.computation());
// Subscribe to begin the emissions.
runThisAfterDelay.subscribe(delaySubscriber);
If you want to run a code after every one second, say, then you can do this:
private Observable<Long> runThisOnInterval = Observable.interval(1000, TimeUnit.MILLISECONDS, Schedulers.computation());
In addition to the first answer, you might want to consider what the API documentation says for the onReceive method:
[...] The function is normally called within the main thread of its process, so you should never perform long-running operations in it [...]
So it looks like generally it is not a good idea to start something that waits a couple of time within onReceive (even though, in your case it's less than the 10s limit).
I had a similar timinig problem with the BroadcastReceiver. I couldn't get my results processed even though I onReceive had been called with exactly what I was exepcting. It seemed that the thread the BroadastReceiver was running in, got killed before my result processing could finish. My solutuion was to kick off a new thread to perform all processing.
AlarmManager seems not to work very well for short periods of time like 10 seconds and according to user reports the behaviour heavily depends on the firmware.
At the end I decided to use Handler and Runnable in my service.
When creating the Handler, be sure to create it inside the Service class, not inside the BroadcastReceiver since in the last case you'll get Can't create Handler inside thread that has not called Looper.prepare()
public class NLService extends NotificationListenerService {
private NLServiceReceiver nlservicereciver;
Handler delayUpdateHandler = new Handler();
private Runnable runBroadcastUpdate;
public void triggerViewUpdate() {
/* Accumulate view updates for faster, resource saving operation.
Delay the update by some milliseconds.
And if there was pending update, remove it and plan new update.
*/
if (runBroadcastUpdate != null) {
delayUpdateHandler.removeCallbacks(runBroadcastUpdate);
}
runBroadcastUpdate = new Runnable() {
public void run() {
// Do the work here; execution is delayed
}
};
delayUpdateHandler.postDelayed(runBroadcastUpdate, 300);
}
class NLServiceReceiver extends BroadcastReceiver{
#Override
public void onReceive(Context context, Intent intent) {
triggerViewUpdate();
}
}
}