ankidroid
SDK: can we un-deprecate android.graphics.Path computeBounds [see last comment]
This one is related to:
- #17333
It is confusing because the new API does not show up in the reference documentation, only the old API with deprecation:
https://developer.android.com/reference/android/graphics/Path#computeBounds(android.graphics.RectF,%20boolean)
In the source, it appears to be flagged, and I don't know what that means but perhaps it is triggering the lack of documentation?
There may be an entirely different non-deprecated way to meet the functional requirement we need, or it may be as simple as doing a new Compat API internally to use one computeBounds for API < 35 and one for API >= 35 and ignore the flag but I wasn't sure so did not just do it while forward-porting in #17333
Here's the source of the old and new method for reference, appears to be a very simple forward port for us, just don't understand the FlaggedApi thing
/**
* Compute the bounds of the control points of the path, and write the
* answer into bounds. If the path contains 0 or 1 points, the bounds is
* set to (0,0,0,0)
*
* @param bounds Returns the computed bounds of the path's control points.
* @param exact This parameter is no longer used.
*
* @deprecated use computeBounds(RectF) instead
*/
@Deprecated
@SuppressWarnings({"UnusedDeclaration"})
public void computeBounds(@NonNull RectF bounds, boolean exact) {
computeBounds(bounds);
}
/**
* Compute the bounds of the control points of the path, and write the
* answer into bounds. If the path contains 0 or 1 points, the bounds is
* set to (0,0,0,0)
*
* @param bounds Returns the computed bounds of the path's control points.
*/
@FlaggedApi(Flags.FLAG_EXACT_COMPUTE_BOUNDS)
public void computeBounds(@NonNull RectF bounds) {
nComputeBounds(mNativePath, bounds);
}
@jainv4156 can you maybe tell us how you plan to solve it? Or at least update us when you figure out the proper way to do it? (Unless of course you expect to have solved everything in the following days, in which case more regular updates is not used)
Because that was noted as confusing in the first message. It's a new behavior for the App and I admit I'd be curious to understand what it means going forward
Can this be done on top of the main branch? I'd have suspected it should be done on top of https://github.com/ankidroid/Anki-Android/compare/main...dependency-updates given that it's the one with code for API 35.
Correct - this will have to start based on dependency-updates branch until the changes staged there are merged in I should do a dependency updates squash into main soon I am just holding off as I am focused on 2.19.1 items Once dependency-updates is squashed in then you would want to rebase whatever work you do here on to upstream/main and it will likely tell you that a bunch of commits are dropped/already included, that's fine
Specifically for this change though - it was confusing. I don't understand how/why they could deprecate one API and point to another new one, but the new one is Flagged by annotation in their code and not showing up in the documentation? Seems like a bug upstream in the android code either of a documentation type (should not be flagged, should show up in documentation) or a bug of code type where should not be deprecated. So the work here is to start with issuetracker.google.com to see if anyone has logged this, and if not, to log an issue questioning this new change and link the issue here
And a possible solution might be to step back and think about what we are actually trying to do here and just avoid the deprecated / new API entirely by doing it a different way then move on with our lives...
@Arthur-Milchior, I am away from my workstation for a couple of days. I will continue working on this issue after I return and will provide regular updates once I start working again.
I have searched issuetracker.google.com but couldn't find any issues related to the deprecation of compute Bounds. Although I can link a new issue, I suggest we look for an alternative approach since we only use this API in one place. To avoid relying on computeBounds, we should consider alternatives, especially since the new API is flagged and may take time to stabilize. If this change is not too much work, it would be beneficial.
@jainv4156 you should create a new issue in issuetracker if there is not one that exists. They are easy to create and you'll be (Internet) Famous :-). They shouldn't deprecate an API and point to an API that's flagged and doesn't show up in docs. That cannot be intentional on their part and someone should let them know
Agreed using an alternative way seems good, but that will only be possible if we analyze what we're trying to do and determine there even is a technically feasable way to do it. There may not be, I don't know - that will become the work effort here, someone needs to become the new expert and be authoritative about it
Yes, I agree! using alternative way seems one more work to do , so I will create a new issue and follow up on it
Do not create a new issue, there is no need to do that. This issue is tracking things nicely. Just post a PR when you have something to show.
This is the link to the issue: https://issuetracker.google.com/issues/377366942. As this is my first time creating an issue, any guidance would be appreciated.
@jainv4156 I think the issue is missing a lot of key information you could include easily and you should update it
- include the full actual method name you are talking about - the string you are using "Compute-bound" is meaningless, it is both not an actual string in use as an API anywhere that would work in Java nor is it unambiguous, like
android.graphics.Path::computeBounds - include a deep link to the android developer documentation for this specific API we are talking about, showing the deprecation warning for the method
- include a link to the android source showing the Flag of the new API, like for instance https://android.googlesource.com/platform/frameworks/base/+/refs/heads/main/graphics/java/android/graphics/Path.java#320
In other words: You are requesting someone's time by logging an issue - you should pay them the respect of making the issue complete and correct so you do not waste their time with obvious follow up questions like "what API is that?", "do you have an example of the documentation you mean?", "it's flagged really? where and how?"
Log great issues to respect people's time
Just to add, when linking source, also consider including a permalink to the revision as well as/instead of a link to HEAD
@mikehardy,
Thank you for your valuable feedback. I’ve added clarifying comments in the issue since I don’t have access to edit the description.
You can take a look at the updated issue here: Issue Link.
If there are any other suggestions or further improvements needed, please let me know.
@jainv4156 are you still working on this issue. If not then can I work on it?
I found that the method has been undeprecated in Android 16 beta 1. Does this mean the issue is no longer relevant? If it is still relevant, I can try making a compatibility wrapper if you would assign it to me.
Cheers! https://github.com/ankidroid/Anki-Android/issues?q=state%3Aopen%20label%3A%22Won%27t-fix%22
Reopening: investigate if we can remove the @Deprecated tags [maybe after a sdk update]
Indeed, the method appears to be undeprecated now so we can remove the deprecated annotation
Additionally, the method they advised everyone to move to no longer appears to be flagged but it is only available in API36+ so moving to it would require a Compat implementation
https://developer.android.com/reference/android/graphics/Path#computeBounds(android.graphics.RectF,%20boolean)