Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Discussion options

Hello,

for android in expo-blur we use:

which recently released a new version V3. This adds new performant way for android API 12+ (API 31).
However, the API of it has changed a bit. We now need to wrap the content we want to blur with a <BlurTarget> view:

  <eightbitlab.com.blurview.BlurView
      android:id="@+id/blurView"
      android:layout_width="match_parent"
      android:layout_height="wrap_content"
      app:blurOverlayColor="@color/colorOverlay">
    
       <!--Any child View here, TabLayout for example. This View will NOT be blurred -->
    
    </eightbitlab.com.blurview.BlurView>

    <!--This is the content to be blurred by the BlurView. 
    It will render normally, and BlurView will use its snapshot for blurring-->
    <eightbitlab.com.blurview.BlurTarget
        android:id="@+id/target"
        android:layout_width="match_parent"
        android:layout_height="match_parent">
        
        <!--Your main content here-->

    </eightbitlab.com.blurview.BlurTarget>

I want to discuss if expo has any plans to change over to that new version / would accept community PRs?

There is one very important aspect to why I think this API is better: I just created a PR that fixes issues with expo-blur when using react-native-screens. The problem is that we need to provide a root from where the blur should start. And right now we pick by default the very app root.

So my improved API proposal would be to:

  • also have an accompanying <BlurTarget> component, that is optional to not break the current API
  • Probably something like <BlurTarget id="1"/> .. <BlurView targetId="1" />
  • When using <BlurTarget> we can pick BlurTarget as root

I am not sure about how nice <BlurTarget> would play though with the iOS api? I think it's not needed there, right ? (haven't had time to look into it). Would that be fine to be an android only Component? We could explain that users should use that to get much better performance on Android 12+

You must be logged in to vote

Replies: 2 comments · 1 reply

Comment options

@hannojg
Hi!
We are definitely open to PR's if you are down on implementing the new API support.
I think we should keep the current implementation working as is - so we don't introduce breaking changes - by default we don't blur on Android for performance reasons. If someone want's to blur on Android they will have to wrap the content with a . I guess that on iOS the can be just a regular view.
We would also probably add support for the animation notification methods from the new API

If the new API works well and people are happy with it we would consider to making it a default in a future version 🤔

Let me know if you want to move forward with implementation. If you don't have time for that I'll add it to my todo list 😄

You must be logged in to vote
1 reply
@hannojg
Comment options

While I would love to contribute that change realistically I probably don't find the time to do it - so I'd appreciate if you want to tackle it! 😊
Feel free to ping me on any PRs, definitely looking forward to that change, as I think this will help with performance on android even more!

Comment options

Hello,

for android in expo-blur we use:

which recently released a new version V3. This adds new performant way for android API 12+ (API 31). However, the API of it has changed a bit. We now need to wrap the content we want to blur with a <BlurTarget> view:

  <eightbitlab.com.blurview.BlurView
      android:id="@+id/blurView"
      android:layout_width="match_parent"
      android:layout_height="wrap_content"
      app:blurOverlayColor="@color/colorOverlay">
    
       <!--Any child View here, TabLayout for example. This View will NOT be blurred -->
    
    </eightbitlab.com.blurview.BlurView>

    <!--This is the content to be blurred by the BlurView. 
    It will render normally, and BlurView will use its snapshot for blurring-->
    <eightbitlab.com.blurview.BlurTarget
        android:id="@+id/target"
        android:layout_width="match_parent"
        android:layout_height="match_parent">
        
        <!--Your main content here-->

    </eightbitlab.com.blurview.BlurTarget>

I want to discuss if expo has any plans to change over to that new version / would accept community PRs?

There is one very important aspect to why I think this API is better: I just created a PR that fixes issues with expo-blur when using react-native-screens. The problem is that we need to provide a root from where the blur should start. And right now we pick by default the very app root.

So my improved API proposal would be to:

  • also have an accompanying <BlurTarget> component, that is optional to not break the current API
  • Probably something like <BlurTarget id="1"/> .. <BlurView targetId="1" />
  • When using <BlurTarget> we can pick BlurTarget as root

I am not sure about how nice <BlurTarget> would play though with the iOS api? I think it's not needed there, right ? (haven't had time to look into it). Would that be fine to be an android only Component? We could explain that users should use that to get much better performance on Android 12+

Hey guys, I was looking for ways to update my own BlurView library and came across this discussion. @hannojg suggested this idea of ​​creating a BlurTarget component with an id property to identify it to BlurView. I found this idea interesting and applied it to my library, and it worked!

I will merge the change into my library as soon as I have time, I will take the opportunity to mention this discussions there, maybe it can help you in a future implementation.

Thank you!

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
3 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.