I have an existing app with a minSdk of 14, now targeting 21, and I would like to use Theme.AppCompat to get the "Material look" throughout. This app also uses ActionBar tabs and ViewPager (FragmentPagerAdapter, etc.). I was previously using the native ActionBar and Fragment classes, but in order to use AppCompat from support.v7 it looks like I also have to use support.v7.app.ActionBar and related classes.
The issue I then ran into is that some support library ActionBar classes, such as the ActionBar.TabListener abstract interface, define methods that require the support library version of Fragments (support.v4.app.Fragment, et al). So now I'm faced with extensive modifications throughout the app to import the support library classes, change to getSupportFragmentManager, etc.
Is this the only route I can take for using the AppCompat themes for V14-21 -- switch entirely to the support library for both the action bar and fragments? Do some of these classes pass thru to the native classes at execution time?
Related
I opened my old Android TV app project and tried to update the dependencies. I then updated the appcompat libraries to 27.1.1. I opened the leanback fragments and Android Studio warned me the BrowseFragment is deprecated and I should use BaseSupportFragment instead. Same case for other leanback fragments. I then changed all the fragment to AppCompat version (except for LeanbackSettingsFragment as there was no AppCompat version provided) and then changed my Activities extend AppCompatActivity.
After I made these changes, I built the app but when I launched the app I saw this error in logcat:
Unable to start activity ComponentInfo{net.swiftzer.trainboard.dev/net.swiftzer.trainboard.main.MainActivity}: java.lang.IllegalStateException: You need to use a Theme.AppCompat theme (or descendant) with this activity.
The theme I used for the app and activities are all under Theme.Leanback. But I checked the theme is based on platform native theme.
Should I stick with the deprecated leanback fragment classes or the leanback library do provides AppCompat themes? The leanback library is like a half-baked one. I saw the leanback library do provides an AppCompat version of fragments last year but no sample projects was using them. Now they marked the fragment classes extended from android.app.Fragment as deprecated but they didn't provide proper way to migrate.
You can't use Theme.Leanback for Activities extending AppCompatActivity. For using support fragments you can't extend the activity with android.app.Activity either. For using support fragments extend your activity with android.support.v4.app.FragmentActivity.
You are not allowed to use AppCompat theme for Android TV with Leanback library.
You should extend your BaseActivity of the FragmentActivity to benefit from the Support Components.
Given the following:
Android documentation says :
AppCompatActivity - Adds an application activity class that can be used as a base class for activities that use the Support Library action bar implementation.
I'm not considering adding action bar to my activity
I need some material design widgets, which I can control only through AppCompat or material theme, but the latest need API >= 21, which is not my case.
I tested Theme.AppCompat.Light.NoActionBar with Activity class and it works well.
--
Is there an issue with using Activity class with AppCompat theme in my case?
The AppCompat library is intended to make compatibility with olders API, so the Theme and all components may work well in older systems.
I think the only concern is to always use the AppCompat elements and not the regular ones.
Example, use AppCompatEditText, AppCompatTextView, etc... And always refers to they with the AppCompat (AppCompatEditText editText;)
I have used a lot the support library and not have others issues, considering the visual elements may be a little different when using an API minor than 21
No.There is not issues with AppcompactActivity & support libaray. You can refere this link
To gain more rich & amazing look go with support library,Try to do material design
I have a problem with ActionBar.
I set minsdk in AndroidManifest to 14. Next I create Activity (BlankActivity), thats create MyACtivity class which extend ActionBarActivity and import android.support.v7.app.ActionBarActivity. I think that this library need only if you use sdk level 7 or lower.
This import correctly? Or i need use another extend class?
And I try change extend class to Activity, but its does not create ActionBar on Activity.
How add ActionBar on this Activity?
P.S. I was misled, because on my sdk function getActionBar must work, its NullPointer, because my app use this strange import. A can use getSupportActionBar, but its strange use support library for sdk 7 to create Application for sdk 14 or higher.
P.S.S. Thanks!!
If anybody have same problen, there is some links about toolbar:
http://www.101apps.co.za/index.php/articles/using-toolbars-in-your-apps.html
Why was ActionBarActivity deprecated
I have a problem with ActionBar.
Who doesn't ;)
I think that this library need only if you use sdk level 7 or lower.
The appcompat-v7 library used to backport API 14 Action Bar to platforms below that. APIs 7 through 13 used this reimplementation, APIs from 14 used native Action Bar.
Since Lollipop the appcompat-v7 always uses it's own implementation of Action Bar and backports Material theme from Lollipop.
This import correctly? Or i need use another extend class?
To have the Action Bar with appcompat-v7 your activity class must extend AppCompatActivity (previously ActionBarActivity) and it's theme must descend from Theme.AppCompat.* family.
And I try change extend class to Activity, but its does not create ActionBar on Activity.
Native activities on Lollipop don't have any Action Bar by default. You would supply it by having a Toolbar widget in your layout and calling setActionBar(Toolbar). Similar approach can also be used with appcompat-v7 (if you use a theme without default action bar) by calling setSupportActionBar(Toolbar).
How add ActionBar on this Activity?
[...] but its strange use support library for sdk 7 to create Application for sdk 14 or higher.
It's perfectly OK, the goal is to make the app look the same from API 7 to API 22. Appcompat-v7 now backports not only the Action Bar but Material theme as well.
It's better you start with a working example. Just check in you android sdk installation for the folder \samples\android-21\ui\ActionBarCompat-Basic.
The use of the support library is correct, just follow the ActionBar Developer guide here.
In Android what is the main difference between extending Lifecycler Activity, Activity,ActionBarActivity & AppCompactActivity? How do these classes differ from each other in terms of usage?
extending ActionBarActivity gives you the ActionBars functionality on every API level >= 7
by extending Activity you can avoid adding additional projects/libraries to your project but you'll lack the ActionBar on api levels below 11
edit: More details:
ActionBarActivity is part of the Support Library. Support libraries are used to deliver newer features on older platforms. For example the ActionBar was introduced in API 11 and is part of the Activity by default (depending on the theme actually). In contrast there is no ActionBar on the older platforms. So the support library adds a child class of Activity (ActionBarActivity) that provides the ActionBar's functionality and ui
edit2: Update April 2015 - it looks like the ActionBarActivityis deprecated in revision 22.1.0 of the Support Library. AppCompatActivity should be used instead.
edit3: Update Aug 2017 - LifecycleActivity is a LifecycleOwner but:
"Since the Architecture Components are in alpha stage, Fragment and
AppCompatActivity classes cannot implement it (because we cannot add a
dependency from a stable component to an unstable API). Until
Lifecycle is stable, LifecycleActivity and LifecycleFragment classes
are provided for convenience. After the Lifecycles project is
released, support library fragments and activities will implement the
LifecycleOwner interface; LifecycleActivity and LifecycleFragment will
be deprecated at that time."
(copied from the Architecture Components guideline)
If you look carefully, you will see this
public class ActionBarActivity extends FragmentActivity
implements ActionBarDrawerToggle.DelegateProvider TaskStackBuilder.SupportParentable
Here you can read about FragmentActivity:
http://developer.android.com/reference/android/support/v4/app/FragmentActivity.html
And differences between Activity and FragmentActivity:
Difference between Activity and FragmentActivity
Also, there are some new themes for styling actionBar...
https://developer.android.com/training/basics/actionbar/styling.html
Actionbar is introduced in API level 11. com.android.support:appcompat-v7:+ is a support library which allows you to have an ActionBar in your app for devices running on Android 3.0 or below. So, if you need actionbar below api level 11 your Activity needs to extend ActionBarActivity.
If you are targetting api level 11 and above then you don't need to extend ActionBarActivity and reference AppCompat. You can simply extend Activity and you will have actionabr by default.
Android Studio default project includes it automatically in dependencies and extends ActionbarActivity instead of Activity in order to use it.
The ActionBarActivity or the SupportActionBarActivity have additional methods and properties that are not in a generic Activity. for example methods for adding tabs are present in the ActionBarActivity and not in a generic Activity.
The major difference being you don't get an ActionBar on a generic Activity.
ActionBarActivity just has more support libraries and better usage of the newer themes available from api 11.
"In its most basic form, the action bar displays the title for the activity and the app icon on the left. Even in this simple form, the action bar is useful for all activities to inform users about where they are and to maintain a consistent identity for your app."
You are using Android support library When you come to to the Actionbaractivity . so the uses of Support library is your application can be suport for maximum number of devices. Support library gives to your application the power of Backward compatibilty. Actionbaractivity gives you the mulitiple feature like Actionbardrawer toggle etc.. there are more support libraries available. see this link .. and share to your friends...https://developer.android.com/tools/support-library/index.html
If I do not need to grant support for older versions of android and can just use API 17, is there an alternative way to implement the much advertised horizontal swipe (like in gmail) and not use viewpager, fragmentsactivities (new APIs already have fragments...) etc. to get rid of the support library?
All the tutorials I've found for horizontal swipe show how to do it using the support library and FragmentActivities. Otherwise what is the advantage of the new APIs if I cannot use their native classes and methods?
to get rid of the support library
ViewPager only exists in the Android Support Library. The Android Support Library is not just for backports.
new APIs already have fragments
ViewPager can use native API Level 11 fragments, though you may need to create your own PagerAdapter. Or, you can use ViewPager without any fragments, using just ordinary View or ViewGroup objects for the pages.
is there an alternative way to implement the much advertised horizontal swipe
You are welcome to write your own replacement for ViewPager. Most developers prefer to reuse ViewPager, for reduced development and maintenance costs.
There is also HorizontalScrollView, an open source HorizontalListView floating around, and so on.
You can write your own FragmentPagerAdapter which works with android.app.Fragment instead of android.support.v4.app.Fragment to minimize dependency on the support library. You only need to create your own class for the adapter (based on FragmentPagerAdapter from support library which source can be found in folder <android-sdks>/extras/android/support/v4/src/java/android/support/v4/app/). Only modification is in the import section - you should reference Fragment, FragmentManager and FragmentTransaction from android.app instead of android.support.v4.app.