i've a question for a feature, i want to implement.
I know some applications, like whatsapp, gmail or others, which run in background and notify the user, if something is received...
i'd like to do the same with my application. i've a http-network-connection and want to notify the user, even if he hasn't the application started. is something like this possible?
Is it possible, that a PopUp-Window, like receiving a sms, appears?
(if not, the notify-way in a titlebar is enough)
i've no idea, what i should google or where i can find help
Thank you a lot!
Edit: I found another very cool framework which deals with notifications. Have a loot at: https://www.parse.com/tutorials/android-push-notifications
You should take a look into Services. You can have the http connection listening in it. For the notification I'd use the NotificationManager class. A notification is much more less intrusive than a pop-up.
Hope that helps
Google Cloud Messaging will definitely help you.
If your server can instantiate this 'action' or 'event', by all means don't try to pull data periodically, coz that brings extra complexity to your app and also battery drain to your users.
But if you really, truly, badly need this behavior, you can instantiate a Service from your app's process. This can be done from many places, like your main activity or some other user action, or even from a broadcast listener. For example, our app has some parallel work to do, so we pass this to a service and that service is initiated by a broadcast listener listening for phone events like a phone call or sms.
On the other hand, just like the main activity of your app, your background service can be killed arbitrarily by the operating system any time. So you shouldn't depend on it running forever. You should have ways to check if that is still working in the background. Check alarm events or any other relevant broadcast listeners.
Related
my app lets user create scheduled task.
Example: Tomorow show this notification => this notification leads to this activity etc.
What is the best practice to do this? Do I need to use some background task manager? How can I do this so it will work even when App is not running?
Facebook is doing something similar, when it is not running it still checks web for useful info for you.
Can somebody point me to some tutorial or get me some example? Thank you
There are several solutions that are recommended by Android framework team
Firebase JobDispatcher
GCM Network Manager, codelab
Job Scheduler api 21+
For showing a notification at a known point in the future (either a specific time or X hours from now) use AlarmManager to set an alarm.
For getting notifications from a server, generally you'd use push messages from the server. Although polling the server on an alarm would also work.
I'm building a fairly simple data tracking app. Using a runnable, every 5 seconds my app checks how much data the user has consumed and updates the UI.
The app works well, and the runnable keeps going even when the app is not in the foreground, but when the app is closed, it stops.
I've never used a service before, and after reading some documentation, I'm still unsure if that's what I need. I need to be able to update the UI, and depending on the data amount, start an asynctask to update a server.
Right now this part is happening from the runnable, but from what I've read about services, it seems like interacting with the UI is difficult.
I was originally hoping that I could somehow just prevent the app from ever being killed. It's going to be used on a private system, so there's no concern of the user 'getting annoyed' that the app can't be closed, but I can't figure out how to pull it off.
Thanks in advance for any information!
Note: I didn't post any code because I didn't think it was relevant here, but I'd be happy to upon request.
Is this the correct situation to use a service?
Yes.
from what I've read about services, it seems like interacting with the UI is difficult.
It's not that hard. The easiest solution would be to use an EventBus.
Another solution without a library: The Activity binds to the Service in onCreate. The Service returns a Binder. The Activity passes a Listener to that Binder. The Service calls the listener as soon as the UI needs to be updated.
I know it might seem a repeated question, but I want to call a method to report geolocation position every minute as long as the application is open. Other answers recommended using CountDownTimer class. Is there a better way in Android to repeatedly call a function in background?
No idea who suggested a count down timer, but in Android you can use Services namely the Background Service. See here
You could consider something like an AlarmManager - which will run periodically, i.e. every minute to execute an Intent
The risk you run, if something is continuously running, is it will be shut down by the OS.
Alternatively, if you're checking network connectivity etc then you can look into BroadCast receivers - and there's no need to run continuously in the background.
It depends on how you are getting the location. If you use play services you can take advantage of the LocationRequest class. For more information about how to use play services to get the location, please have a look at this training put together by Google.
Hope this helps.
I am developing an Android app that allows sports team coaches to update the attendance for events like training/matches. A feature I would like to add would be to display a notification on the device to remind them that they need to update the attendance for the event when it has started.
I have been reading online a bit and it seems that push is the preferred method for data that is changing. But because i know the start times of the events, would it be better to create a background service using something like the following?
https://stackoverflow.com/a/9933130/2039505
I basically want the user to receive a vibrate notification which when they click on it, it will open the events attendance screen. Hopefully someone will have some insight into which option is best!
Since all you need is a notification on a timer, the AlarmManager would be the best way to go.
If you used Push Notifications(GCM), that would require server side code and a method to store the device id to send the notification to.
Overkill if you ask me.
Here are links to the official documentation and example code:
Official documentation
Vogella's example on services
I'm writing a simple broadcast receiver. I've registered receivers in both the manifest and in the code before. For my purposes this is a simple receiver that doesn't need to do anything fancy.
Is there a reason to choose one method over the other in this case? Is registering the receiver in the manifest more efficient (executes faster)? Or are they both basically the same?
I'm asking because the application I'm writing needs to be very efficient, and I haven't been able to find good information on the practical difference between the two methods. I'm trying to follow whatever is the best coding practice.
Cheers
Well, they are actually different. You seem to think that it is almost same. When you register a receiver in code, you must unregister it when the app gets destroy (actually, when the Activity or Service that register it, gets destroy). On the other hand, when you declare it in the manifest, you make it available even if you app is not running.
Just ask your self: which of the two approaches best fits your needs?
I can't speak as to the efficiency of the implementation of one over the other (my intuition tells me that it's too close to really matter), but for reasons hinted at in Cristian's answer, registering and unregistering programmatically might make your app more efficient.
If you register in the manifest, your broadcast receiver will always be woken up by any intents that match your filters. If you register programmatically, you can only allow your receiver to be woken up at particular times, and you can control which intents will wake up your receiver and at which times.
If you're really worried about waking up the receiver at times that it doesn't need to be, then do it programmatically in the code. You'll need to be more careful to always unregister, and ensure that your receiver is registered at all times that you expect it to be, but if you do that correctly, you can avoid waking up your receiver unnecessarily, and thus saving some efficiency.
It depends on scenario.
When to use which method to register
Which method to use for registering your BroadcastReceiver depends on what your app does with the system event. I think there are basically two reasons why your app wants to know about system-wide events:
Your app offers some kind of service around these events
Your app wants to react graciously to state changes
Examples for the first category are apps that need to work as soon as the device is booted or that must start some kind of work whenever an app is installed. Battery Widget Pro or App2SD are good examples for these kinds of apps. For this type you must register the BroadcastReceiver in the Manifest file.
Examples for the second category are events that signal a change to circumstances your app might rely on. Say your app depends on an established Bluetooth connection. You have to react to a state change – but only when your app is active. In this case there is no need for a statically registered broadcast receiver. A dynamically registered one would be more reasonable.
There are also a few events that you are not even allowed to statically register for. An example for this is the Intent.ACTION_TIME_TICK event which is broadcast every minute. Which is a wise decision because a static receiver would unnecessarily drain the battery.
Simply put
Dynamic Registration - Your app expects something to happen immediately while the app is running
Static Registration - You app is waiting for something to happen over the long term. And since you cannot guarantee your app will be running when it happens you can politely ask the android system to notify you when it does
They both would have the same execution beyond that point