I am making an app, and I wanted to use Tabs for menu, however when I extend TabActivity in my class it says it's deprecated.
So my question is, when will this cause problems? Will this affect only like Android L phones or what?
Can I still use it without having problems? I only have 2 months left to make app, so I don't have time to learn about fragments, from quickly glancing over documentation it seems too long to bother spending time learning fragments.
Generally #Deprecated means that this feature will no longer be developed (for example no bugs will be fixed) and in some future release this will be removed completely.
However I know no example of feature or function being removed from Android API. Goolge usually tells us:
Hey, we invented something awesome, but it can no longer be
achieved using present mechanisms, so we implemented it from scratch! Please switch to our brand new mechanism whenever you will have time.
To summarize:
Using #Deprecated methods will not cause any problems by sole fact that they are deprecated. This features are obsolete now and there is something better, faster and more reliable in Android API that you should be using now.
Related
Android documentation encourages to use Fragment Dialogs on older versions of ADT by adding the support library. It claims that just using Dialogs can issue some memory problems. However when I added support library to my project it increased my footprint from 400K to 700k, so my application is just same size as the support library. It was a price to just show one simple dialog.
So question is really I have to sacrifice my application footprint by adding the library because Dialog implementation has real problems, and in this case I had to do that, or I can live with standard dialogs implementation?
Attention to moderators, it isn't duplication of How Android Support Library work?
since I am asking of an impact not using fragment dialogs and the support library on an application stability.
I think if you are only running API 10 and lower, but nothing higher, you might not want to add the support library. Seeing as you won't be using anything else (I'm guessing here from what you are saying), the footprint might not be worth it. The support library is meant for backwards compatibility, and since your intent is not to do that, remove it and use plain old Dialogs. If they are not deprecated then I don't see why not. Just make sure there are no performance issues (which is my guess as to why the doc encourages the use of the DialogFragment).
That being said is there any reason you are designing an app like that (pre honeycomb only app)? You really should be using Fragments. If you really don't want to use the support library, then design your app for API 12 and up. Not supporting older versions is more viable solution nowadays (if the adoption metrics mean anything). Plus its tried and true, so you will encounter less problems with the support (no pun intended) around it.
I realized that Gallery class in Android is deprecated, but I can still build my application and it runs correctly.
I don't care much about performance, since it will contain 2-3 pictures at most.
What I'm wondering is, is it safe to use Gallery ?
Will it work in all devices (including API > 16)?
And I hope that Android Dev Team replaces Gallery with another widget, instead of making us write our own galleries using HorizontalScrollView etc.
There are certain functionality deprecated by the Android Engineers just to make the developers use a newer implementation of the same. For example the Dialog Fragment requires a lot of coding to do the same task a showDialog() can possibly do. You are completely safe on this one as far as I know. At the same time, there are some other deprecation made due to security issues as well. In the case of Gallery, I understand that there is nothing wrong with using the deprecated class, except that it is deprecated. You are safe.
I just started developing on Android. I'm practicing with a Tablayout tutorial in API 15 when I see TabActivities are deprecated.
Would I be better off just forgetting about Fragments for now and keep developing with TabActivities?
Would I be better off just forgetting about Fragments for now and keep developing with TabActivities?
IMHO, no.
Get yourself a copy of ActionBarSherlock and implement tabs in the action bar. That is the tab pattern going forward with Honeycomb and Ice Cream Sandwich, and ActionBarSherlock lets you use the same approach for Android 2.x devices as well. You are better served aiming for the future, not the past.
Note that you do not have to use fragments with action bar tabs, though you can.
I suggest you learn Fragments. There's no point in using TabActivities any more, there's a static support libary (you can see it available for download in Android SDK Manager) that will allow you to use fragments on older APIs - that's the way it's meant to be done now.
Go with Fragments and action bar pattern, new is always better :)
Also, be ready to dump any other deprecated piece of API or obsolete UI approach. Mobile development evolves pretty quickly.
No, just follow the example here for how to Tabs with Fragments: http://developer.android.com/reference/android/app/TabActivity.html
Normally, I would say that using a deprecated API is a bad idea. However, since you are just practicing and presumably do not need to release this application on a wide range of devices, then just carry on with the tutorial and happy learning.
Hope that helps and enjoy Android.
Effective Java (Joshua Bloch) Item 17 says :
"Design and Document or inheritance or else prohibit it"
However, just a cursory glance through the Android APIs reveals that most of the API classes are non-final; which is OK if they are also documented for inheritance (View of Activity, for example). But there are also several non-final classes, but the documentation makes no mention about the inheritability of these classes. Just some arbitrary examples to illustrate my point:
The classes representing the System Services (WifiManager, NotificationManager ...)
Utility classes like UriMatcher.
Some hardware-specific classes like Camera.
Openness and extensibility being the philosophy of Android, is the convention reversed here? Meaning, could one assume that all of the Android API classes are designed to be inherited (whether explicitly documented or otherwise); unless declared final?
Just my €0,02: Clean OO design by the book is one thing, making things work for all possible use cases in practice is another. The principles of clean OO design sometimes are somewhat of academic nature. - And maybe a little bit of black and white.
Think for instance about who uses the Android API provided by google: It's not only app developers but also device manufacturers who need to specialize general APIs for their devices.
So, for me, SW design is neither black nor white in most cases; the shades of grey are important.
And finally: In practice I have seldom (read: never) seen problems caused by "carelessly" omitted final keywords (on classes), while unreflected overuse of final (often caused by thoughts like "my code is sooo [great | ugly], no one will actually ever want to modify it through inheritance") can be quite a pain.
"I know that I know nothing" seems to fit here: It is presumptuous to claim that one knows all the crazy, ingenious, creative, smart,... ideas of others for how one's code may be used in the future beforehand.
The Android developers went to great lengths to ensure that extensibility, while not recommended in many cases, is possible. The motivation behind this appears to be related to testing environments.
For instance, it would be much more difficult to create a faux WifiManager for the purposes of creating unit tests if it were finalized. Without the finalization, it is trivial to subclass the WifiManager (e.g. to mimic "unexpected" wifi disconnection during operation) and return an instance of this subclass from a customized testing Context.
So while you will probably never find a reason to implement a subclass of the these classes in an application that you ship to the end users, the flexibility is there to allow you to extend them if it is necessary for one reason or another.
In the case of utility classes, the answer is simply that the utility of the class is not diminished by allowing the developer to subclass; in many cases, a developer can achieve more understandable code reuse by inheritance than by aggregation and delegation.
I've been thinking about the pros and cons of using Android's Support Package when targeting the latest API and setting the min SDK to 7, for example.
The Android documentation states "The goal is to simplify your development by offering more APIs that you can bundle with your application so you can worry less about platform versions"; however, I'm having some doubt on whether it will make it simpler.
Consider the TabActivity, which has been deprecated. The alternative to using TabActivity is through Fragments and by looking at the example to get a tabular view working, it doesn't look simpler. Besides, I have to use reflection anyways when deciding on to use the Fragments class versus the FragmentActivity class, so why not just use TabActivity. I was hoping to get your opinion on this. I'm leaning towards not using it, but I would like to know if I'm missing out on any benefits.
The alternative to using TabActivity is through Fragments
An alternative to using TabActivity is through Fragments, using the icky stuff in the example you cite. The better alternative to using TabActivity is to put your tabs in the action bar, perhaps using ActionBarSherlock's fork of the Android support library that offers a backwards-compatible action bar.
by looking at the example to get a tabular view working, it doesn't look simpler
It's not.
Besides, I have to use reflection anyways when deciding on to use the Fragments class versus the FragmentActivity class
If you are using the Android support library, you should not need this, as you always extend FragmentActivity.
I'm leaning towards not using it, but I would like to know if I'm missing out on any benefits.
If you plan on supporting tablets and/or TVs, you want to be using fragments. Fragments are useful even in phone-only apps, but not quite as visibly.