in my app, there are 5 classes and 1 activity. This activity has, as you all know, an OnDestroy() method. In this method I need to remove a test provider which is set up in another class called "mockingclass".
In "mockingclass" I have a method similar to this:
public void mocker()
{
xxx
location.RemoveTestProvider(location.GpsProvider);
xxx
}
While xxx stands for many other functions in this method, when the app is being destroyed I need to call ONLY for that ONE function in within this whole method.
Is there any way to do that at all? If not, what would be your suggestions?
THANKS!
Obviously you can't choose a single line from method to be executed. You need to extract it separate method which will be called separately. Maybe you should look at some injection? Let this call be injected as an delegate for example. In that way you could manipulate what should be called depending on situation.
Related
In the past I used "startActivityForResult" and "onActivityResult". Those methods are now deprecated. Therefore I want to use the modern alternative "registerForActivityResult".
Unfortunately, however, I cannot figure out a way to achieve the old functionality with this new model. I used to override "startActivityForResult" and "onActivityResult" of "AppCompatActivity" to run specific code before any activity was started and whenever any activity finished with a result. This was very convenient, since I didn't have to write the code for every activity launch.
As I see it now, I register the activity for a result and pass a callback to get a launcher that I can use to launch the activity later. This part I could solve by creating a function to use the launcher that always executes certain code. But there's a problem with the callback. As I see it, I would have to write this specific code into the callback of every callback I write for any activity launch.
Am I correct or am I missing something?
Theres a couple ways to do this:
1)Put the common code in its own function and just call that function in every callback. Reduces the code needed to be written to 1 line
2)Write a callback class GenericCallback. Then write your specific callback MySpecificCallback extends GenericCallback. Put the common code in the GenericCallback class and you just have to call super in the specific callback. Reduces the code to just calling super.callbackFunction, but means you can't use a lambda- you have to use a named or anonymous class. This is probably more of a Java approach though
3)Create a wrapper function for registerForActivityResult that takes a callback, and calls the real registerForActivityResult who's callback calls the common code and your callback Example:
fun registerWrapper(callback: ()->Unit) {
registerForActivityResult(() ->{
doCommonCode()
callback()
}
}
I am trying to use this solution inside my Fragment, however I couldn't be sure where to call System.LoadLibrary(), finally I decided to call from onCreate method of the Fragment, I want to be sure if this would not raise some another weird error on different devices.
General it won't cause weird behaviours, as onCreate is mandatory callback when your fragment created by system. This make sure your native library is prepared before you do further operation in your fragment.
Take a look at fragment life cycle, it might be better if you put your library initialize routine on the first callback onAttach, you can use the attached Activity context to initialize your native library.
It is just a static initialization. You don't even have to have it inside your onCreate() at all. You can simply initialize it as the first part of your class next to your global variables as such:
class YourClass
{
static
{
System.loadLibrary( yourLib );
}
...
}
It is only important that it is done early or you may see UnsatisfiedLinkError followed by application's crash. That way whenever a call referenced later is made, the library itself has already been loaded. A static declaration at the top will do that as soon as an instance of the class has been requested; even before onCreate().
I know onCreate , onListItemClick and onPageSelected etc. are callback methods in android.
Yet some are not so obvious to tell they are callback methods,
for example, getItem method in class FragmentStatePagerAdapter.
(Isn't it? Or getItem is not a callback method?)
How can we know a method is a callback method in android?
Is there any clue to let people know they are callback methods?
Or is there a list of all callback methods in android?
The documentation for each class at the Android developers site will list all of the methods available to you as a developer.
Take the Activity class for example. We can generally sort the methods into two large buckets:
Methods that are final such as getApplication()
Methods that are not final, such as onCreate()
Methods that fall into the first bucket you can immediately rule out from what you refer to as "callback" methods. Since they are final, you cannot override their behavior.
Methods that fall into the second bucket might be a "callback." I wouldn't get hung up on trying to label them as such though. Each and every method in the Activity class may or may not get called by some other piece of code at some point in time. However, most of those methods exist because they will get called at some point in time.
Even some of the methods that you might not think of as a "callback" method can be overridden and can be called by the framework (or your own code). For example, you can override the finish() method of an Activity. Most applications will only ever call finsh() directly without customizing the behavior, but you do have that option.
Focus on what you need to do, find the appropriate method to either call or override, then read the documentation on that method. Whether or not the method is a "callback" is usually irrelevant.
I have a small problem in my own android app. I have one class that extends AsyncTask, where in onPostExecute I want to call some method of the Activity from within this task was called. But the problem is that I want three different instances (and maybe some day more) of this task, each of them I want to call different method on my Activity (but all of these methods have the same list of arguments, for now). Is there any elegant way to solve it? Or I just have to create three different classes that differ in one line - name of the calling method in onPostExecute?
I heard that in Java we cannot pass function handle as a paremeter, so it seems really hard. Can anyone help?
I think you should create interface (which contain method with needed arguments), create in Activity three inner classes implementing this interface and pass instance of appropriate class to AsyncTask via contructor.
should I call super.xxxx() before my custom code or after when I override a method?
Is there some skills to Identify?
The short answer: It Depends.
The long answer:
You need to understand what the implementation of the method in the parent class does.
There are cases when the super method does some "initialization" work required for the overridden method to function smoothly. In such cases, the super.myMethod() call should be the first line in the method.
In some other cases, the implementation of the method in the parent class could be responsible for some clean up (or some sort of finalization) operations. Thats when you would need to make the call to super the last line in your overridden implementation.
Then there are situations where the order doesn't matter, but you must call the super method because the implementation in the base class performs some operation which are necessary; although the order of these operations doesn't matter. Most of the Activity life cycle methods fall in this category. Which is why you must call though to super.onCreate() although you can do it at any point in your onCreate().
Finally, there are also cases where the call to the super method is not required. The base class has a default implementation which you may choose to use or ignore. You might also end up doing an if-else here: For instance, you might call through to the super implementation. If it returns a null, you might create a new object and return that instead.
Is there some skills to Identify?
Read the method documentation and see if there is any mention of the order in which the super method must be called.
Go through the source code of the base class and see if you can figure out whether it does anything that necessitated calling it in a particular order.
(Very OOPy) generally, the idea is to call super just when you need a parent's functionality. I know it seems pretty obvious, but it has implications when it comes to cleanup functionality:
Init:
super.init
... your initialization code
Delete:
... your deletion code here <-- important
super.delete
SomeOtherRandomMethod:
... your code may go here if it does not need any state from the parent
super.SomeOtherRandomMethod
... otherwise it can go here
I find it's just simpler / cleaner to just call super's code at the beginning of an override (unless there's some really specific reason not to), and just make sure that I call the parent's destroy/delete/free/destruction after I've done my own cleanup (we definitely don't want the parent dumping the object out from under us!)