Android views inside view

Centering views in Android layouts

Apr 13, 2017 · 2 min read

I am an Android developer for a couple of years now, and sometimes I’m still confused how to center a View inside a ViewGroup. To get rid of the tangle for once and for all, I will sum up all the possibilities for centering your views, considering the layouts I use most: LinearLayout, RelativeLayout, FrameLayout and of course the new ConstraintLayout.

LinearLayout

The LinearLayout has a gravity property which supports centering it’s child views. You can specify the gravity as center_horizontal, center_vertical and center (which centers both horizontally and vertically).

On the chil d views of the LinearLayout you can specify the layout_gravity property, which also supports center_horizontal, center_vertical and center. So it’s up to you if you want to center all children (using gravity on the LinearLayout) or you want to center specific children (using layout_gravity on the child views).

RelativeLayout

The RelativeLayout has the same gravity property as the LinearLayout. However, centering child views inside a RelativeLayout works differently. Instead of layout_gravity you have to use the properties layout_centerHorizontal, layout_centerVertical and layout_centerInParent (which centers both horizontally and vertically).

FrameLayout

The FrameLayout has no gravity property. However, you can specify the layout_gravity of a child view inside a FrameLayout.

ConstraintLayout

Centering within this ViewGroup is completely different, because you can only specify contraints. For centering a TextView within a ContraintLayout horizontally you could do the following:

This sets two equal constraints from the left border of the TextView to the left of the ConstraintLayout and from the right border of the TextView to the right of the ConstraintLayout. You could do the exact same thing with top and bottom for centering vertically. As a bonus you can specify a constraint bias to shift the center of gravity a bit more to one side or the other.

ConstraintLayout chains

The ConstraintLayout doesn’t have a gravity property to center all children. However, you can use a chain to center multiple views together. You create a chain by cross referencing constraints bidirectional. For example:

This vertically centers both TextViews with equal distance between the parent ConstraintLayout and the TextViews. You can specify different styles of chains though: spread (even distribution), spread_inside (first and last view fixed to start and end of chain) and packed (all views packed together).

I hope this post clears up some of the confusion. Let me know if I forgot important ways of centering views within viewgroups.

Источник

RecyclerView inside Fragment with Android Studio

In developing an Android application, there are two approaches. Native and Hybrid. Native applications developed for a specific platform, meanwhile hybrid applications developed for multiple platforms on a single base. In native, Android applications are written in Java-based, and iOS are written in Swift. My Software Development Project was requested by our client to use Native apps to develop our project. So, we use both Kotlin and Swift language for our project.

“The secret of getting ahead is getting started” — Mark Twain

My job during this development is developing the Android one. We use Android Studio as our IDE. It is an official IDE by Google for developing Android applications. Well, this is my last article related to my Software Development Project course. This time, I want to share my experience using Android Studio and Kotlin for the first time, especially in making a Recycler View, and to be more complicated, it is also inside a Fragment.

First thing first, please make sure you’ve already prepared this:

Understand the Concept

Before we start, you need to know what is exactly RecyclerView, CardView, and Fragment. For a more complete explanation, please see Android Developers.

RecyclerView

Sometimes in an application, we want to display a large set of data. Here we certainly need a view that can handle it. Several different components work together to display the data. All container for the User Interface is a RecyclerView object that you add to the layout. LayoutManager such as LinearLayoutManager or GridLayourManager could be your layout manager to fill the RecyclerView.

CardView

Package view of Material Design which commonly used for wrapping data, package data in several views. This view has a drop shadow and a corner radius. This is a subclass of FrameLayout.

Fragment

A fragment represents a portion of User Interface in a FragmentActivity. Multiple fragments could be combined in a single activity and reuse a fragment in multiple activities. We implement this fragment because at the end we want to make this recycler view page could be slide to another page. Here’s the illustration of it.

Let’s jump to the implementation

Here I want to make a RecyclerView consist of CardView, which is inside a Fragment.

Prepare the Android Studio

1. Create a New Project on Android Studio. Choose Empty Activity.

2. Add your file name, then click Finish

Add the Dependencies

Adding the dependencies for RecyclerView and CardView on your build.gradle (app stage).

Then do the Sync Project with Gradle Files

Add RecyclerView to layout

Next, add RecyclerView code on your res/layout XML file. Because I want to make it inside a Fragment, which could work with FrameLayout. So, the Root Element is FrameLayout.

1. Right-click the layout folder and go to New > Layout resource file
2. Add your file name
3. Select the Root Element with FrameLayout, then click OK

Create the layout with ConstraintLayout and RecyclerView.

Here’s the layout.

Create a CardView layout

Same as adding RecyclerView to layout, but the Root Element is CardView or androidx.cardview.widget.CardView.

I divided the row inside the CardView with LinearLayout, which is inside a RelativeLayout to makes them responsive. To insert the font and strings to the XML, don’t forget to add the resources first on the values folder. You can see the tutorial on my article about implement design guidelines here.

