Using Toolbar and Cast SDK with minsdk="14" without v7-appcompat - android

I have an app that supports Android v14 and up. I'd like to use the Cast SDK, as well as some of the Material features that were added to v7-appcompat. I'm currently using v13-support, which wraps v4-support but let's you use real Fragments.
Is there any way to use the Cast SDK back to v14 without incurring the cost of using FragmentActivity et al? Needing to replace all my styles/themes and base classes, go find every reference to getFragmentManager and replace them all with getSupportFragmentManager so on, and so on...?
The features that I"m interested in from v7 support library have seemingly nothing to do with Faux Fragments or Faux Holo themes...the idea of refactoring the whole app to use the Faux Fragments in order to use Cast seems audacious.
Anybody know an alternative?
(the app i'm working on has backwards compatibility issues beyond the v7 support library, so using v7 wouldn't change the fact that the app needs to be 14+)

Related

Difference between support.v7.widgets and android.widgets Toolbar, Fragment

I am creating a new application and will have to deal with ActionBar. I know that I have to extend the AppCompatActivity because the ActionBarActivity is deprecated, however I still do not understand why I have to use the support.v7.widget Toolbar rather than the android.widget Toolbar even though I am using the latest API ?
Thank you
EDIT1:
I understand now that the support.v7.widgets are there to enable devices with old APIs to comprehend what are the new functionalities added in the newer versions and mimic them in their own way. Is that correct ?
If that is correct and I do not want to have any sort of backwards compatibility does this mean I can move forward and use the android.widget Toolbar ?
Also using the android.widget Fragment unfortunately I can not add it to a ViewPager. Why is that ? Why does it force me to use an older version which has been extended to mimic the behaviour of the new implementation of the component ?
I think I just getting lost in all of those "support" libraries. Can someone briefly ( or not ) explain all that - why are there things in the support libraries that are not included or updated in the newer versions of the API ?
Thank you
First of all you are asking Good Question, Android will add advanced features continuously in different API levels but those features are available from which level of API they are added
For Example: Consider android fragment functionality was added in API level 11 that means it will work for API level 11 and above but your application need for API level 10 devices also at that time it wont be work. For this reason android develop support library for cover a wide range of Android devices (support for low level API) to work those functionality.
Android always recommend developers to use support library for development for more information check here
Support.V7.widgets and widgets.android both are different libraries.
support.v7.widgets uses design library.
toolbar actually not an actionbar we are manually implementing a
ActionBar with support library.
And there are lot more new inbuilt properties are included like observableScrollActivity and More material designs...,
Why we aren't using default actionbar?
Because ActionBarActivity is depricated. Comparing old actionbar with our latest sdk actionbar it gives good look.
.setSupportActionBar(toolbar);
After Setting support to the toolbar gives actionbar properties to the toolbar like we can hide it by getSupportActionBar().hide();

Why am i using support.v4 package when I am using Android v 17?

I think I'm missing something, but don't really understand the reasoning behind the support packages for objects like ViewPager and Fragment etc and how do I know which one to use?
I'm writing an app with min sdk 16, why are the objects not included somewhere in the API without the "support.v4" (some appear to be support v.13) qualification?
Can somebody shed a bit of light?
The support library is for the following reason:
for backwards compatibility
for functionality that is not included in the standard SDK's such as ViewPager
Here, ViewPager isn't included in the standard SDK. So, if you want to use Viewpager API then you have to use support library.
Fragment in the support library is mainly for backwards compatibility. If you are implementing something using support library which required to use Fragment then you will need to use Fragment from support library.

Android Which Fragment (and Activity) to Use

I have a library of Android code that I use throughout my Android projects. I created it a while back, and it uses the v4 support library (any Fragment subclasses inherit its Fragment, and all my Activitys are FragmentActivitys).
In most of my projects I have a BaseActivity class that inherits from FragmentActivity so that I don't have to worry about accidentally defining a non-support library Activity and try to use one of the Fragments from the support library. I put a lot of my application specific boilerplate in this BaseActivity.
I'm now working out the logistics of dropping support for one of my apps for devices below ICS. I have found a few issues regarding how to continue to use my Android library, which mostly boil down to whether I should continue to use FragmentActivity and the support library's Fragment even after dropping support for HC-.
I'm stuck between the convenience of "native Fragment and ActionBar and the new capabilities they come with, and the backwards compatible nature of the support library (eg, nested fragments for 4.0-4.1).
Anyone have any input as to whether I should keep using the support library, or if it's worth it to find some way to have a ridiculous amount of version checking and code overhead to provide implementations for versions that needs the support library and versions that can use the current API?
I would suggest keeping the support library implementations. This allows you use things like ViewPagers without worrying or mixing and matching implementations. It also ensures that the underlying code won't change on you until you update the support library jar.

"The type TabActivity is deprecated" For app tab

"The type TabActivity is deprecated"?
I am making the Tabs of app following tutorial book.
I've checked from the android developer.com website, but i have no ideas on the significance of the following message : This class is deprecated.
New applications should use Fragments instead of this class; to continue to run on older devices, you can use the v4 support library which provides a version of the Fragment API that is compatible down to DONUT."* (http://developer.android.com/reference/android/app/TabActivity.html)
What is v4 support library?
How to finish the tab functions?
You can still use a deprecated package. It is however recommended to use Fragments, and thus the support package. You can read more about it here. However, if you are a beginner at java and android development, I would recommend ignoring the deprecation for now and come back to this when you have completed the tutorial you are currently using if you find it educating.
If you want to watch a nice example of tabbed navigation using Fragments, then create a new project in Eclipse using android 4.0 or later. Make sure your android-plugin is updated. You will get the option to create a project with basic navigation already implemented.
"Deprecated" means that the api developers don't recommend using it anymore, probably because its not a good model, or inefficient, etc. Fragments were introduced in Honeycomb and can be used to provide a similar functionality as tabs and is more in-line with android's current design philosophy.
Since Fragment was introduced in Android 3.0 Honeycomb, you might think you cannot use that for pre-Honeycomb devices. Enter Support Libraries. They are libraries which you can include in your application which needs to run on pre-Honeycomb and still use this class.
So if you want to, you can finish the TabActivity as described in whatever tutorial you are following, it'll probably work on a few more upcoming android versions. But it is recommended that you start using Fragments.

ViewPager with indicator without Android's support library

Right now I'm using the ViewPagerIndicator for swipe-able fragments with an indicator in my program and it's working like a charm. But since Google is pushing more and more into the direction of Fragments without using the Android support library and e.g. PreferenceFragments aren't available in the support library, I'm wondering if there is something similar to the ViewPagerIndicator that's using the standard Android library.
Google is pushing more and more into the direction of Fragments without using the Android support library
And your proof of this is... what, exactly?
e.g. PreferenceFragments aren't available in the support library
It is not possible to backport PreferenceFragment very easily, as there are many other requirements to make that useful (e.g., backporting the new PreferenceActvity). I have personally looked into backporting the preference fragment system and concluded that it would be significantly more pain than it is worth to me.
I'm wondering if there is something similar to the ViewPageIndicator that's using the standard Android library
By definition, that is impossible, as ViewPager is in the Android Support package, which means any indicator for ViewPager must use the Android Support package.
However, there is nothing about ViewPager that requires you to use fragments. You are welcome to create your own PagerAdapter implementation that does not use any fragments, or uses native API Level 11 fragments, if you so choose.

Categories

Resources