I am very new to Android Development, but can I ask why the FAB is not supported in Activity and only in AppCompactActivity. Correct me if I am wrong but it's my understanding that as long as you are not bothered with backwards compatibility then using Activity is the one to use as you can directly implement material themes and use the latest material design like CardViews RecyclerViews and other layouts like CoordinatorLayout. Why then when you want to use a material design feature like the FAB does it force you to use the AppCompactActivity, I thought using the one supporting higher APIs would work. Am I missing something here, I know there are third party libs I can use, but I really need to get my head around this...
FloatingActionButton is not a part of core android library. Rather it is a part of android support design library.
compile "com.android.support:design:27.0.2"
This means this class is not pre-installed in android devices. Also to use it, your activity must use one of the AppCompat themes. Hence you need to use appcompat library to use a default FAB.
compile "com.android.support:appcompat-v7:27.0.2"
However, you can find many open source third party libraries for FAB in GitHub.
Related
I have to implement FloatingActionButton in my company's Android Application.
The problem is, the app is pre-style with Holo theme. When I ran the app, it crashed, the error is
"java.lang.IllegalArgumentException: The style on this component requires your app theme to be Theme.AppCompat".
So, the question is: Is there a way to implement FloatingActionButton without AppCompat theme.
The FAB is built into the new Design Compat library - which will work on devices as early as API 7. You will need to include it as a dependency to use it (and shouldn't hesitate to do so).
If you want to avoid using a library (or any external code) you will need to draw the FAB yourself (using a Shape Drawable).
Bottom line, using the Design Compat lib is the preferred method for supporting a FAB, and you should use it. The Design Compat lib IS the "pure/Material API21 stuff".
There is NOT a FAB implementation implemented for any API other then the one in the Design support lib. You have to include the lib, or implement the code entirely yourself.
The Design lib has a dependency on AppCompat, so if you are planning on using the native fab, you will also need to include the dependency for AppCompat.
"Note that as the Design library depends on the Support v4 and AppCompat Support Libraries, those will be included automatically when you add the Design library dependency."
I'm studying about the layout types in Android and I started construct a floating button and I would like to know what is the best mode to create a floating button in Android Studio. Using floatingActionButton library at Android Studio or creating without libraries.
I advise you to use the support one when it answers your needs (or at least start with it until you see a major drawback).
Most of time, if the support library covers your needs, you'll be less likely to have bugs or issues with it than you would with a third party library.
So I'm creating an app that is Lollipop 5.0 API 21 and up with zero interest in supporting older devices. Do I still need the appcompat library when using Material Design like UI elements & layouting (sidebar aka nav bar, ink, etc) ? When stripping it down I often encounter crashes when trying to move away from the AppCompat stuff. Changing activity types from the AppCompat one to the Normal one, I end up with problems regarding dependencies on layout types like the coordinator layout that aren't there.
I'm still new to android and this is very confusing, as my theme is currently in limbo somewhere between the appcompat theme & material design when I tried to change it from one of the template.
I've read that this is an android studio issue because it always uses appcompat regardless of your set dependencies & minimum API levels. Forcing you to manually override every implicit hidden appcompat call.
When trying to dump AppCompat, what changes to I need to do to make that happen ? Manifest, Activities, Menus, Layout, Styles ? It seems to touch all these things. If going exclusive without Appcompat, do you still need the v21 folders or will it grab the default ones ?
Do I still need the appcompat library when using Material Design like UI elements & layouting (sidebar aka nav bar, ink, etc) ?
If you are using classes out of the Design Support library, such as NavigationView, you generally need to use appcompat-v7 and AppCompatActivity. As of early May 2016, Google has not shipped a Design Support library analogue that works with Theme.Material. You may be able to find third-party library replacements for some of those widgets, and seasoned Android developers can sometimes "cross-port" these components to eliminate the appcompat-v7 dependencies.
I've read that this is an android studio issue because it always uses appcompat regardless of your set dependencies & minimum API levels. Forcing you to manually override every implicit hidden appcompat call.
The only place that Android Studio really cares about appcompat-v7 is in the new-activity wizards, which you do not have to use.
When trying to dump AppCompat, what changes to I need to do to make that happen ? Manifest, Activities, Menus, Layout, Styles ?
That is difficult to answer in the abstract. You would need to:
Stop using Design Support library widgets and containers
Stop inheriting from AppCompatActivity
Change your app: attributes in your menu resources to their android: equivalents
Change your theme to not use Theme.AppCompat
If going exclusive without Appcompat, do you still need the v21 folders or will it grab the default ones ?
-v21 resource directories are not tied to appcompat-v7. They will still be used, on API Level 21+ devices.
Recently I'm studying the usage of the appcompat support library and the design support library. And I met a strange question(at least for me) that I can't understand.
In the appcompat support library, there're several AppCompat* like components, such as AppCompatButton, AppCompatCheckBox... There's one same thing among these components - In the official doc all these components have such illustration,
This will automatically be used when you use Button in your layouts.
You should only need to manually use this class when writing custom
views.
or something like this.
Here come's the question. Since Button isn't AppCompatButton, how can it consider it as AppCompatButton when I use Button during the xml or created in code? How does it work?
Forgive my Cantonese English.
Short brief on how the AppComp decided which class to init -
When using the support library (AppCompat) using the support library widgets (e.g. android,support.v4.widget.Button) ,the library will use the appropriate implementation based on your Android OS.
For example ,if your OS support Button it will use the native implementation ,else it will use the AppCompat implementation.
In other words ,it defers to run time to decide what to use..
I assume this is the automatically part..
By Using DrawerLayout (by using android.support.v4.widget.DrawerLayout)from Android support library, we are achieving the navigation drawer functionality in our Android app.
But this is the ONLY thing an app needs from android.support.v4.
Is there a way or a roadmap in future exist, where DrawerLayout becomes part of android.jar(like Fragment who migrated from support-library now into android.jar)?
This way developers are not required to add a library(android.support.v4) just for using 1 widget/class from it!
Also, Currently, is there a way to continue using DrawerLayout without a need to add android.support.v4? App does not have a requirement to use other Navigation patterns like Toolbar or ViewPager.
With a large amount of functionality being unique to support-v4, most of the components in that library will remain there long term as it allows continual bug fixes and evolving of those components to meet the latest design and functionality specs without leaving broken versions in older versions of the framework. If you are using ProGuard (either directly or via the gradle minifyEnabled line), parts of the support library you are not using will be completely stripped from your application.
Of course, you can certainly extract DrawerLayout from the library and embed it in your application: the source is readily available if you find it necessary.