I am new to android programming and I have been doing lots of tutorials all over the internet but I keep bumping into deprecated methods, like for example when I call BitmapFactory.Options.inPurgeable, android studio crosses out inPurgeable, giving message that method is deprecated.
Where do I find alternatives to deprecated methods?
It's deprecated because this flag is ignored starting Lollipop. Also use of it can lead to dropped frames. As documentation mentions - use inBitmap method instead.
The documentation says:
This field was deprecated in API level 21. As of
Build.VERSION_CODES.LOLLIPOP, this is ignored. In
Build.VERSION_CODES.KITKAT and below, if this is set to true, then the
resulting bitmap will allocate its pixels such that they can be purged
if the system needs to reclaim memory. In that instance, when the
pixels need to be accessed again (e.g. the bitmap is drawn,
getPixels() is called), they will be automatically re-decoded.
So there should be no need to add this anymore...
... however, according to Romain Guy, it still makes sense when decodeByteArray() is used:
This flag is currently completely ignored' is true in certain cases only - in other cases (e.g. when using decodeByteArray on downloaded data) then this flag is not ignored and is very, very useful
Related
I recently came across the deprecation of clipRect(Rect,Region.Op), which I would like to use with DIFFERENCE. This was replaced with clipOutRect(Rect) and thus I implemented:
#Suppress("DEPRECATION")
fun clipOutRect(canvas: Canvas, rect: Rect) =
if (SDK_INT >= O) canvas.clipOutRect(rect)
else canvas.clipRect(rect, DIFFERENCE)
Now this looks like it could be a compatibility method in AndroidX, but for some reason I was not able to figure out, where I could find it exactly.
Is there a class already providing a compatibility method for clipOutRect(Rect)?
Short answer is - no. The only thing related to Canvas in AndroidX is this file: https://github.com/aosp-mirror/platform_frameworks_support/blob/androidx-master-dev/core/core-ktx/src/main/java/androidx/core/graphics/Canvas.kt
Long answer.
First of all, Canvas is passed to view by native code, so it will be awkward to have something like onDrawCompat(canvas: CanvasCompat) in ViewCompat class. And I think there is no reason to do that at all.
Also, it's really not that type of deprecation you should worry about.
For example WifiManager.startScan() is noted with
This method was deprecated in API level 28. The ability for apps to
trigger scan requests will be removed in a future release.
That says Change this code now, or it will be broken year later
That not the case with clipRect, it will be kept for backward compatibility with apps that won't be ever updated for years or even tenth of years. Deprecation warning for this is just like Hey, we have new method with better functionality/name, if you target minimum is API 26 you can use that
My app uses a proprietary implementation of Canny edge detection based on RenderScript. I tested this on numerous devices with various APIs and it worked very reliably. Now I got the new Samsung S7 working on API23. Here (and only here) I encountered a rather ugly problem. Some of the edge pictures are studded with thousands of artifacts that stem from the Magnitude gradient calculation kernel and are NOT based on actual image information. After trying with all kind of TargetAPIs, taking renderscript.support.mode on and off, etc. I finally found that the problem only arises, when the RenderScript (and Script) instances are used for the second or more times. It does not arise when using them for the first time.
For efficiency reasons I created the RenderScript and Script instances only once in the onCreate method of MainActivity and used it repeatedly thereafter. Of course I don't like to change that.
Does anyone have a solution of this problem? Thanks.
UPDATE: Crazy things are going on here. It seems that freshly created Allocations are NOT empty from the outset! When running:
Type.Builder typeUCHAR1 = new Type.Builder(rs, Element.U8(rs));
typeUCHAR1.setX(width).setY(height);
Allocation alloc = Allocation.createTyped(rs, typeUCHAR1.create());
byte se[] = new byte[width*height];
alloc.copyTo(se);
for (int i=0;i<width*height;i++){
if (se[i]!=0){
Log.e("content: ", String.valueOf(se[i]));
}
}
... the byte Array se is full of funny numbers.... HELP! Any idea, what is going on here?
UPDATE2: I stumbled over my own ignorance here - and really don't deserve a point for this masterpiece.... However, to my defense I must say that the problem was slightly more subtle that it appears here. The context was, that I needed to assign a global allocation (Byte/U8) which initially should be empty (i.e. zero) and then, within the kernel getting partially set to 1 (only where the edges are) via rsSetElementAt_uchar(). Since this worked for many months, I was not aware anymore of the fact, that I didn't explicitely assign the zeros in this allocation.... This only had consequences in API 23, so maybe this can help others not to fall into this trap.... So, note: other than numerical Arrays that are filled with 0 (as by Java default), Allocations cannot assumed to be full of zeros at initiation. Thanks, Sakridge.
Allocation data for primitive types (non-struct/object) is not initialized by default when an Allocation is created unless passed a bitmap using the createFromBitmap api. If you are expecting this then possibly you have a bug in your app which is not exposed when the driver initializes to 0s. It would help if you can post example code which reproduces the problem.
Initialize your allocations by copying from a bitmap or Java array.
Here is the image that show the objects that are depreciated...?
What does this mean?
Deprecated means that you should not use it anymore but a new implementation of it, because it will be removed from framework / language whatever in future releases. In most cases there is a description at this method or documentation what you have to use instead.
Tried endpoint.audDevManager().setOutputVolume(percentage), with values ranging between 100-1999. Unfortunately, it's not resulting in any increase in volume.
The documentation suggests that:
This method is only valid if the device has PJMEDIA_AUD_DEV_CAP_OUTPUT_VOLUME_SETTING capability in AudioDevInfo.caps flags.
And I've already ensured that this flag is set. Is there anything else that I need to take care of?
Sauw Ming suggested (over mail) to use AudioMedia::adjustRxLevel(float level) instead, and that fixed the issue for values of level over 3.0. At least that's when there was perceivable difference in volume.
I also worked with endpoint.audDevManager().setOutputVolume(percentage) and it works after the call start.I got the change of volume.Also i used the range 1-100.Please check it with this settings.
So I just had to up my min API level to 11 for the Preference (addpreferenceresource was depreciated) - turns out 9-10 takes out like 50% of the market. So my question is, is it better to just suppress the warning to cater to the Gingerbread market or is there a different way to make my preference reference without using Preference Fragments?
I would implement both types (the one that works in 11+ and the one that works in 10-), then use conditional checks for them. This is written in quite a bit of detail in this answer.
Basically, you end up setting up OtherPreferencesActivity with PreferenceFragment, and then PreferencesActivity with the deprecated PreferenceActivity. (Your APK will not break by including this deprecated code, as long as you use a version check so that if/when it's removed in the future, it doesn't try to find it.)
if (Build.VERSION.SDK_INT < 11) {
startActivity(new Intent(this, PreferencesActivity.class);
} else {
startActivity(new Intent(this, OtherPreferencesActivity.class);
}
Keep in mind, you will want to have them use each others' methods as much as possible so that you don't end up duplicating code.
Last tip: #TargetApi(11) and #SuppressWarnings("deprecation") will come in handy here. Just be careful that you're not ignoring other deprecations by doing so.
"depreciated" doesn't mean you can't use it and will break your system if you run the code. It means that it is officially not recommended to use and this method maybe removed from the api. In the future but we don't know when. So I would say it is save to use in this case for now.