clear mRestoreCropWindowRect and mRestoreDegreesRotated when using setImageBitmap #69
Conversation
There was a problem hiding this comment.
Thanks a lot for helping with this PR!
Would like to ask you to edit the CHANGELOG.md file
from this ## [unreleased 2.2.0] - to
## [unreleased 2.1.1] -
### Fixed
- CropImageView incorrectly restored on rotation[#68](https://github.com/CanHub/Android-Image-Cropper/issues/68)
And
(This is totally optional and don't need to do if you don't want or don't have the time)
Would be amazing to add this test case in our sample app!
We have the CropImageViewFragment class that already implement a CropImageView but didn't use the method setImageBitmap.
Would be very helpful to avoid breaking this again in the future, mainly when we change from java to kt!
Anyway, this is totally optional. Thanks for the help so far =D
| clearImageInt(); | ||
| mRestoreCropWindowRect = null; | ||
| mRestoreDegreesRotated = 0; |
There was a problem hiding this comment.
Nice!
What you think we add this both setting inside the clearImageInt() method?
Doing this, we can remove
mRestoreCropWindowRect = null;
mRestoreDegreesRotated = 0;
from method setImageUriAsync(uri)
There was a problem hiding this comment.
Yep, makes sense. I applied that suggestion.
I don't have time to look at the sample app, sorry.
These both need to be cleared when setting a new image via setImageBitmap, just like how they are cleared via setImageUriAsync. Also, the degrees need to be cleared immediately after they are used to restore the degrees. At the moment they are left there, lurking. I don't think this one is a bug since they are only used when mRestoreCropWindowRect is not null (which is also odd?) but it's still a code smell.
chriscoomber
force-pushed
the
issue-68
branch
from
f249524 to
4ba15d4
Compare
#68
Template 2 [Bug]
Bug
Cause:
mRestoreCropWindowRect and mRestoreDegreesRotated weren't being cleared in all cases where a new image was set. They lingered on and when an image is next added they overwrote the crop rect with an old state one, which may have been related to a totally different image with different dimensions.
Reproduce
See linked issue
How the bug was solved:
Clear out these member variables a) When setting a new image, and b) When they are used to restore state. (Some attempt at both of these points had already been made - just not enough.)