Develop Reference

android - Why should I implement interface while communicating between main activity and fragment

I do not understand something. Now, I am reading the documents in android developer site and there, it is written that in order to communicate with fragments, I should implement interface. However, now I can easily access the widgets, exist on fragment, in Main activitiy class.
For example, in main activity class, by issuing following line, I can access fragment´s TextView.
TextView t1 = (TextView) findViewById(R.id.t1);
In this condition, why do i need to implement interface? (forgive my ignorance and thanks)

On Fragment, how do you access a method of the Activity it is attached to? You could call getActivity() but that will only give access to the methods available to the parent Activity object, not your implementation of it with your own custom methods.
To access those custom methods, you need to tell Java that you know that the particular Activity you want to get is the one you created, lets call it MyActivity, which obviously extends Activity or some other implementation of it like ActionBarActivity. In this case you can call ((MyActivity)getActivity()).myMethod();
The problem now is that you are coupling your fragment to that particular activity. By doing so, you won't be able to use your fragment with any other activity in your project because that particular fragment will be looking for MyActivity.
So instead, you declare myMethod() in an interface and make your Activity implement it. If in the future you need to use the fragment with another Activity, all you have to do is make it implement the interface as well.

What is the difference creating event callback or the activity itself within a fragment?

Lets say I will be using several fragments(Action1Fragment, Action2Fragment etc.) within an activity(ActionActivity). I want to access some elements of activity object, or call some methods of ActionActivity. It is generally offered to create a event callback . What if I keep a reference to ActionActivity within Action1Fragment instead of keeping a reference to CallBackInterface which is actually implemented by ActionActivity since I will be using these fragments only within a particular activity.
I am kinda confused by the idea that Activity might be dead while reference of interface might still be alive(it sounds ridiculous when I read it again but it is OK if I managed to explain myself).

The Android Developer tutorials recommend that you use a callback interface on your fragments. The activity that hosts the fragment must implement the callback interface. The fragment does getActivity() and casts it to the callback interface, and then makes the callback.
This is the recommended way to promote a more modular design. It would not matter if your fragments will only ever work inside one activity. But if you want to make more generic fragments that could be used by different activities, then the above design pattern starts to become useful. (For example: a telephones fragment inside an person fragment and a company fragment.)
Suppose you do it the other way: the fragment does getActivity() and casts it to PersonActivity. The fragment then has access to all the public methods of PersonActivity. But this design pattern becomes much more ugly when you need the other activity to also use the fragment. The fragment would then have to be changed to first try and cast to PersonActivity, and if that throws, try the CompanyActivity.
The recommended design pattern basically gives you a way to make an activity compatible with the fragment instead of vice versa. The fragment only knows about the callback interface and not about any of the activities itself. The activities do know about the fragment because they implement the callback interface but they already knew about it because they constructed and initialized an instance of it.
Does that make sense?

Is it possible to have one GestureDetector for ALL activities?

Is there a better way to implement a GestureDetetor to all activities instead of having to define a GestureDetector individually?
In my scenario I have 10 activities for which I would like all of them to have the same behavior for Gestures. For example a swipe to the right will end the current activity and take the user back to the main activity.
My options seem to be
Define the GestureDetector in each of my 10 activities
or
Extend Activity and add a GestureDetector there and then extend from my custom activity.
Is there a better way to implement this behavior?

One easy way to do it is setting the GestureDetector in a base class that all activities extend from. This is a typical approach but it creates a new instance each time.
Another way to do it, depending on your target api, is using Application.registerActivityLifecycleCallbacks. You can find more information in the Application class documentation. This is api 14+.
Don't forget to read the docs:
public void registerActivityLifecycleCallbacks (Application.ActivityLifecycleCallbacks callback)
Add a new ComponentCallbacks to the base application of the Context,
which will be called at the same times as the ComponentCallbacks
methods of activities and other components are called. Note that you
must be sure to use unregisterComponentCallbacks(ComponentCallbacks)
when appropriate in the future; this will not be removed for you.
After you do that, just check ActivityLifecycleCallbacks for more information. You've got all the typical onCreate, start, resume, etc callbacks with the corresponding activity as an argument.

Android - Parent activity should determine what child activity had called it

I have 2 activities in my project, lets say Activity A, and Activity B. Both A and B extend the same superclass: BaseActivity.
We know that in this case, lets say if the Activity A is opened, then the superclass method onCreate() is called, and then the Activity A's onCreate() follows.
Being in the onCreate() method of the parent BaseActivity class, how can I determine which child activity has been started?

I would suggest a different approach. Basically don't do inheritance. Use composition instead. Remember most operations that you think you need to extend for really just need a reference to the context. Activities extend from context. So really you can provide most base functionality in any class that has reference to an active context. No need to do inheritance at all.
So if you want to share some functionality between ActivityA and ActivityB just put it in HelperC
HelperC.someOperation(Context c, otherParams)
HelperC can do anything that some base activity could do. Ultimately the base activity will never exist any way. It will always be an instantiated version A or B

I don't think you should do it this way.
As far as I remember the idea of extending, superclass method should contain only universal code. Puttin the differenting code in child classes would be much easier to do and as I believe more proper.
You can initilize some values in parent onCreate(), and then re-set it in childs'.

Android: Using methods from an Activity in a Widget. Extend Activity and AppWidgetProvider?

I'm working on an Android app which has an activity and a widget. This is currently implemented via two classes in two .java files - one for the activity (extending Activity), one for the widget (extending AppWidgetProvider). Nothing out of the ordinary here as far as I'm aware...
However, the widget class code could be a lot simpler if it was to make use of functions and asynctasks defined in the activity class. Duplicating these functions seems like bad design, so I'm wondering how I can structure the app to make them usable?
Can I extend both Activity and AppWidgetProvider somehow? Can I import one in the other?
Thanks!

either make the funcs static, or make a 3rd class to hold these funcs

Move the functions down into a service. Create a Service and you can use context.startService(Intent) from you WigetProvider or from the activity to access the functions.