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.
Related
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.
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.
Is there a easy way to have our application look like ICS or JB?
Mainly the slider and the radio button. They look old when displayed in green.
Any hint about this?
There's a nice package available on github called HoloEverywhere.
One thing though, do not try pass it off as a ICS/JB Application, just because it "looks" like the user interface one would expect to see in a native ICS/JB Android set up.
Best that can be done with the project, is to target the latest SDK to guarantee your wide-market of Android usage, including GB.
Aim high, not low ;)
The best way is to use the Android Library 'Actionbar Sherlock'. This Library uses all native ICS Themes, etc for older devices.
ActionBarSherlock is an extension of the compatibility library designed to facilitate the use of the action bar design pattern across all versions of Android with a single API.
I'm looking to create a cross-version compatible android tabbed layout.
The problem I'm running into is when implementing Google's example of TabActivity, I get a depreciation notice. The app I'm writing needs to be compatible down to 2.1, and I'm not finding a clear cut way to make it compatible.
I am aware of the versioning by folder (/layout-v4, /layout-v14, etc) but if possible I want to avoid this.
Are fragments the answer here and if so, does the Android Compatibility Layer V4 become the key to solving this problem?
I'd suggest the best approach might be to use the excellent (and free) ActionBarSherlock, so you can add Android 3+ action bar (including tabs) to apps going all the way back to v2.x versions.
I've used it on a few apps and it's pretty easy. I think it's the right approach to use the proper Action Bar interface across platform versions, and they include tabs and replace the whole TabActivity thing, which was pretty horrible anyway.
http://actionbarsherlock.com/