I googled for this purpose but I couldn't find any answer for my question but I found Android Material Design with android studio , my question here is there any way to add Material Design Library to my android project in Eclipse.
thanks for any comment.
Obviously it does.
It doesn't depend on the IDE, Check out this.
It's in German, but it's all pictures, so, it's very easy to follow even if you don't know German.
Mind that you must have the SDK installed (21+). Simply do all the upgrades in the SDK Manager, then (when finished) Help/Check for Updates in Eclipse.
To make the newer SDK design apps work on lower level devices, you must set the minSDKVersion to the lowest API Level you want to support.
And use the support.library versions of the objects and the methods.
i.e.:
Use NotificationCompat instead of Notification
Use getSupportFragmentManager() instead of getFragmentManager(), ...
Related
I'm working with Xamarin.Android.
Appcompat is actually necessary for use material design because the nougat package (Android.support.design) requires it.
But why, for example, if I work only with API 27, I must add the AppCompat package? In my toolBox i've not the floatingActionButton, NavigationDrawer etc.. so I must add this packet to unlock them.
What is exactly this package? I've read on the web that this package works with backward compatibility but I only work with new APIs, so why I must install it?
Thanks.
AppCompat should add the functionality of the latest API to older APIs when needed. For instance, lollipop added the CardView class, which can be used in older Android APIs when AppCompat is used, with some minor differences (some of the Android L animations may not apply on older versions of Android for example). It is recommended to use AppCompat in most cases since more users will be able to run your app when you do (depending on your MinSdkVersion). If you want to know what classes you can access in AppCompat, you can take a look at the features here:
https://developer.android.com/topic/libraries/support-library/features.html
The Xamarin.Android.AppCompat is just what it says. Its a library for App Compatibility for backward compatibility for previous versions of Android and more specifically this version (v7) brings support for Action Bar support. Read more here :
AppCompat
They are libraries used for accessing the latest features of an Android OS version. It is backward compatible by the way.
Android dashboards show that only half of devices have Android 5.0 and above, but numbers look different for our customer data set - it's over 93% of our users. So we've decided to abandon support for devices with Android version lower than 5.0 and change minSdkVersion from 15 to 21.
This upgrade require from us to review all of obsolete functionalities and clean some hacky workarounds which we applied to support older versions. One of main functionality which we can apply now is to replace android.support.v4.app.Fragment with android.app.Fragment. It sounds like good idea, especially when we know that fragment API had been reviewed and improved.
Just to make sure that I’ll take right path and android.app.fragment won’t surprise me I would like to paraphrase question from this stackoverflow thread - Are you using fragments from the support library, even though they are already available, when developing for Android 5? Are there any bugs in fragment API which occur on Android 5.0 and above and were fixed in support library?
Update
After Android-KTX release, Jake Wharton made the following statement in one of PRs:
Thanks for taking the time to make the PR (with tests!), but we would like to encourage that developers only use the support library fragments. The next version of Android will deprecate the version of fragments that are part of the platform. Thus, we aren't going to add any extensions to support them in this project.
So using fragment from support library is the right thing to do.
I would suggest using the support library fragments anyway, for a few reasons:
Future features may be added and backported, and then you'd need to rewrite to use them
Consistency. The support library works to make sure support fragments always work the same. Whereas the native fragments may have subtle differences between versions.
The support library can contain bug fixes to the platform and can be updated much more frequently.
Edit: As of 2018, the OS level Fragment is deprecated. Google's path forward technically is to do less in the OS library and more in add ons. So for Fragment this is absolutely now support library, and likely to go this way for more items.
We started a fresh Android app few months back and we were wondering the same thing.
IMO, you should always try to use android.app.Fragment if it is possible. This way, you are certain that Android developers optimize, update and support this API and they will give you a quality product.
Right now, we are using android.support.v4.view.ViewPager and other similar components that provide different functionality in Support library than in the normal API.
what is the version of android from which further on there is no concept of incompatibility(no need of support libs). I am a newbie and this supporting and non supporting thing is making it so boring. I just want to know of a stable version from which I should take start and do not use support libraries (like appcompat, sherlock, etc). Also tell me if I am doing a wrong thing doing this I mean anything that will help me. Thanks
Any relevant help is appreciated.
As an app developer, you'd like your app to run on as many devices as possible. Generally, developers give support from API level 8 (Android 2.2) and upwards.
Most of the compatibility libraries are for pre-API 11 (HoneyComb).
So basically, it depends upon what you want to aim for.
Edit
You might be interested in checking out Choosing the right API Level for my android application.
Do you think is it a good practice to use Android Support Library if my app will support only devices which working on Android 4 ? Or it is unnecessary?
Alex. P.S. Sorry for my English:)
The Android Support package is not only for backports. For example, if you want to use ViewPager, you will need to use the Android Support package. And, in 2014, the Android Support package might get backports of things that are not in whatever your planned android:minSdkVersion is.
If, instead, you are asking whether it is necessary to use FragmentActivity, the AppCompat action bar, and similar backports, no, you will not need those.
Use the support library only if functions you want to use don't work on one of the API levels you target.
I'm creating an app that uses the clipboard manager. Since the way of working with this has changed since API level 10 but I still want it to work on all versions, I would like to use both APIs if possible. I would then like to code some kind logic like this:
if androidVersion < 10
use code x
else
use code y
Is this possible?
When I create a project in Eclipse, it either gives me the Android 1.6 jar file or the Android 3.0 jar file depending on the min SDK version I selected. My question is if it's possible to import and use both and if so how? Or will I simply need to make separate projects for different versions? Thanks.
Is this possible?
Sure. Use android.os.Build.VERSION to find out what version you are running on and use the appropriate code based upon that.
If you are supporting Android 1.x, the story gets a bit more complicated.
When I create a project in Eclipse, it either gives me the Android 1.6 jar file or the Android 3.0 jar file depending on the min SDK version I selected.
No, it does not. It gives you 1.6, 3.0, or whatever based on the build target you selected. By default, it also makes the android:minSdkVersion match that, but you can change that, so the minSdkVersion is the oldest that you are willing to support and the build target is the oldest whose APIs you are directly referencing.
My question is if it's possible to import and use both and if so how?
You do not need to import both, and you can't do that anyway.
Or will I simply need to make separate projects for different versions?
You do not need separate versions.