I try to get the foreground activity for a long time, and i didn't managed to get it until now.
I don't know if it even possible, but i am dont intersted in my app activity only.
There is no data transfer between my service and the activity which i want to get.
I saw lot of questions of this kind but i got nothing suitable for my needs.
I just need to get an instance, not a ComponentName, not decription of the current foreground activity.
I've tried through ActivityThread, ActivityManager, ActivityManagerService (even though i couldnt get his instance too), and so on.
Field activitiesField = activityThreadClass.getDeclaredField("mActivities");// won't help
activityManager.getRunningTasks(rnd);// won't help either
If there is any refelection way, listener or something like that, but not a static field.
Without knowing why you want an instance of the Activity, or other background info. I'd suggest the following.
If you're inside a Fragment, then you can do getActivity() - which will give a reference to the Activity, and you can then cast this as your own Activity.
Otherwise, you might want to consider having a BroadcastReceiver, which can start an Activity for you.
You shouldn't be accessing an Activity directly. If you have methods/logic you need to access, you might consider refactoring them into a helper class.
Edit:
"Your application runs in a secure sandbox environment, so other processes on the system cannot access your code or private data." Take from the official Android docs
Related
I have a case where inside an activity, I have a variable (say bindingManager) to store the binding information between the application to a service. I understand that when the 'Back' button on the phone is clicked, the activity will be destroyed and so are all its member variables. If I want make these binding info stored in bindingManager persistent after the activity is destroyed, may I know where shall I move this variable (bindingManager) to?
Thanks
Regards
Hammer
I think storing binding info. into the file, preferences, or DB would be annoying things.
It seems you have a service. So why don't let your service store information you want. And the service should be remote so it would live after an activity has dead.
I think you may need Messengers or AIDL to complete this work.
This is very short answer without specific codes. But you can make it work with this tiny hint.
I have a main Activity that's happily been working with a Service I created for a while now. Recently I've had to add a DialogFragment to my app and although its working nicely as well, I now need to make a call to my Service and pass along more than the usual Intent type strings. Basically I need to pass an array of Bitmaps to the Service, and I don't think it's reasonable to try and stuff them into an Intent.
So I was hoping, without luck so far, that I could bind to the service while the DialogFragement is open so I can make a direct method call to the Service.
Is there any way to do this? So I have to copy the entire ServiceConnection class and bind to it from onStart()? I figured there must be a less messy way to do this.
Thanks in advance.
As there is no code, I assume that your DialogFragment serves to capture some kind of input from the user (Yes/No or something similar), as most dialogs do. If this is the case, then you can simply return the input back to the calling Activity and make a call to the Service based on this input. Another question is where to the Bitmaps come from? Passing an array of Bitmaps from an Activity to a Service doesn't seem a good decision for me, you should probably consider moving the Bitmap retrieving logic to the Service itself, whether the Bitmaps come from the network or from resources.
Most part of my answer is based on assumptions about the design of your application, so if those assumptions go wrong you can post some code or add a broader description of your app and I'll be glad to review my answer.
I would like to get the class name (*.class) of an Activity which is bound to my local Service. Is there any native method which i could use to achieve this?
I tried to get that information out of the Intent I use to bind to the Service. But it seems there is no function in Intents for this.
If I wasn't blind, additionally I would like to know why there's no information about the calling Activity in an Intent?
Is there any native method which i could use to achieve this?
No, in large part because the class in question may not exist in your app, and may not even be a class.
You are welcome to package whatever identifying information you would like in the Intent, such as via an extra.
Also, if you are allowing third parties to bind to this service, you can use methods like getCallingUid() on your Binder to find out information regarding the process that bound to you.
additionally I would like to know why there's no information about the calling Activity in an Intent?
Because there is not necessarily a calling Activity. The binding engine works with C; C does not have classes, let alone activities.
Im trying to use the pattern of Activity-Service-Messenger to comunicate my Activity and Service. (like explained here http://viktorbresan.blogspot.mx/2012/09/intentservice-and-inter-process.html) Basically it says that i should create a Handler inside my Activity, and then create a Messenger and send that via putExtra() to my Service. The Service would then post messages to the activity ussing the Messenger.
My problem is that if i rotate the emulator, the Handler associated with the Messenger holds a reference to a destroyed activity. This causes not to refresh the interface of the new activity. I tried to put Messenger in onSaveInstanceState(). Eventought i can save the Messenger, the Handler is still referencing my past activity and i cant find a way to retrieve my Handler from the Messenger to set the new activity.
Edit:
Im avoiding to using:
android:configChanges="orientation|keyboardHidden"
onRetainNonConfigurationInstance()
Edit:
I used HalR idea of using a singleton and keep the handler there. It works really good, althought i can see that this pattern implies a careful cleaning of the references on the singleton.
Finally im also testing on the idea of using Activity-Service that was commented by Hoan Nguyen
I'm not sure that its appropriate for this case, but there are many people who have been frustrated by losing their activity when it rotates, or having to set complex stuff up every time they get a new activity.
Some people will create singletons that they use for referencing, then keep the Handler in there.
Others will extend the application class and put stuff in there. If you have a lot of complex things you are wanting to set up once, those are techniques you can use.
Keeping your app fluid and your making your activities independent of one another is a better overall philosophy, so its best to avoid anything global, but sometimes you gotta do what you gotta do.
Rotating the device at least pauses and resumes your activity according to the lifecycle. I think you are aware of the consequences.
Maybe stopping and starting a new service is the only right solution here. i worked as well with global states, but it will just always be easier when, you make every activity independent like a "single application".
edit: ok it's a messenger service... so stopping and starting is not a solution. so maybe you can register and unregister your messengers.
I have an application that is driven by a configuration XML: various
app properties are loaded at the app start-time by parsing the XML and
initializing static variables of some class. The data read from this
XML drives different Activities of the application. Presently, I have
called the "parsing and the properties-initialization" from the
onCreate() of my Main Activity.
I have a few questions as regards this case/approach:
Should I invoke the app initialization method from the Application
Object or is the current approach correct? What advantages/
disadvantages do/would we get/have if I choose to invoke it from the
Application object?
Do we really need a static class to store app properties? Or can we have all the properties as a static Collection variable in the application object?
Parsing a XML(~200 nodes) at app load time might take some time(not
sure how long tho); How can I avoid the dreaded ANRs? I am using a
Pull Parser.
Please help me find answers to these questions.
Thank you.
It depends on what you're initializing. Application's onCreate() should be used when you're doing things that need to be done before any part of your app works correctly and only needs to be done once, whereas Activity/Service/etc's onCreate() should be used for things that are needed for that component alone and needs to be done multiple times.
The main concern I have for putting all your initialization into a component is that it will make extending your application more difficult later on. Suppose you want to make some Activity in your application accessible by outside intents - now you've got to either move the initialization code to Application or you have to duplicate initialization code in the non-launcher Activity.
It sounds like you should check out SharedPreferences, especially PreferenceManager.getDefaultSharedPreferences(). The preferences will be stored between sessions and it gives you easy access to simple properties from any Context.
Threading. I find AsyncTask to be the easiest way to accomplish this task; there's a good write-up on it at Google. Alternatively, you could fire up a Service to do this in the background while having a foreground Activity inform the user that you're booting up the app.
The Application object is used for sharing non-persistent state across the application. I don't think you'll need to use an Application class at all. You can do your initialisation in the onCreate() method of the Activity that is called first. To quote the documentation:
The subclass is optional; most applications won't need one. In the absence of a subclass, Android uses an instance of the base Application class.
You don't need to create your own class to store application properties. This is done for you by SharedPreferences.
You should also have a look at the setDefaultValues() method in the PreferenceManager
class as this will set preferences from the data in an XML file. What's nice about this method is that use the readAgain parameter so that the XML is only parsed once - the first time you start up your application - rather than every time.