Well, i've interesting problem. I have a widget, something like reminder, which shows few nearest items on screen. Each item time, when it comes. I need to show only items, which are in the future, not passed items. As regular update can be done at least every 30 minutes, its not enough for me (my items has tiems like 11.54, 12.07, etc). So i have only 1 option = schedule an service, which can update screen in any interval i want (for example every 5 minute).
But this is not very good for me, because i have 2 requirements, which are a little bit fighting together:
run very often (<5 minutes)
do not use too much of battery and other resources
So - is it possible something like intelligent update? I mean for example algorithm like:
a) update screen every 1 minute when device is unlocked (=user is doing something with phone)
b) but do not update when device is sleeping (its useless, as user can't see result of update)?
Or at least something like "run every 5 minutes, but only from 8:00am to 8:00pm during working days"? Simple intelligent service scheduling...
So i have only 1 option = schedule an service, which can update screen in any interval i want (for example every 5 minute).
There are other, more efficient options, like AlarmManager.
is it possible something like intelligent update? I mean for example algorithm like
An intelligent algorithm would recognize the fact that you only need to update the app widget when the list changes, not every minute, second, or millisecond.
Use AlarmManager to set an alarm for one minute past the first item on your list. When you get control from the alarm event, update the app widget, then use AlarmManager to set an alarm for one minute past the next time on your list. Also update your app widget when the list changes from other sources (e.g., UI, sync process), and if that might cause you to need an earlier alarm, cancel your current alarm and schedule a new one using AlarmManager.
Related
I am trying to introduce auto-save functionality on one of my Android applications. The idea is that as the user inputs first name, last name and after a fixed interval I would like to save that information to the server before the user hits Next button. The final goal is to have something similar to the draft option in the Gmail app where your email information is automatically saved. So, if there is a timer that runs every 10 seconds, I will pass the information on the screen to the ViewModel and let it deal with the logic of saving the data to the server.
A couple of options I have explored are.
Execute recurring code with a specified interval using Handler.
PeriodicWorkRequest -- however this option has a minimum interval of 15 minutes which is a little too much for my use case.
AlarmManager -- This option runs even if your application is not currently running, In my opinion, this option can be an overkill.
I wanted to know if there are best practices/blogs around this and if anyone I on the wrong path or potential red flags with this approach.
you can make countdown for 10 second, when countdown is down save the data and call the countdown again.
when your activity is destroyed, so stop the countdown
This question is vague but I am not sure what to Google for exactly.
But in my app I have a section where you create a list of tasks with various attributes, and a lot of these numbers are summed up and displayed in daily totals visually. But these daily totals should reset every 24 hours (based on the hour of the day the user chooses for the cutoff, e.g. 3 am if someone works late).
Right now: my database can hold all the data by day. Then my daily counters will visually display the numbers by pulling the corresponding data from the database looking for the current day. That's the easy part.
The hard part: I can refresh the counter after the time cutoff if the user rotates the screen or restarts the app because then it'll be looking for items in the database with a new day that won't be found, so everything will be 0 as intended. But what if the user is just staring at the screen as the time cutoff rolls by? How do I make the app refresh the counters once the time hits? What if they're not even using the app at all (either it's minimized in the background or not even active).
Do I need to have some kind of always-running loop in the background that checks the current time against the values in the database? If so, isn't this inefficient if it's always needing to pull values from a database based on time? What's the correct practice for something like this?
You can setup a service and schedule that service to run periodically so that it does whatever job you want it to do
maybe this article can help you.
Alarm manager and services will be ideal for you to implement to do something for your requirement.
Services : It will be running all the time irrespective of your life-cycle of activity.
Alarm manager: Inside services use alarm manager to trigger event to update UI at regular interval.
Finally you can use Local braodcast reciever to update your Activity from services.
You can check implemetation in details below :
Android update activity UI from service
Regarding the problematic stated below I have come to a point where I need to make a decision on whether to:
Start a Service once that has an AlarmManager inside which then starts the query every 10 minutes. This Service will only be stopped if the user sets an "Onn-Off" Switch to "Off".
Use an AlarmManager to start an IntentService every 10 Minutes. This Service will then only be started when needed and closed afterwards
Which of these ways is better when it comes to:
- Ability to exchange data received by the Service (Or Intenservice) with other activities/services
- Battery usage
- Overall "good coding habits" ?
Thanks!
Original Question:
I am a pretty new Android Developer and have come across a situation that I do not know how to solve. I have already spent several days searching for a solution but could not find one.
While trying to develop my first app idea I have started playing around with receiving and parsing data from the internet. What I have achieved so far is generating a query that receives JSON data via an API and parses this JSON. All of which is done inside an AsyncTask. The received data is then shown on the screen.
However, for the purpose of my app idea, I need this to be done in the background. What I have thought of is:
Starting a Service that pretty much has the same logic as my Asynctask. Managed by an AlarmManager, this service then requests, receives and parses the data in a specific time interval.
Now the tricky part begins:
The data that I receive (let's say every 10 minutes) shall be used to change an alarm clock. So, as a simple example, let's say the user can set his alarm clock to 08:00 in the morning. The application then checks the current temperature every 10 minutes and changes the alarm clock time to 07:45 if the temperature is below 0° celcius because the user has to wake up earlier to clear the ice off his car.
Also, when "waking up" the application, the current (or rather the latest received) tempereture shall be shown in the UI.
What would be the best way to achieve this? I am having some issues regarding passing/receiving data from AsyncTasks/Services to/from Activities.
My first approach would be to start a single service from the MainActivity, passing some data to the Service (like the initial time the alarm shall start and the current location of the user). The Service then has two seperate AlarmManagers. One of which is set to perform the actual alarm (waking up the user in the morning) and the other manages the time interval of getting the data from the internet.
My questions:
- Does my train of thought make any sense at all so far?
- What is the best way to pass and receive data to/from a service? My best guess would be to use intents to pass and a broadcastreceiver to receive data from the service. would this make sense in this specific situation?
I fear that it is not welcomed to post questions without putting in any effort of your own before. Although I did not add any actual source code, I hope you can see that I have dealt with these questions for quite a while now but could not really start coding before I know the structure of the application.
Thanks in advance
Use AlarmManager to start an IntentService as often as necessary (in your example, it should be sufficient to start checking the temperature about two hours before the user plans to get up and maybe again after one hour and finally half an hour before the normal wakeup time. More often only in case of extreme weather conditions.
It's not necessary to check the temperature exactly at 03:33 a.m. so use
setInexactRepeating(), this will be easier on the battery.
See also Scheduling Repeating Alarms
Write the results to SharedPreferences and have one IntentService check 15 minutes before normal wakeup time if the user should get up right then. Cancel the normal wakeup alarm in this case. Communicating via SharedPreferences (think of a mailbox) and local (!) Broadcasts is a good idea - cheap and secure :)
The Android GenieWidget (also known as News & Weather Widget) updates very often (every few seconds). Now the time interval for updating a widget can currently not be shorter than half an hour. It is possible to create a service or use AlarmManager that updates it more often, but this is discouraged because of the drain of system resources.
I am considering making a similar application. My question is, how is it (probably) done in GenieWidget? Is it some clever trick, or does it just update more frequently (and is therefore battery drainer)? That would be weird since it is Google application and one expects some quality there.
I don't know where you're getting the information that the Widget checks data more often than 30 minutes. Just check the interval in the settings.
But if you have to do that - why not use another event except a scheduled interval like display turned on?
After some research I think most likely scenario is this:
Updates of news and weather data from the Internet (news.google.com and other sites) every hour
Frequent updates to the widget (every few seconds) by a service that is probably started on receiving the ACTION_SCREEN_ON intent (which however should not be used lightly as its excessive use by applications and services could significantly slow down the system when turnin screen on).
As far as I understood the official documentation about Widgets I am a little bit confused.
The "standard" way would be to define a BroadcastReceiver and define the update frequency in milliseconds - this way allows a minimum update interval of 30 minutes to save battery power. Sounds reasonable.
The "manual" way I found reading the Google documentation would be to handle the update of widgets yourself using the AlarmManager. Using this method higher update intervals are possible (though of course discouraged!) and it would be possible to use alarm types that do not wake up the device when asleep. (I assume the intent is sent any time after the event should trigger as soon as the device wakes up for some other reason - is that right??)
Now, I get confused by the following thought: widgets reside on home screens. Or at least that's the most common place they will be found. Android offers many pages (standard is 5 or 7) on home screens, so a Widget, even though placed there by the user, might not even be visible!
As long as the information a widget displays is just a very simple text (like the current time!) that could be calculated or derived without any delay whenever needed, I do not want any update frequency or even device wake-up intents when it is not visible!
But as long as the device is on, or more specific: as long as the screen is on AND the widget is visible, I want a lot of update events! Like a clock displaying the seconds needs an intent to redraw every second!
How can that be realized? How is the "Android analog clock" realized? Neither method A ("standard") nor B ("manual") give my high update frequency but only as long as the device is on and my widget is visible.
Can anybody give me a hint???
I assume the intent is sent any time after the event should trigger as soon as the device wakes up for some other reason - is that right??
Yes.
I do not want any update frequency or even device wake-up intents when it is not visible!
But your users do, in many cases. Anything you do that is worth doing in the update may take some number of seconds. The user is not going to sit there waiting some number of seconds. Hence, the app widget update model says that you keep the app widget updated constantly, so when the user goes looking at the app widget, they have the updated data right away.
But as long as the device is on, or more specific: as long as the screen is on AND the widget is visible, I want a lot of update events! Like a clock displaying the seconds needs an intent to redraw every second!
Write your own home screen app.
How is the "Android analog clock" realized?
It is a feature of the home screen app.