Say someone wants an Activity which both has an action bar and a preference, the first idea in mind is probably
public class MyActivity extends ActionBarActivity, PreferenceActivity
But Java doesn't allow this. I know API 11+ Activities has actionbar builtin. It's just an example of wondering how to use multiple features from multiple base classes.
EDIT: Based on the feedback it seems we have to hack in this case. IMHO it could be as simple as putting all activity utilities as fields in class Activity and implement getter/setter to use those utilities. Well, in reality, it isn't.
No you cannot extend from two classes in Java. Typically in Android to add the ActionBar to the older PreferenceActivity there are a couple of hacks you can do or libraries that also do the same thing. However, recently with the new AppCompat library they introduced the Toolbar widget which can be used to add an Actionbar to your PreferenceActivity in this case. For more information, checkout this post I recently wrote on how to add a Toolbar to your legacy SettingsActivity.
simple solution:
Firstly you can't extend multiple classes..java does not support multiple inheritance see here
Secondly using action bar sherlock library here, this gives you action bar functionality without extending the actionbaractivity plus its backwards compatiable.
Or...you can implement a custom action bar go here
As mentioned in the other answers, Java doesn't allow multiple inheritance.
If you want an ActionBar as well as something such as Preference functionality, consider using a PreferenceFragment
It's not quite the same as multiple inheritance but Fragments allow adding extra functionality to Activities.
You can create a subclass of the PreferenceActivity, called AppCompatPreferenceActivity (or whatever you would like), to use an AppCompatDelegate to provide the SupportActionBar functionality. You can then subclass the new AppCompatPreferenceActivity for your MyActivity class like so:
public class MyActivity extends AppCompatPreferenceActivity
For how to do this, check out the AppCompatPreferenceActivity sample code from the Chromium project.
Related
I'm developing an app that has the same action bar for all Activities. The only thing that changes is the menu, which can be easily built dinamically.
At the moment, I have a xml file for each toolbar of each Activity, but there are plenty of code repetition thoughtout the code. How should I deal with it?
I've thought of making a single xml file and including it in the Activities layout. However, there are plenty of stuff that are made programatically, such as definition of the button, title and menu. These methods are located in the Activities onCreate. How is it done to reutilize this code?
Im not sure If I understand you correctly, but maybe make class which extends after Activity (or if you use AppCompatActivity etc.) for example class MyCustomActivity extends AppCompatActivity implement there your actionbar, and then in every new Activity class where you need that ActionBar just extend MyCustomActivity. In this class you can ofcourse implement some public method to set menu in subclasses etc.
There are two principal ways of creating an app bar for an activity in API 21+ using the Toolbar.
Create an activity which extends AppCompatActivity and then follow the instructions here
Create a standalone Toolbarwhich acts as an app bar (define the Toolbar in xml using android.support.v7.widget.Toolbar) and then inflate a menu into it like this: ` toolbar.inflateMenu(R.menu.homeview_menu_common);
My question is: what are the benefits and drawbacks of doing one over the other?`
A related question to this topic can also be found here (How can an activity use a Toolbar without extending AppCompatActivity)
Short answer: No you should make your activity extend AppCompatActivty
You can create a toolbar without AppCompatActivty but besides an app bar the AppCompat also brings with it the support libraries that allow you to add material design to your app going as far back as API level 7 of Android.
Unless there is a specific reason for not using AppCompat all your Activites should extend AppCompatActivty to model a Material app.
You need to use an AppCompatActivity extended Activity because, when you set up the Toolbar as the ActionBar with setSupportActionBar(Toolbar) you get the ability to reference it through Context.getSupportActionBar() from nearly anywhere in your code i.e Fragment. But, if you don't extend AppCompatActivity you can't easily get a reference to the Toolbar from anywhere else other than the Activity in which it was defined.
android.support.v7.app.AppCompatActivity was added into the latest v7 support library as a new feature yesterday.
It is said that ActionBarActivity has been deprecated in favor of the new AppCompatActivity and that AppCompatActivity is base class for activities that use the support library action bar features. So, what are new features of AppCompatActivity over ActionBarActivity? What enhancements do AppCompatActivity have over ActionBarActivity? And what are advantages of AppCompatActivity? Could somebody supply a few samples?
PS: what surprised me most is that AppCompatActivity which is extended from android.support.v4.app.FragmentActivity is the direct parent class of ActionBarActivity! I mean actually now that ActionBarActivity can do anything that AppCompatActivity can do, why did Android pushed out the latter?
Meanwhile, I saw a blog post that states: "It's not a rename from ActionBarActivity to AppCompatActivity, the internal logic of AppCompat is available via AppCompatDelegate", so what's the "internal logic" of AppCompat? What can AppCompatDelegate do? Could somebody post some code about this?
As Chris wrote, new deprecated version of ActionBarActivity (the one extending AppCompatActivity class) is a safe to use backward compatibility class. Its deprecation is just a hint for you asking to use new AppCompatActivity directly instead. AppCompatActivity is a new, more generic implementation which uses AppCompatDelegate class internally.
If you start a new development, then you should rather use new AppCompatActivity class right away. If you have a chance to update your app, then replace deprecated ActionBarActivity by the new activity as well. Otherwise you can stay with deprecated activity and there will be no difference in behavior at all.
Regarding AppCompatDelegate, it allows you to have new tinted widgets in an activity, which is neither AppCompatActivity nor ActionBarActivity.
For instance, you inherit an activity from an external library, which, in turn, does not inherit from AppCompatActivity but you want this activity to have tinted materials widgets (views). To make it happen you need to create an instance of AppCompatDelegate inside your activity, override methods of that activity like addContentView(), setContentView() etc. (see AppCompatDelegate javadoc for the full list of methods), and inside of those overridden methods forward the calls to the inner AppCompatDelegate instance. AppCompatDelegate will do the rest and your "old-fashion" activity will be "materialized".
It's mostly a name change: ActionBarActivity doesn't really describe everything it now does. You can safely use ActionBarActivity if you wish to. Think of it like a symlink.
The AppCompat Support Library started with humble, but important beginnings: a single consistent Action Bar for all API 7 and higher devices. In revision 21, it took on new responsibility: bringing material color palette, widget tinting, Toolbar support, and more to all API 7+ devices. With that, the name ActionBarActivity didn’t really cover the full scope of what it really did.
http://android-developers.blogspot.it/2015/04/android-support-library-221.html
AppCompatActivity was introduced into Android-SDK since the release of android support appcompat library.
AppCompatActivity is the direct child class of FragmentActivity of support v4 and the direct parent class of ActionBarActivity.
AppCompatActivity is the base class for activities that use the support library action bar features.
You can add an ActionBar to your activity when running on API level 7 or higher by extending this class for your activity and setting the activity theme to Theme.AppCompat or a similar theme.
As for support v7 appcompat library, it adds support for the Action Bar user interface design pattern. This library includes support for material design user interface implementations.
Here are a few of the key classes included in the v7 appcompat library:
ActionBar - Provides an implementation of the action bar user
interface pattern.
AppCompatActivity - Adds an application activity class that can be
used as a base class for activities that use the Support Library
action bar implementation.
AppCompatDialog - Adds a dialog class that can be used as a base
class for AppCompat themed dialogs.
ShareActionProvider - Adds support for a standardized sharing action
(such as email or posting to social applications) that can be
included in an action bar.
After you download the Android Support Libraries, this library is located in the /extras/android/support/v7/appcompat/ directory.
Previously the only entry point into AppCompat was through the now deprecated ActionBarActivity class. Unfortunately this forced you into using a set Activity hierarchy which made things like using PreferenceActivity impossible.
see chris banes's support-libraries-v22-1-0 for more info
The latest release of android support library, 22.1, deprecates the ActionBarActivity in favor of AppCompatActivity, which promises to bring a single consistent ActionBar for all devices starting with API Level 7 and above
I want to create an activity that uses action bar ui pattern and fragments. Which base class my activity should extend, ActionbarActivity or FragmentActivity?
http://developer.android.com/reference/android/support/v7/app/ActionBarActivity.html
ActionBarActivity is the right answer
As #Pontus said, it depends on the way your requirements are:
If you are aiming API 11+ then you should go for FragmentActivity.
If you want to have your app compatible to older devices version 2.1+ then you will need the support library, ActionBarActivity.
In addition to ActionBarActivity, you have a very customized and easy to use library by Jake, ActionBar Sherlock available and its easy to implement as well. So if you wanna customize the actionbar and want it to be flexible you can even go for this.
Try and choose the best suit o your shoes. Happy Coding :)
Is it possible to add an Action Bar to an android application:
1) without subclassing ActionBarActivity
2) support for gingerbread and newer
I've searched google and SO, no results.
The reason I ask this is because I have an activity that already subclasses from another library, and I can't make the ActionBarActivity the root subclass.
Normally no, multiple inheritance isn't part of Java.
Of course, the real question is if ActionBarActivity will actually be useful on Gingerbread. It depends on what specific functionality you need from it.
What you can try to do:
Make your own "ActionBar" via layout.
If the library you're using is open source, modify it so its Activities extend ActionBarActivity instead.
If not, both ActionBarCompat is open source - you can download the source and incorporate the functionality into your Activity. ActionBarActivity does extend FragmentActivity, so you may need to work with the raw support-library source as well.
I know the answer for Q2 is YES. You use support library v7 to support Action Bars on devices running GingerBread (Eclairs and Froyos as well).
For Q1, i believe the answer is an YES. You just use the Window.requestFeature() to add Action Bars. But i am not very sure about this.
HTH.