I have been researching Services, but I cannot figure out a way to do something periodically. I realize that when a service is called, it calls the OnCreate() method and the onStartMethod() but what I want to do is do a process every 10 minutes or so (subject to change). So in which method/how would I make the service execute code on an interval of a certain time?
I'm sorry if I missed something in the Android documentation.
[EDIT]
More specifically, I want to update some information and see if it is any different than the existing one -- and then issue a taskbar Notification to the user.
You probably want to check out AlarmManager, it's an easy way to do what you want. It'd also be nicer in terms of memory usage, battery, etc. than keeping a service open for 10 minutes just waiting to do something.
http://developer.android.com/reference/android/app/AlarmManager.html
Related
I'm using Android Studio to develop and application and I'd like that when a certain moment of time is met the application performs some defined action.
I know I could create a service that continously checks for actual time, every little seconds and if it happens to be equal or bigger than the needed time it performs the action, but doing it this way looks too resource consuming.
Is there some way in Android to do something like when a defined time comes, an interruption is sent and the defined action is fired?
It would be enough with supporting a soft time event, it doesn't mind for my application for the event to be fired some seconds later.
Thanks for helping.
Yes take a look at AlarmManager it will let you do an action in a specific time
If you need to check some external databases once every X seconds/minutes, then you may consider using a Handler & Runnable with postDelayed() method to achieve what you need.
I am building a fitness app which continually logs activity on the device. I need to log quite often, but I also don't want to unnecessarily drain the battery of my users which is why I am thinking about batching network calls together and transmitting them all at once as soon as the radio is active, the device is connected to a WiFi or it is charging.
I am using a filesystem based approach to implement that. I persist the data first to a File - eventually I might use Tape from Square to do that - but here is where I encounter the first issues.
I am continually writing new log data to the File, but I also need to periodically send all the logged data to my backend. When that happens I delete the contents of the File. The problem now is how can I prevent both of those operations from happening at the same time? Of course it will cause problems if I try to write log data to the File at the same time as some other process is reading from the File and trying to delete its contents.
I am thinking about using an IntentService essentially act as a queue for all those operations. And since - at least I have read as much - an IntentServices handles Intents sequentially in single worker Thread it shouldn't be possible for two of those operations to happen at the same time, right?
Currently I want to schedule a PeriodicTask with the GcmNetworkManager which would take care of sending the data to the server. Is there any better way to do all this?
1) You are overthinking this whole thing!
Your approach is way more complicated than it has to be! And for some reason none of the other answers point this out, but GcmNetworkManager already does everything you are trying to implement! You don't need to implement anything yourself.
2) Optimal way to implement what you are trying to do.
You don't seem to be aware that GcmNetworkManager already batches calls in the most battery efficient way with automatic retries etc and it also persists the tasks across device boots and can ensure their execution as soon as is battery efficient and required by your app.
Just whenever you have data to save schedule a OneOffTask like this:
final OneoffTask task = new OneoffTask.Builder()
// The Service which executes the task.
.setService(MyTaskService.class)
// A tag which identifies the task
.setTag(TASK_TAG)
// Sets a time frame for the execution of this task in seconds.
// This specifically means that the task can either be
// executed right now, or must have executed at the lastest in one hour.
.setExecutionWindow(0L, 3600L)
// Task is persisted on the disk, even across boots
.setPersisted(true)
// Unmetered connection required for task
.setRequiredNetwork(Task.NETWORK_STATE_UNMETERED)
// Attach data to the task in the form of a Bundle
.setExtras(dataBundle)
// If you set this to true and this task already exists
// (just depends on the tag set above) then the old task
// will be overwritten with this one.
.setUpdateCurrent(true)
// Sets if this task should only be executed when the device is charging
.setRequiresCharging(false)
.build();
mGcmNetworkManager.schedule(task);
This will do everything you want:
The Task will be persisted on the disk
The Task will be executed in a batched and battery efficient way, preferably over Wifi
You will have configurable automatic retries with a battery efficient backoff pattern
The Task will be executed within a time window you can specify.
I suggest for starters you read this to learn more about the GcmNetworkManager.
So to summarize:
All you really need to do is implement your network calls in a Service extending GcmTaskService and later whenever you need to perform such a network call you schedule a OneOffTask and everything else will be taken care of for you!
Of course you don't need to call each and every setter of the OneOffTask.Builder like I do above - I just did that to show you all the options you have. In most cases scheduling a task would just look like this:
mGcmNetworkManager.schedule(new OneoffTask.Builder()
.setService(MyTaskService.class)
.setTag(TASK_TAG)
.setExecutionWindow(0L, 300L)
.setPersisted(true)
.setExtras(bundle)
.build());
And if you put that in a helper method or even better create factory methods for all the different tasks you need to do than everything you were trying to do should just boil down to a few lines of code!
And by the way: Yes, an IntentService handles every Intent one after another sequentially in a single worker Thread. You can look at the relevant implementation here. It's actually very simple and quite straight forward.
All UI and Service methods are by default invoked on the same main thread. Unless you explicitly create threads or use AsyncTask there is no concurrency in an Android application per se.
This means that all intents, alarms, broad-casts are by default handled on the main thread.
Also note that doing I/O and/or network requests may be forbidden on the main thread (depending on Android version, see e.g. How to fix android.os.NetworkOnMainThreadException?).
Using AsyncTask or creating your own threads will bring you to concurrency problems but they are the same as with any multi-threaded programming, there is nothing special to Android there.
One more point to consider when doing concurrency is that background threads need to hold a WakeLock or the CPU may go to sleep.
Just some idea.
You may try to make use of serial executor for your file, therefore, only one thread can be execute at a time.
http://developer.android.com/reference/android/os/AsyncTask.html#SERIAL_EXECUTOR
I have a small Android app that I have been working on that logs GPS data to my SD card in a GPX file. I currently have a main Activity that starts a Service to do all the background work. The service is kept in the foreground in the notification bar to make it the least likely thing to be killed by the OS. Currently I am requesting location updates from the service at the maximum frequency to get the most accurate route. The problem I am having is my User Interface is acting slow/strange. Correct me if I am wrong, but what I have concluded is that I have too much going on in the main thread of the app. My next thought is to try and move the service performing the acquiring and logging of data to a separate thread. I am new to Java/Android so the whole topic of interacting with separate threads is hard for me to wrap my head around. Initially in research I came across IntentServices, which are supposed to make threading easier, but from what I read these don’t seem to mix well with the Android location package because they don’t run long enough. I feel like I am running in circles with internet searches on this topic. I desperately need some guidance on how to achieve the following features for my programs service:
Separate thread from Main Thread
Fetching and storing of data must be the least likely thing to be killed by the OS and run indefinitely once started (don’t worry about battery I will have the device plugged in to power while running the app)
Eventually I will need the ability to interact with the User Interface
Thanks for any help you can offer!
this is a common problem that i have accomplished a lot on
in the launcher or main() ( what Android is calling an Activity ) you do as little as possible ( which amounts to saving the the refs they give you and maybe setting a few other things as long as you are there ) and do ^not^ drop in to a long-running activity
A Service is exactly what you need but instead of trying to pump it into a "hold on to it" state what you do is implement checks for nulls and handle as needed -- trying to "fix" a machine to make it run the way you want here actually involves rescinding you hold on the main thread and letting it go as fast as consistent with the Applicaton's general constraints.
To do this you can simply write a Service - reading everything available - then extend that service and implement Runnable then you run the constructor on that code from the Activity Constructor and do new Thead(yourClass).start(); in the onCreate() checking for Thread.isRunning() before starting it again ...
Service will have an onCompletion() call in it somewhere - it will go through an interface
All this is done in Android in something like start activity for result then you just to the UI stuff in that call or sorta figure out a way for the GUI to get called somehow at some time then check to see if Service is done an so report in the gui
I have some questions about executing SQL queries (to an online database) from an Android app.
Since these are network operations and they are costly, should I be doing them in a separate thread? Also, what should I show the user (UI) while these queries are processing?
I suggest you to make a use of AsyncTask. In the doInBackground() method you'd be downloading/processing stuff. In the onPostExecute() you'll be displaying on the UI. This is in short. Research base on AsyncTask for further information.
The first answer is good with regards to AsyncTask. If they're REALLY long queries, I would put them in a service and communicate back to the activity with a broadcast, but if they're just "network long", then Async is good.
It seems like EVERYBODY wants to use a waiting dialog, but this kind of UI generally sucks. It blocks everything, so if you can't get a response or whatever, the user is stuck. I recently reviewed an app for somebody, and because our network was slow, the time spent waiting in an alert box was 47 seconds. Any idea how long that feels to a user?
I would disable a repost, put some kind of spinner up, but don't block the UI. If the user wants to do something else, let them. Also, when the AsyncTask comes back, the screen that it expects to manipulate may no longer exist. Wrap everything in case you get an exception.
I try to do all remote stuff in a service, even if it isn't totally necessary. Talk back and forth with broadcasts. That's just me, though ;)
I have a 4x4 widget and i want to update a little piece of it every 15-20 seconds. Clearly i don't want it to be updated when the phone is in standby. The widget needs also to respond to some system events other than my timer. So, which is the best option?
An AlarmManager: nice but probably cpu intensive if it needs to be run every 20 seconds
An Handler: light but i dont know how to stop it when phone sleeps
A service: also here i need to understand how to stop it when phone sleeps
I will also need to update a little part of my widget without updating all its screen area, is this possible??
Thanks everybody.
I have a 4x4 widget and i want to
update a little piece of it every
15-20 seconds.
Please make this optional or configurable.
So, which is the best option?
A Handler has nothing to do with app widgets.
An always-running service is bad for business and is the sort of thing that causes users to attack you with task killers.
The best of the bad options is AlarmManager.
Frankly, the best answer is "don't update a little piece of it every 15-20 seconds".