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.
Related
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.
For my new assignment, I wanted to use some library that can provide a "Posterize effect". I found many library like Aviary SDK and jhlabs, Yes, these are easy to use, but these making the code heavier. SO I keep searching for Android's API itself which can do the similar task. And after a lot of RnD, I finally found one my time saver class EffectsFactory which provides the same as I wanted. I applied it in my assignment also. But the bad thing it was added in API level 14, And my app should be compatible with at least API level 8.
So, My question is,
Can I use EffectsFactory class for lower version? If Yes then How?
Or, If No, Then Do we have any API in Android SDK itself which do similar to effectfactory ?
Please avoid referencing any library or NDK's open cv library.
No, there is not an Android API that will posterize an image below API 14. Even above API 14 EffectsFactory may not work, as it says in the Android documentation:
Some effects may not be available on all platforms, so before creating a certain effect, the application should confirm that the effect is supported on this platform by calling isEffectSupported(String).
However, you could easily make a lightweight solution yourself. Posterization is a simple process. For example, the code behind JHlabs' posterize filter is less than 50 lines (and most of them are sugar). In your shoes, if using a 3rd party library was out of the question, I wouldn't hesitate to write my own.
Edit: If you happen to be posterizing images your app takes from the camera, there is also Camera.Parameters.setColorEffect(), but again this is not supported on all devices, as it says in the documentation:
For example, the application should call getSupportedColorEffects() before calling setColorEffect(String).
Are there any disadvantages to using deprecated methods in my code?
For example, I am using view.setBackgroundDrawable(background) in api 19 and it's working fine, but I want to know the proper way.
The main disadvantage is that the API might not be available in future versions, which will increase the cost of updating your application. It's also an indication that the SDK developers believe that there is a "better way" to do what you want to do.
Thus, in the end, it's a cost/value tradeoff: If the deprecated method is easy to replace, use the replacement. If it isn't, it's up to you to decide whether developing the "future-proof" way is worth the additional effort.
For example:
setBackgroundDrawable can easily be replaced by setDrawable (see the comment in the documentation of setBackgroundDrawable).
On the other hand, startManagingCursor is much harder to replace, so one might put off transitioning to ContentProvider until there is no other option.
I see quite a few good old useful methods or even entire classes being "deprecated and obsolete".
But code that used to call those methods continues to work. So, what does this mean to me, as an Android applications developer?
Continue using this method as long as I want, because newer SDKs
will always remain backward compatible.
It will work as long as I build for older targets (e.g. API 8), but
if I build from API 14 up, the compiler will refuse to complete
the build.
Both (1) and (2)
Other?
This is especially confusing when no alternatives are provided, as in the case of WebView.PictureListener.html#onNewPicture.
It usually means that there's either a better way of doing things or that the deprecated functionality had some irreparable flaw and should be avoided. You can usually keep using deprecated methods, but you are advised to either switch to some new API (in the first case) or find some other way of doing what you want (in the second).
Regarding onNewPicture in particular, the entire PictureListener interface is deprecated. There's no sign of what, if anything, is supposed to replace it. A comment by #CommonsWare in this thread is food for thought:
It is conceivable that upstream changes in WebKit are driving the deprecation and that support for PictureListener might be totally lost in some future release.
I would go with 4:
It will basically tell you that the use of the method or class is discouraged; it is NOT 100% that they will keep backward compatibility (they can decide to not include that method in future releases), so you should try to use the replacement of the method or class. This is sometimes not possible to use the new methods (for instance, if you want to support devices running older versions).
Some other times it is actually possible. For instance, the showDialog method is now deprecated and they recommend to use DialogFragment class. You can achieve that even in older versions of Android by using the compatibility library.
Deprecated methods are not guaranteed to remain backwards compatible. They might remain in there for a few more releases just to give everyone a chance to migrate away from them before the developers remove them. The fact that they're deprecated means that the developers think that there's an easier, faster, neater, or otherwise better way to do whatever that class or method does.
It's probably better to change your code to use a non-deprecated interface now, since if you wait and it does get removed, your users will see crashes and errors.
Even when they are deprecated, they may compile but not work. Google has decided to delete various functionality at the low OS level.
Case in point. Google, at android release 2.3 deprecated many but not all method API's that allowed call recording. They compile OK but do not function since Android 2.3 and forward on any android phone device, or tablet with phone capabilities.
As an example for a deprecated interface that has been removed in a later API level, consider the org.apache.http package: It has been deprecated in API level 22 and removed in API level 23.
Of course on actual Android devices, the classes contained in that package will still be available in the system libraries (otherwise, applications targeting an older Android release would no longer run on that device).
They are however not available in the SDK anymore, so compilation will fail unless you either change the target/build SDK to an older version (or manually include the deprecated classes).
If Google were really determined to discourage use of those libraries, they could modify the implementation so that the affected classes check the target API version of the running application and complain and/or throw a runtime exception.
The AbsoluteLayout class is deprecated but still can write it in code and it works. Will there be any problems if I use this class? Will the application work correctly after I deploy it on a phone?
Thanks
Deprecated generally means that you are discouraged from using it because better methods exist. It can also serve as a warning that it will be removed entirely in future versions.
I would think you would want to stay away from absolute layouts because it can prevent your UI from scaling correctly on different resolutions, and it might not work at all on later versions of Android.
"will the application work correctly after I deploy it on a phone" most likely yes, but like I said you are probably going to run into issues with phones having different display resolutions.
This is a mighty assumption. It depends on the purpose, a business application on a standard large-screen device (tablet) may have a reason to go absolute.