Probably it's not a really complicated question, but first of all, I have no idea, what search query should I search for?!
At the beginning of my application I would like to start GPS and if my application will be enden GPS should be closed.
How can I check, if the whole Application (not an Activity) is finished?
Is it enough to use onDestroy-Method for Start-Activity, which will never closed with finish()?
Thank you very much and sorry for a beginner's question.
Mur
UPD
I saw the first answer and I'd like to say once.
I don't mean an ACTIVITY, I mean really the whole APPLICATION (in which many activities exist).
How to check if all application's activities were finished and only in that case stop the service?
Is there posibility for that?
UPD2:
I've tested my solution on a device:
"Is it enough to use onDestroy-Method for Start-Activity, which will never closed with finish()?"
Yes, it was enough.
Make it so that, each Activity binds (via bindService) with the Service...When all the activities have been terminated (unbinds implicitly), your Service will perish. Since the Service will remain alive as long as someone is binding with it.
In this particular case what you need to do is:
Create an Activity to show information to the user.
Create a Service that will run on background and will send the updates to the Activity
There are lot's of examples of what you are trying to do, but basically you can start the Service on the onStart() method of your Activity and ending the service on the onDestroy().
Related
I know that, unlike onCreate(), Application class does not have a onDestroy() method. But I wanted to know when my application is closed (or it is not visible on screen anymore). After all, whatsapp and many more similar chat applications can detect when user has left the app, and can record user's last online time. I want to achieve a similar thing. Also, when the application is destroyed, I want to detach all listeners attached to firebase databse.
I have already seen this question, but the accepted answer there is unreliable. So, what is the workaround for onDestroy() for me.
if you are talking about Application class (detecting when it is destroyed) - this is impossible, when Application gets killed developer shouldn't (and don't) have option for executing own code (as it may e.g. restart app from scratch)
but you are talking about app visibility, probably any Activity present on screen - extend Application class (and register it in manifest) and use ActivityLifecycleCallbacks with additional counting code: counter++ when any onActivityStarted and counter-- when onActivityStopped. also in onActivityStopped check if your counter==0, if yes then all your Activities are in background, so app isn't visible on screen (still it doesn't mean that its destroyed/killed)
edit: check out THIS example. or inspect supporting class ProcessLifecycleOwner (which probably is counting visible Activities for you and only calls onAppBackgrounded when all are gone)
You do not need onDestroy callback for it . You should be Doing it in onStop() of ProcessLifecycleOwner . Upon Application destroy your process will be destroys anyways in idle situation so no need to remove listeners there .
Remove the listeners in onStop and attach again in onStart . You can configure Application class with ProcessLifecycleOwner in a way so that Every Activity gets These callbacks. This is how it should works i guess if app is in background u will pop a notification of new message . Checkout ProcessLifecycleOwner.
I've seen similar questions asked where they wanted to know if they could find if a specific activity was running from a service. This is not what I want to do. I want to be able to tell if the user is currently using any activity on my app.
My use case is that I have a monitoring Service that monitors many session-related things, such as a Socket connection. If the Socket connection fails at any point, the monitoring Service is made aware and will have to let the user know. However, I only want to let the user know if he is using my app. If he pressed on the home button to check something elsewhere, I don't want to let him know. If he is using my app, I show him a dialog.
My issue is that I need to be able to check if there is any Activity currently resumed. If so, then I show a dialog to my user.
I've seen many solutions that are in my opinion pretty bad. I don't want to hold a boolean that is constantly updated by activities to know if an activity is running. I want to be able to cleanly tell if there is a resumed activity and show a dialog if that's the case. Remember that I am in a Service, so I don't have a context.
You can use ProcessLifecycleOwner in the AndroidX Lifecycle library and check if the current lifecycle state is at least STARTED (visible to the user) or RESUMED (frontmost), depending on your preference. Its lifecycle is the composite of all Activity lifecycles in your app, so this will check if any Activity is in that state.
Also:
Remember that I am in a Service so I don't have a context.
Service extends Context, so you can use use the Service as a Context like you would with an Activity.
I got a situation where i have two APPS for simplicity keep it as APP1 and APP2, i am passing an object remoteCallback as CALLBACK from APP1 to APP2 for future use.
where based on result APP2 will instantiate a method updateStatus(String msg) using a object remoteCallback, Everything is working fine but, when i close the APP1 and clears the memory, APP2 is unable to call the method i know what causes this problem i want to know is there any way to make the object(remoteCallback) live even the APP1 closed.
Thanks in advance.
I'd use an unbound Service here. Unbound services make that even if one of your apps close, if the conditions permit it, it will still be running in the background. If you used a bound Service, it would stop with your app if your app stopped.
This differs from an AsyncTask or a Thread, because even if they run in the background, there's a big change of being killed if Android needs more memory or is in lack of resources.
This introduce, however, a new responsibility for you: You'll have to make sure you use startService() or stopService() accordingly within your app and don't leave your Service running indefinitely.
This seems to be a good example about how it works, but you might find lots of documentation about unbound Services
There is no way we cant stop an app from destroy so instead of passing an callback to get details use BROADCAST RECEIVER.
This is the solution i adapted to this situation.
"I want to know is there any way to make the object(remoteCallback) live even the APP1 closed."
PendingIntent ?...
Its the same mechanism used on notifications.
You can start the background service and the store the object which you want to live object after the app is closing
you can declare the public static data member and you use the whole application
In android how to make sure that the service that I have in the application will get called only through an activity that is within the app.
(In other words I want to limit the service to get played by only a certain activity & not even by other activities within that app)
I tried studying Intent-filters but got a bit confused.
Can someone please suggest, if possible with an example?
Thank You
Use Context.startService(Intent service) to start the service from your activity.
Despite the name it doesnt only start the service. If the service is running already, it just calls it.
From the service perspective, the service will then call its onStartCommand(...) method.
Only an activity within the same application can call/start a service this way.
If you set exported="false" in your <service .. /> element of AndroidManifest.xml, the service cannot be called by activities outside your own app.
I know of no way to limit access to any particular activity within the app, but this seems a less pressing concern. Supposedly you can trust your own code?
I am writing a social game but am stuck with how to create a timer thread that works accross activities showing time lapse for an attribute such as energy. Every activity has the energy textview but the thread can update only one view at a time. Please note that im not using androids timer class but have created my own thread class.
You probably don't want to try to keep a thread running between activities. Managing it when the activity suspends will give you nothing but headaches. It's much easier to just store your time in the Application while you move from activity to activity. The Application is alive for the duration, no matter which Activity is actually loaded. The fact that you have an identically named TextView in various activities is neither here nor there... it's not the "same" TextView... it just looks (and smells) similar. So, you can just grab the clock when the app first launches and at any given time look at the difference between the current time and that time.
Then just use a Timer to update the string in whatever Activity you're in.
If you're unfamiliar with Application it's going to be a real Eureka thing for you to discover (Android tutorials overlook it ALL the time, for some reason, leaving you to do all sorts of really ugly Intent passing alternatives).
If you have any questions on how to use it, just follow up in a comment, and I'll add details.
I think you must think about using a Service :
Thus a Service itself is actually very simple, providing two main
features:
A facility for the application to tell the system about something it wants to be doing in the background (even when the user is not
directly interacting with the application). This corresponds to calls
to Context.startService(), which ask the system to schedule work for
the service, to be run until the service or someone else explicitly
stop it.
A facility for an application to expose some of its functionality to other applications. This corresponds to calls to
Context.bindService(), which allows a long-standing connection to be
made to the service in order to interact with it. When a Service
component is actually created, for either of these reasons, all that
the system actually does is instantiate the component and call its
onCreate() and any other appropriate callbacks on the main thread. It
is up to the Service to implement these with the appropriate behavior,
such as creating a secondary thread in which it does its work.