Here’s the layout.

Create an Adapter for the RecyclerView

On making RecylerView, there is must be an adapter to connect the RecyclerView with the CardView. The views in the list are represented by view holder objects. By extending RecyclerView.ViewHolder, these objects are instances of a class you defined. Each view holder is in charge of showing a single item with a view. This shows a list of questions, each view holder might represent a single question. The RecyclerView creates the same number of view holders as are expected to show the on-screen portion of the dynamic content. As the user scrolls through the list, the RecyclerView takes the off-screen views and rebinds them to the data which is scrolling onto the screen. The view holder objects are managed by an adapter, by extending RecyclerView.Adapter. This adapter created view holders as needed and also binds it to the data.

Here’s my model are a component that will be on the card later, such a code, category, and content. This fragment class will call the layout we’ve made before.

In the upcoming implementation, the data for the components are automatically fetched from the API. This code only shows if the data are input manually from the array.

For the simple implementation, create ViewHolder as an inner class on the RecyclerAdapter class.

DetailPertanyaan is an activity if the card has been clicked. For the supporting method in RecyclerAdapter class, add this code below the ViewHolder class.

onCreateViewHolder() needs to construct a RecyclerView.ViewHolder and set the view to display its contents. It would set the view by inflating the CardView layout.

onBindViewHolder() uses the view holder’s position to determine what the contents should be.

Set the Adapter to RecyclerView on Fragment class

This class will call the layout that consists of the RecyclerView and connect the adapter with the RecyclerView.

onViewCreated() will set the RecyclerAdapter to the RecyclerView layout.

Last but not least, don’t forget to Run your ‘app’ to see the result!

I will not explain more about the further Fragment implementation, you can use TabLayout as the sections pager adapter and ViewPager to make the page could be slide to the next fragment. This tutorial I made only for one fragment. There are so many inspirations and tutorials out there to explore more about this layout. This card also could be clicked and go to another activity, and the tutorials are also available on the internet. Hehe

Closing Statement

On developing my project with Android Kotlin, there are so many lessons that I learned. This is not the only task that I do, there is also another task. I learned a lot about this new framework, I use Android Studio and Kotlin for the first time. I learned it from the basics. Before we start the project, our client gave us a free course in Udemy on Android Fundamentals. You also can learn it here.

When I first succeed in making the sign-in layout, I am feeling very very joyful! My layout for the sign-in page was made on the Design option. It is very easy because you will feel like design a mockup, just drag and choose the details on the Attributes. As time goes by, I easily understand how to make the UI for Android and made the layout on the Text option, so I literally code the layout. I also learn how to make a SwipeRefreshLayout, Onboarding pages, and account page. There are also different obstacles in every task I did. I can increase my ability in every task I did on this project. So, if you want to learn about the native mobile application you could use Kotlin as your programming language and Android Studio for the IDE.

With this article, I officially finished my individual review writings on what has been learned and implemented in developing a project. Thank you for reading all my individual review, I’ll be glad that you read this last sentence. Especially, thank you Mr. Mishbah for grading all these articles 😀

Источник

Use view binding to replace findViewById

New in Android Studio 3.6, view binding gives you the ability to replace findViewById with generated binding objects to simplify code, remove bugs, and avoid all the boilerplate of findViewById .

• Enable view binding in build.gradle (no libraries dependencies)
• View binding generates a binding object for every layout in your module ( activity_awesome.xml → ActivityAwesomeBinding.java )
• Binding object contains one property for every view with an id in the layout — with the correct type and null-safety
• Full support for both the Java programming language and Kotlin

Update build.gradle to enable view binding

You don’t need to include any extra libraries to enable view binding. It’s built into the Android Gradle Plugin starting with the versions shipped in Android Studio 3.6. To enable view binding, configure viewBinding in your module-level build.gradle file.

In Android Studio 4.0, viewBinding has been moved into buildFeatures [release notes] and you should use:

Once enabled for a project, view binding will generate a binding class for all of your layouts automatically. You don’t have to make changes to your XML — it’ll automatically work with your existing layouts.

View binding works with your existing XML, and will generate a binding object for each layout in a module.

You can use the binding class whenever you inflate layouts such as Fragment , Activity , or even a RecyclerView Adapter (or ViewHolder ).

Use view binding in an Activity

If you have a layout called activity_awesome.xml , which contains a button and two text views, view binding generates a small class called ActivityAwesomeBinding that contains a property for every view with an ID in the layout.

You don’t have to call findViewById when using view binding — instead just use the properties provided to reference any view in the layout with an id.

The root element of the layout is always stored in a property called root which is generated automatically for you. In an Activity ’s onCreate method you pass root to setContentView to tell the Activity to use the layout from the binding object.

