I am currently building an android application that will be used as an anti theft sort of application. Basically, once the alarm has bee launched, the application will monitor the accelerometer to detect movement. If it does, the user will have 15 seconds to enter a set password to deactivate the alarm, otherwise : BIIIIIP!
My problem is the following: how do I manage to keep the monitoring and counter process running after the activity is destroyed (if for example the user presses back) in a way that I can access it again from a notification.
I was thinking of using a thread to run the monitoring and counting process and when the notification was pressed, for example, the class could, in it's onCreate method, be aware whether an already existing thread is running and if so, get the handle to it?
Thanks.
What you are looking for is a Service. They are meant for this exact purpose; to run on the background (this does not mean a background Thread ) even if there are no Activities running.
You should consider using services for this purpose. Here is one of the example: http://blog.kozaxinan.com/2012/08/using-accelerometer-when-screen-off_16.html
Related
I need to create an android service that:
Starts whenever the screen is on (whether it is at boot time or not)
sends a notification every 20 minutes (if the screen is on)
stops whenever the screen is off
Every tutorial I've read uses an activity, but I need this to be a service because the app is not supossed to be running other than when the user wants to change a setting. The documentation says I need an IntentService, but I cannot stop that manually and I cannot use a Service because it is a long running operation. I tried with an alarm manager but it didn't worked, I don't even bother to show you the code because I really don't understand it. I do not know how to make the service check if the screen is on or not, if I use a BroadcastReceiver it won't be inmediately processed so I am just stuck
To implement your requirement. You need 3 things such as Service, BroadcastReceiver & AlarmManager :
AlarmManager [which will fire after every 20 minutes]
Service [which will make changes like showing notification as system gets notifies after every 20 minutes for your particular msg]
BroadcastReceiver [which will check for screen on/off right from booting to shutting down]
Refer these links :
http://thinkandroid.wordpress.com/2010/01/24/handling-screen-off-and-screen-on-intents/
http://androidexample.com/Screen_Wake_Sleep_Event_Listner_Service_-_Android_Example/index.php?view=article_discription&aid=91&aaid=115
I want this app to function like this
1.it will send the user location along with a message at interval of 2 mins to preselected contacts.
2.Location should be as presice as possible.
3.it should run in backround.
4.it stops only when the user stops it.
I tried many ways but it would work in foreground I want this to waork even when the app is closed if the user has to stop it he would have to open the app and deactivate it.
The IntentService class provides a straightforward structure for running an operation on a single background thread
See https://developer.android.com/training/run-background-service/create-service.html
Is there some sort of onTerminate() method where I can do some cleanup (I want to clear some SharedPreferences) when my Android app is terminating?
I have an Activity that is keeping a running average of a few numbers, that I'm storing in a SharedPreference. I want this average to last while the app is running (the user can move between different activities) so I can't clear it on onDestroy() for that particular activity. I need to be able to clear it once the app is about to quit.
How can I do this?
I've not tried this, but here's what I would do:
As Alex mentioned in the comment to original question, use a Service to share the app-wide state between Activities.
Whenever you move between Activities, bind to the service from the "new" activity, and unbind from the "old" one. Check this to understand how to coordinate activities.
If you follow this properly, you can ensure that at least one Activity is always bound to the Service as long as your app is running; and that all Activities are unbound when the app is no longer running - at which point your service's onDestroy() is called. This is where you perform your cleanup.
So android doesn't really have a concept of an app being "finished". Unfortunently there is nothing synonymous to "onTerminate()". Is there some criteria by which you can decide when to clear your running average?
Use SharedPreference.Editor to remove the preferences, and commit. Here's a link for you: http://developer.android.com/reference/android/content/SharedPreferences.Editor.html
I'm developing an android app (if you want more info http://www.txty.mobi) and I am having some problems with dialogs management. I'm quite new to Android so the way I'm doing things completely wrong. If the case please just say so pointing me to the right documentation to follow.
Background:
The main blocks of the app so far are one activity and one Service (which derives from IntentService).
The actvity needs to interact with the service in just two occasions: start/stop the service. The intent service will self regulate its lifetime using the AlarmManager.
A typical flow when clicking on start/stop:
1) the activity on its onResume registers a broadcast receiver to events sent by the service (unregisters it in the onPause)
2) the activity starts a indeterminate progress dialog
3) the activty sends a single shot alarm event (either start or stop) which will be send **straight away to the service
4) the service does what it needs to do to start
5) the service emits a broadcast event basically saying "done"
6) the activity receive this event and gets rid of the dialog.
The Problem:
The activity can lose its foreground status let's say if the user switches focus or a call is received, so the onPause method is called (at this point the activity could even be killed by the system to claim memory). obviously if this is the case the activity will never receive its broadcast event because the receiver has been unregistered. This will leave the app in the awkward situation, when the activity is brought again to the front, of having a dialog that you can't kill nor will never get rid of.
The (possible??) solution:
The way I am handling this now (apart for keeping the broadcast receiver in place) is by creating a utility class that uses preferences to keep track of which operations are being executed and their status:
Activity
- in the onResume using my utility class gets the list of operations the activity is waiting for
- check their status
- if they are completed perform some actions accordingly (in my case get rid of dialog!)
- delete the operation from the preferences.
- just before asking for a operation to the service it saves it to the preference using my utility class.
Service
perform operation and save state of the operation to the preference using my utility class.
emit broadcast.
Disasters happen!
Now this saves me in a normal situation, but if a disaster happens (i.e. with the task killer app you kill everything) the service might be killed before it can save the status of the operation I am stuck as before (the activity will think the operation is still going on so it won't touch the dialog). So as for now I add a Dismiss button to very dialog just in case :)
Now all of this looks too complicated for what I think should be a fairly common thing to do. That's why, as said at the beginning of the post, I might (very likely!) be completely wrong.
Any ideas? Apologies if this question has been asked already, I looked around but didn't find anything. Please point me to any resource online explaining this.
Thanks and sorry for the lenghty post :P
Luca
Have you tried using a StickyBroadcast? This caches the latest broadcast, so it can be received onResume. Please see this post.
what actions should be taken in the pauseApp method of a Java ME midlet. what is the purpose of having this method.
This is a pretty good description. Say you are writing a Tetris game, you would stop the brick from falling when paused. On a phone, interruptions happen and resources are limited, so you need to write your code to accommodate them.
Midlet javadoc tells us that this method is called when the application is set in paused mode. Paused mode corresponds to the event of the user pausing the application, or the application being paused by something more urgent, like a phone call.
its purely depends on your task and requirement.
Each and every application will have its own steps while resuming the application
For Example if we are using videoplayer and as soon it gets interupted via phone call or bluetooth we must save mediaTime and write some functionality stuff in pauseApp
Once app tries to resume we must startApp with that particular MediaTime where it has stopped
Same is scenario for gaming thing , need to store some info in pauseApp and use them once again in StartAPP.