I'm writing an Android app in java. Trying to make a simple rhythm game where you just tap the button on a beat. I was using a timer object with Schedule at Fixed Rate to make the button flash but then I discovered that the time is variable by a few milliseconds.
Obviously a rhythm game needs particular timing to come out right, so is it possible to make this more precise and accurate or am I barking up the wrong tree with using this method for precise timing?
I don't know for Android but here is what happens for "real" Java...
A Timer uses System.currentTimeMillis() to keep track of time; this method is sensitive to system time changes (say, you run an NTP server for instance).
Which is why, if you want better precision, you use a ScheduledExecutorService; this relies o System.nanoTime(), which is a nanosecond precision counter which keeps increasing for the life of the process, even if the system time changes.
So --> try a ScheduledExecutorService instead.
I suggest you don't use ScheduleAtFixedRate!! Use a Looper and Handler.sendMessageDelayed()
Related
With the languages and libraries I've worked so far, there was always an option to sync the main loop of the program (a game or anything with an always changing context) to the current display's refresh rate. So I had the option to either switch on VSYNC or just let the loop execute as many times per second as it could. I'm referring to SDL2, OpenGL 3.0 with GLFW, the HTML5 canvas etc.
I'm looking for something similar on Android now in OpenGL ES 2.0, but so far all the example code I can find simply uses a variation of sleep and set the framerate to 60 or 30. So they basically count the amount of time passed since the last iteration, and only advance further and call the requestRender() function if a given amount of time has passed (0.016 ms in case of 60 frames per second etc.).
I'm simply wondering if there's a better option than this or not. I'm just concerned that not every phone has the same screen refresh rate, so hard coding any amount doesn't seem to be a desired method. As far as I understand it is not that simple to figure out the given phone's refresh rate, or at least it is not possible with "pure" Java and OpenGL.
What you need to do is match the display's frame rate, and advance game state according to how much time has elapsed since the previous frame. There are two ways to go about this:
Stuff the BufferQueue full and rely on the "swap buffers" back-pressure.
This is very easy to implement: just swap buffers as fast as you can. In early versions of Android this could actually result in a penalty where SurfaceView#lockCanvas() would put you to sleep for 100ms. Now it's paced by the BufferQueue, and the BufferQueue is emptied as quickly as SurfaceFlinger is able.
Use Choreographer.
Choreographer allows you to set a callback that fires on the next VSYNC. The actual VSYNC time is passed in as an argument. So even if your app doesn't wake up right away, you still have an accurate picture of when the display refresh period began. Using this value, rather than the current time, yields a consistent time source for your game state update logic.
source: https://source.android.com/devices/graphics/arch-gameloops
I want to create a Reminder application with a similar idea like this, but this implementation only have at most one alarm/reminder at a time (ie. when an alarm starts, we can only configure another alarm after the most recently fired alarm has finished). Where do I start if I want to implement an application that can fire off multiple alarms?
My initial idea is like this:
For example my reminder application has 10 alarms for today, 20 alarms for tomorrow, etc (a certain number of alarms at a certain day). Should I just create a fixed amount of threads and process the alarms one day at a time? Or maybe I can reuse a timer and timer task but dynamically change the delay value? Please help shed some light for this.
Should I just create a fixed amount of threads and process the alarms
one day at a time?
No, just create a thread when it's needed, to be honest you can just have a clock checker within your application and a table or some data structure which holds type of alarm, time, whatever else there and create thread only when it's needed, it will play sound, wait for termination, etc. (basically user input) or just wait for it to die after it will be done with its work. You can have some kind of fixed iteration amount.
Where do I start if I want to implement an application that can fire
off multiple alarms?
Think about what kind of features you want to add, this will pretty much shape design of your application, design yourself some kind of manager of alarms, and system to create an alarm at a certain time.
Make sure you use FXML and force yourself to keep things organized, since your application can get bigger as you go on and add additional features.
Think about what data will be shared between threads since it's highly possible that you will not like to let threads/alarms overlap each other // for instance when they will have "remind in 5 minutes" //, or just terminate alarm that's about to cross into another one, if user doesn't terminate its alarm within that period and it just keeps going and another one is gonna be started, make sure that there is an entity or some higher controller class which takes care of this. If you don't wanna limit this to some minute interval maximum.
This application that you have in your mind is quite small and trivial you might be able to avoid most problems.
Keep it simple, this might be a best advice anyone can give you.
Bud it's just my personal take on this, these kind of questions will attract opinion based answers.
Ever played Candy Crush? Know how you run out of lives and have to wait 30 minutes to regenerate a new life and up to a maximum of 5? That is idea I am trying to implement in my app but I am uncertain on how to have code running even when the user closes app and/or phone.
My question is how to have a timer constantly running in the background of phone until the timer hits X minutes. Would I use the Timer class for this? Because I am familiar with that class and already have a form of it implemented in my app.
There are two pieces to your question:
To actually have a timer running so that you have an action taken after a certain period of time, use the AlarmManager. This should only be used if you are going to proactively interrupt or notify the user.
Your scenario doesn't actually need a timer, and it's more efficient not to use one unnecessarily. Instead, store a timestamp. When your app is opened again, compare the current time to the timestamp and calculate the effect. In the regenerating-lives example, you'd compare timestamps, see that 100 minutes have passed, divide by 30 minutes, and add 3 lives (maybe keeping the extra 10 minute remainder).
If you want timer to run in background you may use AlarmManager. You can set Alarm at specified intervals or you can set it in service if you want single shot alarms. Also while using AlarmManager beware that if your phone goes down then all alarms you've set will be vanished. So take care that you are saving alarm times before phone goes off. Take a look at:
http://developer.android.com/reference/android/app/AlarmManager.html
While using AlarmManager, use correct PendingIntent flags or you could lose previous alarms. If you still want more information you can raise here or have a google.
I don't think you can keep a timer running for you application even when the application is closed. Here is an idea i think about:
You need to start a timer when the life is gone and your application is running.
On your application close event, save that timer value in a persistent storage such as file
On appliction start, read the timer value from the persistent storage, and restart the timer for the remaining time
Once timer expires, generate a new life.
Hope it helps!
I found this answer that might be of great help. Hope it helps others.
There are several different approaches.
You can make use of the System's AlarmManager.
You can make your own Service.
You can make your TimerObject persist.
Check the link for the complete answer and links.
SystemClock.uptimeMillis()
This call from the Android SystemClock will reset back to zero before it 'Maxes Out'
Right now I use this to base off animations, movement etc below is an example of where a reset would essentially freeze my application.
if (currentTime > frameTime + sequenceTime)
{
frameTime = currentTime;
}
Here lies the problem currentTime is say 50 then the frameTime is set to 50 right? Ideally the currentTimewould increase with the SystemClock.uptimeMillis() but if its reset? The currentTime becomes very small compared to the frameTime How would I go about fixing this or reset the currentTime for all objects?
This is just a small example if I have different objects having a similar dilemma.
From my reading of the documentation, the "uptime" clock only gets reset when the device is rebooted. Unless your application ... somehow ... manages to keep running over a reboot, you shouldn't need to worry about the clock resetting.
(On the other hand, if your application does need to do animations that keep going after a reboot, then maybe you should use the 'currentTimeMillis' clock. The Android documentation for SystemClock describes the alternatives.)
The documentation says this "Note: This value may get reset occasionally (before it would otherwise wrap around).".
This doesn't make a lot of sense to me. The clock is a millisecond clock and is returned as a long, so you would not expect it to ever wrap around. (2^64 milliseconds is a very, very long time.) The only explanation I can think of is that some devices use a 32 bit hardware timer to implement this clock ... which is kind of lame.
I want to make a program that will make a pop-up appear at a certain time in the future, eg. 5:00 tonight. Basically, the program is a reminder/notification system for appointments, meetings, etc.
My first instinct was to create a sort of "Clock Listener" that would check the computer's time every minute or so and see if currentTime == alarmTime. However, I don't know if this takes up too much resources or if it is just a bad practice to have your program constantly doing things like that. Also, for the alarm to be accurate, I think it would need to check every second, rather than every minute (since if it isn't checking the seconds and will go off at 5:00:xx, it could go off at 5:00:59, which may be too late for some people's liking). Is checking the clock every second too much?
My second thought was when the program starts running, calculate how long it is until the alarm is set to go off (say, in five hours). Then, wait five hours, and then sound the alarm. But then I thought, though unlikely, it would be possible for the user to change the computer's time, and then the alarm would go off at the wrong time. So this doesn't really work.
I've seen some solutions that use threads, but I'm not familiar with those yet, so I'd rather not use them.
I'm leaning towards the first solution, but I want to make sure it's efficient and won't slow down other programs. Perhaps I'm overthinking it and checking the clock is a trivial operation, but I just wanted to make sure I'm not doing anything wrong.
The sleep solution is very straightforward, but using java.util.Timer is not much harder, and gives you a clear way to extend your utility for multiple alarms, etc. Assuming you are going to use Swing to display the notification, note that your TimerTask will need to perform some of its work on the Swing event thread. SwingUtilities.invokeAndWait(...) will help you with that.
The first solution is OK. Waking up, checking the time, and going back to sleep should not be a problem at all. You can check every second if you want, but if you only need 1-minute resolution perhaps it is enough to check e.g. every 30 seconds.
The second approach has the problem you have outlined already. If you just go to sleep for the time remaining, and the user changes the time (or the time is changed by some other means, e.g. synchronisation with a time server), the alarm would go off at the wrong time. You could avoid this if you could register some sort of hook so that your program is called back when the system time changes, but you cannot easily do this in Java.