The layout preview UI can't handle code with Renderscript (among other things), so now we avoid those code paths if BlurringView is being rendered by the IDE.
This shouldn't affect runtime performance on a device in any way, as the onDraw() method only checks if it's running in an IDE — via the isInEditMode() method — when no view-to-blur has been attached.
Without this, it's quite annoying to work with a layout that incorporates a BlurringView, as an error message continually pops up, obscuring part of the preview.
The layout preview UI can't handle code with Renderscript (among other things), so now we avoid those code paths if
BlurringView
is being rendered by the IDE.This shouldn't affect runtime performance on a device in any way, as the
onDraw()
method only checks if it's running in an IDE — via theisInEditMode()
method — when no view-to-blur has been attached.Without this, it's quite annoying to work with a layout that incorporates a
BlurringView
, as an error message continually pops up, obscuring part of the preview.See the before / after screenshots:
(click to see larger error screenshot)