Easy Mistake: Calling setContentView(…) with the layout resource id instead of the inflated binding object is an easy mistake to make. This causes the layout to be inflated twice and listeners to be installed on the wrong layout object.

Solution: When using view binding in an Activity , you should always pass the layout from the binding object with setContentView(binding.root) .

Safe code using binding objects

findViewById is the source of many user-facing bugs in Android. It’s easy to pass an id that’s not in the current layout — producing null and a crash. And, since it doesn’t have any type-safety built in it’s easy to ship code that calls findViewById

(R.id.image) . View binding replaces findViewById with a concise, safe alternative.

View bindings are…

• Type-safe because properties are always correctly typed based on the views in the layout. So if you put a TextView in the layout, view binding will expose a TextView property.
• Null-safe for layouts defined in multiple configurations. View binding will detect if a view is only present in some configurations and create a @Nullable property.

And since the generated binding classes are regular Java classes with Kotlin-friendly annotations, you can use view binding from both the Java programming language and Kotlin.

What code does it generate?

View binding generates a Java class that replaces the need for findViewById in your code. It will generate one binding object for every XML layout in your module while mapping names so activity_awesome.xml maps to ActivityAwesomeBinding.java .

When editing an XML layout in Android Studio, code generation will be optimized to only update the binding object related to that XML file, and it will do so in memory to make things fast. This means that changes to the binding object are available immediately in the editor and you don’t have to wait for a full rebuild.

Android Studio is optimized to update the binding objects immediately when editing XML layouts.

Let’s step through the generated code for the example XML layout from earlier in this post to learn what view binding generates.

View binding will generate one correctly-typed property for each view with a specified id . It will also generate a property called rootView that’s exposed via a getter getRoot . View binding doesn’t do any logic– it just exposes your views in a binding object so you can wire them up without error-prone calls to findViewById . This keeps the generated file simple (and avoids slowing down builds).

If you’re using Kotlin, this class is optimized for interoperability. Since all properties are annotated with @Nullable or @NonNull Kotlin knows how to expose them as null-safe types. To learn more about interop between the languages, check out the documentation for calling Java from Kotlin.

In ActivityAwesomeBinding.java , view binding generates a public inflate method. The one argument version passes null as the parent view and doesn’t attach to parent. View binding also exposes a three argument version of inflate that lets you pass the parent and attachToParent parameters when needed.

The call to bind is where the magic happens. It will take the inflated layout and bind all of the properties, with some error checking added to generate readable error messages.

The bind method is the most complex code in the generated binding object, with a call to findViewById for each view to bind. And here you can see the magic happen – since the compiler can check the types and potential nullability of each property directly from the XML layouts it can safely call findViewById .

Note, the actual generated code for the bind method is longer and uses a labeled break to optimize bytecode. Check out this post by Jake Wharton to learn more about the optimizations applied.

On each binding class, view binding exposes three public static functions to create a binding an object, here’s a quick guide for when to use each:

• inflate(inflater) – Use this in an Activity onCreate where there is no parent view to pass to the binding object.
• inflate(inflater, parent, attachToParent) – Use this in a Fragment or a RecyclerView Adapter (or ViewHolder ) where you need to pass the parent ViewGroup to the binding object.
• bind(rootView) – Use this when you’ve already inflated the view and you just want to use view binding to avoid findViewById . This is useful for fitting view binding into your existing infrastructure and when refactoring code to use ViewBinding .

What about included layouts

One binding object will be generated for each layout.xml in a module. This is true even when another layout s this this layout.

In the case of included layouts, view binding will create a reference to the included layout’s binding object.

Note that the tag has an id: android:id=»@+id/includes» . This is required for view binding to generate a property (just like a normal view).

Include tags must have an id to generate a binding property.

View binding will generate a reference to the IncludedButtonsBinding object in ActivityAwesomeBinding .

Using view binding and data binding

View binding is only a replacement for findViewById . If you also want to automatically bind views in XML you can use the data binding library. Both libraries can be applied to the same module and they’ll work together.

When both are enabled, layouts that use a tag will use data binding to generate binding objects. All other layouts will use view binding to generate binding objects.

You can use data binding and view binding in the same module.

We developed view binding in addition to data binding because many developers provided feedback that they wanted a lighter weight solution to replace findViewById without the rest of the data binding library – and view binding provides that solution.

View binding and Kotlin synthetics or ButterKnife

One of the most common questions asked about view binding is, “Should I use view binding instead of Kotlin synthetics or ButterKnife?” Both of these libraries are used successfully by many apps and solve the same problem.

For most apps we recommend trying out view binding instead of these libraries because view binding provides safer, more concise view lookup.

While ButterKnife validates nullable/non-null at runtime, the compiler does not check that you’ve correctly matched what’s in your layouts

We recommend trying out view binding for safe, concise, view lookup.

Learn more

To learn more about view binding check out the official documentation.

And we’d love to hear your experiences with #ViewBinding library on twitter!

Источник