I am creating an IRC bot using Pircbot that can respond to certain requests (e.g. "!time" provides local time). One of the functions I am building is a giveaway system that randomly selects a user from the currently online users and gives them a prize.
I would like to enhance the system by forcing the winner to type "!accept" within 30 minutes of winning in order to claim the prize. However I would like the bot to still function, meaning I can't freeze the entire thread for 30 minutes waiting for a message.
A few ways I am thinking of doing it feel a bit too hacky to me.
I can store the winner's name in a variable or a .properties file, and constantly be on the lookout for the "!accept" command. If an "!accept" was sent by the winner (the name in the variable) and the message sent time was within 30 minutes, confirm winner. The downside to this is if the bot restarts or is taken offline temporarily in this 30 minute period, it could cause a lot of continuity problems, especially with a .properties file.
Create a runnable thread, sleep for 30 minutes and then check all new messages for the !accept command. This sounds extra hacky with hacky sauce on top.
Dance my problems away.
Mark the time you choose the winner, maybe even have another Thread or Timer event which gets triggered after 30 minutes to reset it.
If the input is "!accept" and is from the correct user AND the difference between the "marked" time and now is less then 30 minutes, happy user
Related
So I have 3 games that my user is allowed to play. When they finish playing these games, just the once, I want to be able to lock them out of the game a period of time (let's say 30 seconds for now). I know you can use handler's and stuff, but I don't think it meets my requirements. When the user finishes the game, they are pushed back to the menu and a timer shows on top of the button to show how long they need to wait, the button is disabled but the others aren't (for the other games), works fine okay. If they exit out of the app or leave it, how do I make this timer continue and not reset?
If you want to transfer data across app instances, you should persist the data in disk.
In this case You can store the time of game ending in shared preference and in Activity onCreate check if the minimum time (30 sec ) has passed since the stored time,
There is a game where 10 minutes of real life equals 60 minutes on his day. So one day in the game equals 4 hours in our real time.
The user will inform me of the time of his game on his first time in the application, and I will need to show the game time to the user every time he enters the application. I tried doing this using a SensorService and a BroadcastReceiver, so that the calculation was always being done.
But since there is no way to get this time the same way we get the normal time, I had to do Background calculations to keep the time counting. This brought me trouble because the time was NEVER displayed accurately, not to mention the problem that is when the user has their cell phone turned off and everything.
I would really like to know if there is a simpler way to do this on Android, I'm new to this area and I do not know if there is a custom speed-time format or something. Thank you all at once.
save the first launch time(normal time).
on succeeding logins game time=(System.currentTimeinMilis() -first launch) * 6
I need a way to limit message count on my IRC bot to avoid a global ban from twitch for chat flooding. (They allow 100 messages/30 seconds)
There are two ways I considered doing this both involving a message queue.
Each message starts a thread which takes a counting semaphore. This thread then blocks for 30 seconds and releases after that time. This would be a very clean solution as the queue would be entirely managed by the OS which means less work for me, however, it may result in creating hundreds of threads. These threads will be sleeping for most of their lifetime, but I'm not sure if it considered okay to launch hundreds of threads that do nothing, effectively. They won't take up time slices from the scheduler when they are asleep but they would consume a lot of memory and there would be a lot of overhead in creating them.
Store a stack of timestamps and if a time-stamp is >30 seconds old remove it every time a message needs to be sent. Have a thread running that checks the bottom of the stack every (10-50ms) to see if the time-stamp is >30 seconds old and remove if it is and then send a message from the highest position in the queue that has not been sent if it exists. When a message comes in to be sent it sends it immediately if there are <# messages in the queue.
1 has the downside of creating many threads that do nothing.
2 has the downside of needing 1 thread to poll the message list constantly.
2 could be improved to calculate the time needed to wait till the bottom message in the stack is 30 seconds old and send the message then, but I feel as if I am overcomplicating the problem at that stage.
Any thoughts on which would be the better approach?
Create a sentMessage list with a date for each entry.
Check the list before posting a new message.
I am writing a program that collects a series of angle inputs during a trial and saves these to a file with their corresponding timestamps.
For example:
1 sec 260 degrees
2 sec 45 degrees
3 sec 60 degrees
etc.
When running a trial, the user should be able to pause and restart or fully abort the trial if need be.
I am running into trouble with the pause functionality. I have been using the Java Timer and TimerTask classes to time the input, as it provides much of the functionality I am looking for (start a task after a delay, only record data at certain intervals, etc.).
Within my timerTask, I have been storing the collected angles and times in parallel arrays, and then at the end of the trial, writing these arrays to a file.
However, when I "pause" my timerTask via the timer.cancel() function and restart it, the old data arrays are thrown away. I have tried to sidestep this issue by saving the "paused" array and then merging it with the "restarted" array at the end of the restarted trial, but this doesn't account for the fact that a trial could be paused numerous times.
Are the timer/timerTask classes the wrong classes to be using for this job? Is there a better way to collect time-based data in Java? Or am I just overlooking a solution?
As the API specifies Timer.cancel()
Terminates this timer, discarding any currently scheduled tasks.
The simplest way to achieve the functionality you desire would probably be to store a 'paused' boolean and toggle it when the user pauses/unpauses. Then check the state of the boolean from within your task and simply return; if the trial is paused. The Timer will still fire every second, but nothing will happen as long as the trial is paused.
I'd like to ask you about the best solution/idea how to solve a following situation.
I'm developing an Android app which on one of screens has a set of buttons. After clicking on any of them a kind of config is posted to the server over http.
To prevent multiple clicks one by one which could result in concurrency problems I decided that after each click on a particular button there'll be a waiting interval of 30 seconds before a config is sent to the server. If another click on the same button happens before this 30 seconds are exceeded, then the execution of method is delayed for another 30 seconds - as long as no new click is performed, then the config will be sent.
I need an idea of an algorithm which would implement the mechanism above. What I know is that I don't want to start a separate thread for each click (too heavy for my app). A potential idea is to make a queue of events and send them in a loop but idea of a running endless loop in a thread (or Handler) also isn't my favourite.
Maybe there's a kind of mechanism in Android or J2SE in general, that allows to schedule an execution of method to a given time in the future but still be able to postopone execution for some additional time before 30sec rolled out.
thanks in advance!