i am measuring through put TX and Rx in android thread. how i can put the Max through put in the database every hour. for example thread is calculating throughput every second and save it in the variable. As the hour passes it save the Max value in the data base table.
Use system's AlarmManager feature to set up recurring hourly event and, depending on your application design, your receiver should either tell the app to write data to the DB or do it by itself.
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,
I'm planning to make an app that enables the Mobile Data of the android every X hours for Y minutes. I was wondering which class should I use to schedule this task. Thanks
For tasks for which the user can give you a specific time and date, you can use AlarmManager to have your task executed at that time.
This way, your app does not need to be running the whole time, and will be launched by Android when the time comes.
You can even use the setRepeating() method to set it only once and have it run everytime.
I have an requirement where I have to send the alerts when the record in db is not updated/changed for specified intervals. For example, if the received purchase order doesn't processed within one hour, the reminder should be sent to the delivery manager.
The reminder/alert should sent exactly at the interval (including seconds). If the last modified time is 13:55:45 means, the alert should be triggered 14:55:45. There could be million rows needs to be tracked.
The simple approach could be implementing a custom scheduler and all the records will registered with it. But should poll the database to look for the change every second and it will lead to performance problem.
UPDATE:
Another basic approach would be a creating a thread for each record and put it on sleep for 1 hour (or) Use some queuing concept which has timeout. But still it has performance problems
Any thoughts on better approach to implement the same?
probably using internal JMS queue would be better solution - for example you may want to use scheduled message feature http://docs.jboss.org/hornetq/2.2.2.Final/user-manual/en/html/examples.html#examples.scheduled-message with hornetq.
You can ask broker to publish alert message after exactly 1h. From the other hand during processing of some trading activity you can manually delete this message meaning that the trade activity has been processed without errors.
Use Timer for each reminder.i.e. If the last modified time is 17:49:45 means, the alert should be triggered 18:49:45 simply you should create a dynamic timer scheduling for each task it'll call exact after one hour.
It is not possible in Java, if you really insist on the "Real-timeness". In Java you may encouter Garbage collector's stop-the-world phase and you can never guarantee the exact time.
If the approximate time is also permissible, than use some kind of scheduled queue as proposed in other answers, if not, than use real-time Java or some native call.
If we can assume that the orders are entered with increasing time then:
You can use a Queue with elements that have the properties time-of-order and order-id.
Each new entry that is added to the DB is also enqueued to this Queue.
You can check the element at the start of the Queue each minute.
When checking the element at the start of the Queue, if an hour has passed from the time-of-order, then search for the entry with order-id in the DB.
If found and was not updated then send a notification, else dequeue it from the Queue .
I have found numerous sources for monitoring battery levels, but none of them describe how to check it at a fixed time interval. Suppose I want to check the battery every n seconds. What is the most efficient way to do this?
Currently, I create a BroadcastReceiver and register it in my service with a filter. I then use a ScheduledExecutor to "fetch" the information from the battery. If I understand what's going on correctly, the BroadcastReceiver I made receives all broadcasts from the battery rather at a dynamic rate as they come in, rather than the constant rate I want to check it at.
It appears that when I create the BroadcastReceiver, it receives an "initial" message with the current info. Would it be more efficient to create a receiver object every so often, receive this initial message, then destroy it every time I want to check it? Or, is there a different way that I haven't thought about?
Sources that I used for monitoring the battery, in case if anybody is interested:
http://developer.android.com/training/monitoring-device-state/battery-monitoring.html
http://developer.android.com/reference/android/os/BatteryManager.html
Android Battery in SDK
Suppose I want to check the battery every n seconds. What is the most efficient way to do this?
Unless n is measured in hundreds or thousands of seconds, you may well be the #1 consumer of battery life. Given your comment, I will assume that you really mean "every n minutes".
Step #1: Set up an AlarmManager schedule to invoke an IntentService every n minutes (preferably not with a _WAKEUP alarm type).
Step #2: In that IntentService, call registerReceiver() with a null BroadcastReceiver and an IntentFilter that is for ACTION_BATTERY_CHANGED. The return value will be the last Intent broadcast for this event.
Step #3: Do something with the data.
For my app, I have about 15Mb (which can be compressed with some processing power to about 5Mb) of audio+video+image data that I need to save to disk. For instance, I need to save this when user is interrupted with a phone call (because the activity might get killed after this) and when the user leaves the app.
I can save the data to SD card in about 10 seconds if I don't compress it and something like 20 seconds if I do compress it, where I'd like it compressed. What options to I have for saving my data when onPause is called such that I can be sure the data has been saved?
From some basic experiments, my activity gets killed if onPause hasn't finished after 5 seconds. Some ideas I've had:
Starting a new Thread in onPause and saving the data there. This seems to work fine but seems like something I shouldn't be doing.
Starting a service, copying the data to the service somehow (would this be slow?) and then getting the service to save the data. I think this puts a notification icon at the top of the phone, but I don't think it's awful for a user to see the "Saving data..." task here.
Can I put the data in a SQL database quickly and then save it later when the user returns to the app?
(Due to the nature of the app, there really isn't any practical way I can save the data as I go because the user can transform the data in destructive ways with time consuming operations (e.g. 10 seconds for some operations). Even if I stored the original data and a list of the actions performed to recreate the data, the user would have to wait a minute or two when the app is next started up to process this.)
What options to I have for saving my data when onPause is called such that I can be sure the data has been saved?
Technically, what you want is impossible. There are no guarantees after onPause().
The best answer is what #Viktor Lannér suggested. To phrase it another way, don't wait until onPause() to need to do 10-20 seconds of I/O. Devise some mechanism to allow you to save incrementally as the user performs operations, as a fallback mechanism if nothing else. This is akin to how a database maintains a transaction log.
Starting a new Thread in onPause and saving the data there. This seems to work fine but seems like something I shouldn't be doing.
This is dangerous, because if the activity is closing (e.g., onDestroy() will be called momentarily), Android might terminate your process before your thread is completed.
Starting a service, copying the data to the service somehow (would this be slow?) and then getting the service to save the data. I think this puts a notification icon at the top of the phone, but I don't think it's awful for a user to see the "Saving data..." task here.
Make this be an IntentService, so it automatically shuts down when the work is complete. I wouldn't "copy the data to the service", but rather make the data centrally available, by a static data member if needed. This will not automatically put "a notification icon at the top of the phone", and for something of this duration, that is probably not needed.
Can I put the data in a SQL database quickly and then save it later when the user returns to the app?
Flash I/O is not faster for a SQL database than for anything else.
Due to the nature of the app, there really isn't any practical way I can save the data as I go because the user can transform the data in destructive ways with time consuming operations (e.g. 10 seconds for some operations
Then this probably isn't designed for a mobile platform. Consider whether this app is an appropriate use of the technology.