I have a problem regarding viewing & following method calls in the android source code when Parcels get involved.
I wanted to find out more about the inner workings of PendingIntents by checking out the Android source code, but just when things get interesting, Parcels pop up a few ambiguous functions are called, and the important bit is over.
I belive specifically the following lines in the send() method of IIntentSender is important:
mRemote.transact(Stub.TRANSACTION_send, _data, _reply, 0);
This is where I get lost. How can I track down the method which is called next? Trying to view the source of transact method just reveals an interface with no code!
The type of mRemote is android.os.IBinder (an interface again)
Thanks for your help in advance!
(P.S: I used grepcode.com to inspect the source code)
The Binder is just the "guts" of an inter-process function call. Providers, Intents, and Messages are actually just abstractions of the Binder protocol. There is a lot of information out there about the Binder protocol, however it is designed so that most people don't have to worry about it.
When you call functions such as getActivity() you are acquiring an intent object that will be used later, but when that time comes, it uses the binder to do its job.
This is all to say, you've gone too far into the "guts," and need to take a step back. The Binder is literally used everywhere and is just a generic way to communicate. Whatever is on the other side of that .transact call is dependent upon the means in which the Binder (or in this case, the PendingIntent) was acquired.
Try to deduce what component would handle an intent of your particular variety, and look for a .transact method in its code. This will usually take the form of a huge switch statement that calls different functions based upon .transact's first argument. Whatever the case block calls will be what is "interesting" to you.
In your case TRANSACTION_send makes me think of finding some activity with the capability of "sending" something. Well, this sounds like a job for the ActivityManager. This code can be found here. Check out the onTransact method for some potential breakpoint positions.
Related
This is the question worth to be asked on the behalf of the new developers in Android.
Idea is to provide a deep understanding to why the framework is written as such.
Also, developers face dangling pointers, illegal states and such run-time crashes, and they do not have a clue that why it is happening.
Programmers now a days heavily use call back and factory patterns. Use of delegate class objects reduce the need for Singleton classes, and the need of multiple inheritance in languages like C, C++.
Developers thrill when they come to understand Handler based message passing between components.
Which one of these methods is more reliable to know that the context of the Fragment, should no longer be used by its components, or outside from the Activity that is parenting it:
onStop()
onDetach()
onDestroyView()
onDestroy()
Best Regards.
Kindly go through this link to understand the lifecycle of Fragments
It says that while your current fragment (you can track using getter and setter in Application extended class) is in dying phase, getView(), and getActivity() will return null. So you should not be using these methods and be cautious of the concerned life cycle callbacks (again can be tracked using boolean getters and setters in the abstract BaseFragment/BaseActivity sub-classes of the regular concrete Fragments and Activity classes).
source
I am tracking all of these methods, to stop using getView() of fragment. I logically feel onDestroy(), is the most suitable method for this purpose.
I am using the trackers in the same way in this answer:
https://stackoverflow.com/a/52017405/787399
This inheritance strategy greatly helps and improves the meaning of the Activity and Fragments life-cycles. I fact it is so power full that you can have those features that are not implicitly provided: Like you can handle system back press (managed in the BaseActivity in onBackPressed() method) whenever back is pressed on the Fragment, and you can block the back pressed event call, till some condition is met, or place an OK_Cancel confirmation alert, that whether you want to really exit the current fragment.
Happy coding :-)
is it expensive to always pass Activity as an argument to a method?
You see, I have this class (this is where I put the commonly used methods by my activities). And all my methods there have Activity as a parameter, because the results of those methods will need to be send back to the activity that invoked the method, so basically I need to know to whom should I throw back the results, so I always have like:
public static void processThis(Activity activity){
// some Code
}
I just like to know if this is against the best practices or if this is expensive to use?
Thanks. Looking forward for your explanations that will enlighten me.
Added:
I'm extracting commonly used methods from my activities to promote code reuse. Like, ActivityA use methodA and send broadcast back to ActivityA, same way goes for ActivityB which uses methodB(same as methodA) and send broadcast back to ActivityB. So what I want to achieve is to to extract that methodA and methodB which basically are the same, and put them into another class, and add a parameter Activity so I can know to whom do I need to send the broadcast back. Thanks.
In Java, all parameters that are not primitives are implicit pointers; consequently, passing an object such as activity only requires passing around the address at which the Activity is located in memory, so passing such a thing is not an expensive thing to do in Java.
So, the real question you should ask yourself is not whether it is expensive, but rather if it makes the most sense (from a logical / maintainability perspective). If it makes sense, then by all means do it.
Android newbee here, I have some code that I want to run when my android app first starts up. It checks the version of the local database and downloads a new version if the current version is out of date. I have been sticking it in the oncreate of my first activity, pretty sure there has to be a better place to put this. Any recommendations of somewhere I can put it where it will get called once on startup?
You can write a custom Application class (extend from android.app.Application). Override onCreate to specify what happens when the application is started:
public class MyApplication extends Application {
#Override
public void onCreate() {
super.onCreate();
// Do something here.
}
}
You'll then need to register your custom class in the manifest file:
<application ... android:name="fully.qualified.MyApplication">
Edit:
In response to David Cesarino, I disagree with the purpose of the Application class. If you rely on the Activity's onCreate, then what's to stop it from becoming the same huge class of miscellaneous purposes... if you need something to happen when the application starts, you have to write that code somewhere; and the Activity would probably become more cluttered because you have to perform Activity specific logic in it as well. If you're worried about clutter, then separate the logic into other classes and call them from the Application. Using the SharedPreferences to determine whether or not the logic should execute seems like more of a work-around to a problem that's already been solved.
Dianne Hackborn seems to be referring to data, not logic, in which I totally agree. Static variables are much better than Application level variables... better scoping and type safety make maintainability/readability much easier.
First, look at the Activity lifecycle.
Answering your question, you could put code in any of those "start-up" methods, depending on what you want to do and, mostly important, when you want to trigger that. For what you asked, onCreate is the reasonable place.
I have been sticking it in the oncreate of my first activity, pretty sure there has to be a better place to put this.
And why is that? Any code has an entry point, right? In Android Activities it just happens to be onCreate (again, see above link for the full details). Besides event handling, which are responses to events happening outside the main sequence of calls, you put stuff in onCreate.
If you're concerned about the method becoming huge, then that's another problem. Abstract your code better, I say. For checking preliminary stuff, people generally provide a "Loading" activity, before starting the main activity of the app.
edited:
This is a follow up to what drumboog proposed, since my comment started to grow in complexity to be "just a comment".
Personally, I'd avoid extending the Application class for the sole reason of executing code early on, more so a code that is not that sensible in priority (versioning databases). The Application class is mostly used as an easy way to persist state between Activity'ies, not as a way to "do everything". In short, I feel the Application class is commonly abused.
For what you want, you could perfectly achieve that calling code in Activity onCreate. That reduces complexity, because I've seen people stuffing Application until it becomes a huge class of miscellaneous code purposes. And that's a no-no for maintenance, with logic problems of its own.
Besides, if you truly want another solution, completely disassociated with the UI, you should think about implementing a Service instead (but I don't think it's necessary for just that).
Both of those concerns were previously addressed by Dianne Hackborn (or what I got from her message).
I'm trying to avoid having gigantic activity classes that are hard to follow, but the platform seems to be making it hard. Doing almost anything requires a activity or context - these can be stored away in a helper class, but unfortunately calls like startActivityForResult, for example, don't take a sperate listener but always call back on the same activity on an override with a supplied integer code - so this means that seperation of concerns is hard - the main activity needs to know about the helper class and dispactch to the helper class based on an request code - and of course, that request code needs to be unique, so that's a leaky abstraction as well. Why not specify a listener for every call thus avoiding the dispatching and need for unique request codes? Any other ways to slice this?
thanks
In API level 11 and higher, you can use Fragments.
Specifying a listener would be difficult since it would require passing an object to other processes in the Android environment- remember that activities can be called from one application to another.
How is using request codes making your activities "huge" in a way that listeners wouldn't? Activities should make use of classes defined elsewhere to do more most of the labor, let your activities pertain primarily to UI tasks.
I'm new to this and I'm sorry if this is a really dumb question. I'm just trying to clarify things. My book says I can retrieve application context for process by using the getApplicationContext() method. I just really don't know where to type this or what to do with any of it. I can go to the hierarchy but what do I do with all the script there. Also where would I write Activity Callbacks, in the main.xml? An exercise wants me to add a logging tag to my project but I'm not sure how to do this. The exact text says:
"Within the onCreate() callback method, add an informational logging message, using the Log.i() method."
and another exercise says to:
"Implement some of the Activity callback methods in addition to onCreate(), such as onStart(). Add a log message to each callback method and then run the application normally".
As these seem like basic questions, can someone please help me.
I am using the Android SDK, and Eclipse. I have made the Hello World application, but I have no idea what to do with Context or Retrieving resources. Please help!
The first rule I would give you: if you don't know why you need it, you probably don't need it. Use your activity object as the Context when you need a context.
The callbacks you talk about are on the Activity class. The Application Fundamentals describes what an Activity is: http://developer.android.com/guide/topics/fundamentals.html#Components
The only time you want to use getApplicationContext() is when you need a Context that exists outside of the lifecycle of an Activity class (or other component). You'll want to find documentation on specific cases where this is desired, there is a lot floating around. For example this one is part of the Android documentation: http://android-developers.blogspot.de/2009/01/avoiding-memory-leaks.html
For the tasks you're working with here, you'll be using the Java code that defines the behavior of the application, not the XML files that define resources and layouts or the AndroidManifest.xml file that declares basic application properties.
If you're working with Hour 3 of the Sam's Teach Yourself... book, then you need to open the src\com.androidbook.droid1\DroidActivity.java file. In general, you would need src\<package-name>\<class-name>.java. When you open that file, you'll see a class (in this case, DroidActivity) that extends Activity and already has the onCreate() callback method. Anything that you want to happen during onCreate() goes inside that method. Other callback methods can be added inside the activity class. To see an example that has all the lifecycle callbacks (but doesn't do anything in them), look here.
A logging tag is just a string. You can declare it, for example, as a private static final String inside the activity class.
If there's confusion about where methods belong, where and how to define variables or constants, how to call methods, how to use classes, and so forth, then it might be best to go through an introductory Java text before starting with Android. There are plenty of free resources available for that.