The webpage with the following address states that the class FragmentActivity extends the class Activity:
https://developer.android.com/reference/android/support/v4/app/FragmentActivity.html
However, when I bring up the documentation for the android.support.v4.app.FragmentActivity class within Android Studio, it states that FragmentActivity extends android.support.v4.app.BaseFragementActivityHoneycomb.
What is the reason for the discrepancy and which is correct?
This goes up to BaseFragmentActivityDonut. These base fragments are just an implementation detail of FragmentActivity and should not concern you at all. In the library I use, FragmentActivity directly extends BaseFragmentActivityJB. In the future there might be something like BaseFragmentActivityM or some compatibility layer for even newer platforms.
For your programming just assume it extends Activity only, like the documentation states.
Related
My SettingsActivity currently extends the Android Studio generated class, AppCompatPreferenceActivity which extends PreferenceActivity. Each of the preference screens in the activity are displayed using a PreferenceFragment; which, as of API level 28, is deprecated. The documentation states you should use the PreferenceFragmentCompat class from the support library as an alternative.
The issue is that PreferenceFragmentCompat extends android.support.v4.app.Fragment (instead of android.app.Fragment) which the PreferenceActivity does not support. And there is no PreferenceActivityCompat to fill the role of the of the now inconsequential PreferenceActivity.
Further confusing the issue; the new androidx.preference support library includes its own PreferenceFragment (which extends android.app.Fragment) and PreferenceFragmentCompat (which extends the new androidx.fragment.app.Fragment).
I could always recreate the functionality of the PreferenceActivity with my own classes, but why would the documentation recommend using the PreferenceFragmentCompat without a viable alternative to the PreferenceActivity? Am I missing something, or is the current state of the preference libraries not functional?
The SettingsActivity works as-is for now, but I usually like to try to get ahead of the curve, especially when something becomes deprecated.
Don't use a PreferenceActivity; a regular AppCompatActivity will serve the purpose just fine. If you want, there is a direct method of making a Settings Activity in your app provided by Android Studio:
I would like to use RoboActivity with my activity, but I don't know how to do that coz my current activity extends already ActionBarActivity:
public class MainActivity extends ActionBarActivity
Thank you so much
For RoboGuice 3 simply extend from RoboActionBarActivity.
You can simply copy the relevant RoboActivity parts into your subclass of ActionBarActivity. From the official docs https://github.com/roboguice/roboguice/wiki/Using-your-own-BaseActivity-with-RoboGuice:
In case your base activity class already extends a different library, the best way to get all the power of RoboGuice is to copy all the code contained in RoboActivity.
An example is also provided therein.
I have to do capture Applaunch and App minimize events for myapp for Appirater integration. I have to show Appirater dialog for every 3rd app launch/app minimize
I followed the article
http://vardhan-justlikethat.blogspot.in/2013/05/android-solution-to-detect-when-android.html
But i have a problem, i have many activities,fragments in Application.say some Activities extends FragmentActivity, some of the them are fragments and some of them extends Activity
But, as per the article, i have to extend all the activities using Base Activity
It implies the architecture changes for my application.
If i write the code separate for each activities, the Appirater wonk work proper. Any alternatives to this ? please help in fixing
Tried also by extending Application class but it can capture app minimze events
Create a BaseActivity And a BaseFragmentActivity that does the same as the BaseActivity in the example, and then extend them in the appropriate places, should still work the same and you don't have to do much work. Correct me if I'm wrong, I just skimmed through it
Edit, example:
public class BaseActivity extends Activity{
//everything
}
and the other
public class BaseFragmentActivity extends FragmentActivity{
//everything
}
I am developing an framework which is used overall the application, Which extends an activity, But in some scenario am using maps in my project, So i need to extend MapActivity,I can't Activity for example,
Framework Level,
Activity extends CommonActivity extends MainActivity
Here is my problem,
If i extends MapActivity instead of Activity it causes any problem or it has any drawbacks?
Thanks,
Nikhilreddy.
I don't think so there are any drawbacks of map activity because map activity extends Activity Class.
public abstract class MapActivity extends android.app.Activity
But You have to Run your application on a device or emulator that has Google Maps installed.
Here is the deal : I need to extends two different classes in Android.
An example:
In MainActivity.class I need to extends first TabActivity to use the tabs and getTabHost(); and in the same class I need to extends for example ListActivity or something else...How can I do that? Maybe my question is a little stupid but...
Thanks anyway!
You can extends either TabActivity or ListActivity in your main Activity.You can't extends two all together because java does not support multiple inheritence.After extending any one create the reference of another to use in your activity.
Your MainActivity doesn't need to extend TabActivity and ListActivity at the same time.
Only MainActivity needs to extend TabActivity and you can use a different Activity which extends ListActivity as the content of one or more of the tabs.
Here is the really good official documentation which has an example of what I'm talking about : http://developer.android.com/resources/tutorials/views/hello-tabwidget.html