Hello, friends and readers, as we discussed in our intro of season 2. We will do knowledge sharing with Constraint Layout 2.0 APIs. In this part, I am going to talk with you about Barrier API. These APIs added in Constraint Layout 1.1.
Note: For this tutorial, I am using Android Studio 3.5 beta. All code examples in this part are available on Github.
What is a Barrier API:
“A Barrier references multiple widgets as input, and creates a virtual guideline based on the most extreme widget on the specified side.”
I am not sure how many readers figure it out what is this definition. But now we will see the practical implementation of this definition.
Now we have two buttons, as shown in the above image. Both are of different sizes.
From our definition. “A Barrier references multiple widgets as input.” So we will use these two buttons for the Barrier input. Its time to implement Barrier. We can implement this by using UI editor or by writing XML code. I will show you both ways.
In the above image, we are adding Barrier by using UI editor. Only do the right click, and you can see all the above options.
In the above image, I added a Barrier in XML. As you can see, the UI editor is showing us an error on Barrier. It’s time to resolve this error.
<androidx.constraintlayout.widget.Barrier android:layout_width="wrap_content" android:layout_height="wrap_content" />
In the above image, we fixed the error by setting the value of one new field app:barriedDirection=” left” but if you do a focus on design or blueprint mode. We are not able to see any difference or any new UI component.
From our remaining definition “and creates a virtual guideline based on the most extreme widget on the specified side.”
In the above fix, we can see a specific side of our definition is in practical code. In Barrier API, we can use directions left, start, end, bottom, top, right.
<androidx.constraintlayout.widget.Barrier
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:barrierDirection="left"
/>
In the above image, now we added one new field app:constraint_referenced_ids=” button, button2″ and after that, we can see a vertical line on the UI editor. In this field, we need to give all views Ids with separated commas which we want to be a part of the Barrier.
From our remaining definition “and creates a virtual guideline based on the most extreme widget on the specified side.”
As we can see, now we have a Virtual guideline based on the most extreme widget. In our case, Guideline attached with the long width button, which is a most extreme widget in perspective of barrier direction left.
So now we know if you want to use Barrier in your code, you need to know about only two fields, app:barriedDirection and app:constraint_referenced_ids.
<androidx.constraintlayout.widget.Barrier
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:barrierDirection="left"
app:constraint_referenced_ids="button,button2"
/>
Next, we need to clear a little bit more ambiguity about the extreme widget. So for that, I am going to show you one gif. I hope that will remove all ambiguity.
In the above image, when gif started, our long width button is our extreme widget according to the left barrier direction, then I move the other button and you can see when that button cross the long width button, barrier automatically jump on the right side with a small width button because now small width button is our extreme widget.
Now maybe you are confused about the usage of this API. But now, I am expecting you know how to use this API. So it’s time to see some real world scenarios where we can use this API. One hint about where we can use this API, anywhere I want to save my widgets from overlapping :).
Before going to the real world scenarios, we have one more API in Constraint Layout, which may confuse with Barrier, and that is a Guideline API.
Comparison between Guideline and Barrier API:
Guideline API is also a virtual line only the difference is, in case of guideline that is a static virtual line, and we always manage our widgets according to that guideline. That will never push due to any widget instead widget make their constraint around this guideline. For example, I want to create two columns of the text view, and we want the first column will take 40% width and second will take 60% width of the screen. In this case, we can use guideline.
In the above image, we can see the Guideline is showing at .4%. Which means 40% of the screen, and after that, I constrained the first column text view on the left of the Guideline and second column text view with right of the Guideline. Now you will run this code on any screen or at any rotation you will always get the same effect. I hope that clears the confusion between the Guideline and Barrier API.
Scenarios in which we can use Barrier API:
There are many scenarios in which we can use this API, but here I am going to share with you two scenarios.
First Scenario:
This scenario, I never faced in real-world, but after giving the example of Guideline, I can see a one good use case of Barrier API. So take the same example, we have two columns as shown above, and we have a button below of these text views. Which will do compare the text between these two text views as shown below.
Next, I am going to add some more text in the second column, as shown in the below image.
Everything looks nice because my compare button top constraint is attached to the second column. Now, I am going to add a more text in column one as shown in the below image.
Oh no. We can see in the above image. Our button and first column overlapped. One solution is, I will change button top constraint with the first column text view but, we don’t know when which column has more text. Now in this scenario, Barrier API will help us. I can see the definition of Barrier API in this scenario.
“A Barrier references multiple widgets as input, and creates a virtual guideline based on the most extreme widget on the specified side.”
. multiple widgets ( column one, column two text views)
. specific side ( bottom )
. extreme widget ( some time column first and some time column second will be an extreme widget)
In the above image, as we can see, everything is working correctly. I added a barrier with direction bottom, references ids first column and second column. Next, I changed the compare button top constrained with the Barrier.
.... <Button ... android:text="Compare" app:layout_constraintTop_toTopOf="@+id/barrier" /> <androidx.constraintlayout.widget.Barrier android:id="@+id/barrier" android:layout_width="wrap_content" android:layout_height="wrap_content" app:barrierDirection="bottom" app:constraint_referenced_ids="textView,textView2" />
Now, it’s time to show you the impact of the Barrier in our current scenario.
As you can see in the above image when column first expanded the button pushed to the bottom of the screen due to the direction of Barrier and in this case, our extreme widget is column first. After that we have more text in column second, now again button is pushed and now column second is our extreme widget.
Second scenario:
In this scenario, I have one image view and one text view. We want both views always center with each other without the size issue, as shown below:
I think you guys already know, how I achieved this but for someone who is new or don’t know I am going to show you the constraints as shown below:
Simple and looks nice. Now, I am going to add some new text, and we will see this implementation is proper or not.
Looks great, its time to add some more text and then we will review.
Ah. As we can see in the above image. There is some problem. Our constraints are working, but our text view now overlapped with the screen top edge. If I implement this strategy vice versa, in that case again, our Image view will overlap with screen top edge. Note one thing in this scenario. This time views are not overlapped with each other. Instead, they overlapped with screen edge, but again, Barrier API can help us to solve this problem.
As you can see in the above image, I added a Barrier with bottom direction and image view, text view as reference ids. Then Image view and text view both are top constraints with the parent and bottom constraints with the barrier. Only I added a padding-bottom value to both views for space consistency.
<androidx.constraintlayout.widget.ConstraintLayout
.....
>
<ImageView
android:id="@+id/imageView"
android:paddingBottom="16dp"
.....
app:layout_constraintBottom_toTopOf="@+id/barrier3"
app:layout_constraintTop_toTopOf="parent"
/>
<TextView
android:id="@+id/textView3"
android:paddingBottom="16dp"
android:text="This is the text view."
.....
app:layout_constraintBottom_toTopOf="@+id/barrier3"
app:layout_constraintTop_toTopOf="parent" />
<androidx.constraintlayout.widget.Barrier
android:id="@+id/barrier3"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
app:barrierDirection="bottom"
app:constraint_referenced_ids="imageView,textView3" />
</androidx.constraintlayout.widget.ConstraintLayout>
Now, it’s time to test our new implementation.
For now, our current implementation looks nice as shown in above image. Now, it’s time add more text.
In above both gifs, we can see our design with Barrier API is working 100% according to our requirement.
Cheat or Observation about when we can use Barrier API:
- When views overlapped with each other.
- When views overlapped with screen edge.
- When we are not sure about data length, but we want different views should take care of there constraints according to each other.
- When an app is a multi-language, and some strings are really long in a specific language.
Conclusion:
In this part, first, we tried to learn about the Barrier API and what are the required fields which we should know before working with Barrier API. Then we made the comparison of Barrier API with Guideline API. After that, we try some different real-world scenarios where we should use Barrier API.
I hope you guys enjoyed this part.
by 