Monday , November 29 2021

Android View – Layout / ViewGroup and Namespaces in Android Studio

Android View – Layout / ViewGroup and Namespaces in Android Studio – Whatever you see on the User Screen, it is called User Interface (UI) and the activity is responsible for setting which User Interface will appear in front of the user.

Android View – Layout / ViewGroup and Namespaces in Android Studio

In any Android App, the User Interface is basically made up of two sub-components, known as Views and Layouts or ViewGroups.

Views of User Interface (UI) Elements of an Android App such as Button, Label, Text Box, Radio Button, Checkbox, etc. are called Views that create the User Interface of the Android App, so that the user can interact with that Android App.

While other Container Views that act as Containers to hold these View Elements are called Layouts or ViewGroups, because these Containers actually define the Layout of the User Interface of our Android App by holding multiple UI Views and because A User Interface is a Group of Multiple UI View Elements so these Container Views are also called ViewGroup which represent the Group of Views.

Since Layout is a container for other UI View Elements, they basically specify the pattern of the View Elements appearing on the screen of an Android App, determining that Visually (Height) on different User Interface Elements Screen , Width, Position, etc…).

For example, when using LinearLayout, various User Interface Elements that render under it are stacked vertically (second above or below a UI Element) or Horizontally (second before or after a UI Element), while using RelativeLayout is stacked inside it. The various User Interface Elements to be rendered are Render with reference to their Parent or Sibling UI Element.

<?xml version="1.0" encoding="utf-8"?> <RelativeLayout   xmlns:android=http://schemas.android.com/apk/res/android   xmlns:tools=http://schemas.android.com/tools   android:layout_width="match_parent"   android:layout_height="match_parent"   android:paddingLeft="@dimen/activity_horizontal_margin"   android:paddingRight="@dimen/activity_horizontal_margin"   android:paddingTop="@dimen/activity_vertical_margin"   android:paddingBottom="@dimen/activity_vertical_margin"   tools:context=".MainActivity" >   <TextView    android:text="Hello World!"    android:layout_width="wrap_content"          android:layout_height="wrap_content" /> </RelativeLayout>

The User Interface of Android Application is defined through XML Markups in the same way that we define a Registration Form on a Webpage by the Markup of HTML.

That is, the way a Web Browser’s HTML Parser renders HTML Markups specified as , , etc. in the Element of our HTML Webpage as GUI Controls like Button, TextBox and Label That is, in the same way that the XML Markups we define using the Android Interface of an Android App, the XML Parser of the Android App displays the User Interface Controls on the screen of the Android Device based on those XML Markups. For example whenever we create a new activity based on RelativeLayout, a Layout View is automatically created along with that activity and that Automatically Create View has the following XML Markups by default – The view file to be created is basically an XML file, so like any XML file, it starts with Element as follows:

<?xml version=“1.0” encoding=“utf-8”?>

Which informs the XML Parser of the Android Framework that the Current File is an XML File, which controls the Visual Part of the Android App, the GUI Part.

Also, like any Framework, the Naming Convention of Files in Android Framework also plays an important role. Therefore, the name of this file is related to the name of the activity file being created with it.

For example when an Activity File Create named MainActivity.java is created, the Layout View File to be created with it is activity_main.xml. Similarly if we create another activity named SecondActivity in our Current Android App, then the Layout View File Create with the SecondActivity.java File being created is named activity_second.xml.

However, if we wish, we can also change these names as we wish by not following this Naming Convention of Android Framework, but it is better that we follow the Naming Convention of Android Framework without changing these names.

Android View – Layout / ViewGroup and Namespaces in Android Studio

Because when we follow these Naming Conventions, any IDE we are using for Android Development generates a lot of Android Codes Automatically for us, thereby speeding up our App Development Increases significantly.

Since the Layout and GUI part of the Android App is created by the XML Markup based language, which is the XML Parser Parse of the Android Framework, when we create a new activity, the Create Layout View with it will be specified as specified above.

There are two Elements named RelativeLayout… /> and and as we mentioned earlier, Android App’s User Interface is basically made up of two types of Sub-Components Views and Layout or GroupViews.

Thus, in this Automatically Generated XML Code, Element is a type of Layout or GroupViews, which containerizes multiple View Elements such as as a Group to create an Android App Organizes the User Interface.

In other words, the Layout / GroupViews Element itself is not visible visually, but what the User Interface of the Android App will look like and the various UI Elements (Button, Textbox, Checkbox, Radio Button, Images, etc…) of the User Interface on the screen. Layout / GroupViews Element is decided by the Layout / GroupViews Element itself to decide what will be and how it will appear.

This is why the Element in the above XML Code is enclosed between the Element because the Element is a View Element, which is always containerized under a rough Layout / GroupViews Element And Element is the Default Container Layout of any Android App, under which Screen Positioning (Control of Mobile / Tablet on Screen of each View Element (Button, Textbox, Radio Button, Checkbox, etc…)). Situation) is related to the Screen Positioning of its Parent or Sibling UI Element. Therefore, changing the Screen Position of Parent / Sibling of Current UI Element also has an effect on the Screen Position of Current UI Control.

The Android Framework provides us with a variety of Layout Views, where is the Default Layout View of the Automatically Generated Code by the Android Framework, and we use whatever Layout View for our Android App as per our need, First of all, we need to specify the following two XML Namespaces, which inform the View Parser of Android how to render the GUI of the Android App on a Mobile / Tablet Screen:

xmlns: android = http: //schemas.android.com/apk/res/android
xmlns: tools = http: //schemas.android.com/tools

Since when the UI Part of the Android Framework is completely controlled by an XML File, then there are some Descriptions of the various Elements to be Specified in an XML File, based on which the XML Parser is to Parsing that XML File, ie Runs the XML file and generates the output based on the description. The same description is specified by xmlns Attribute in the name of XML Namespace.

To understand the concept of namespace properly, we take the Analogy of a C / C ++ Program where we know that in a C / C ++ Program File we Include the Header Files for the same, so that it contains Defined Functions, Class, Constants etc. Use in your current C / C ++ program.

For example, in C / C ++, the function named scanf () has been defined (Define) in the Header File named , which is how to accept Input data from the keyboard. Describe to.

Because Google has improved RelativeLayout itself and set its Improved Version as ConstraintLayout as Default for various projects of Android Studio.

But Android Studio gives us the facility that we can convert this Default ConstraintLayout to RelativeLayout again according to our need and for this all we need to do is to replace Highlighted ConstraintLayout Code in RelaxLayout as above in the above XML Code Please do

<?xml version="1.0" encoding="utf-8"?> <android.support.constraint.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" tools:context="com.bccfalna.helloworld.MainActivity"> <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Hello World!" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintLeft_toLeftOf="parent" app:layout_constraintRight_toRightOf="parent" app:layout_constraintTop_toTopOf="parent" /> </android.support.constraint.ConstraintLayout>

As soon as we change ConstraintLayout from RelativeLayout as above, our Layout becomes a Relative Layout.

Although everything we discussed in this section was based on RelativeLayout’s XML Codes, but it does not matter because despite the layout change, whatever discussion we have with Namespace and Prefix, everything is intact and because Now Google recommends ConstraintLayout as the Default Layout for Android Apps, so whenever you create a new Android App, as far as possible, develop it based on ConstraintLayout.

<?xml version="1.0" encoding="utf-8"?> <RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:tools="http://schemas.android.com/tools" android:layout_width="match_parent" android:layout_height="match_parent" tools:context="com.bccfalna.helloworld.MainActivity"> <TextView android:layout_width="wrap_content" android:layout_height="wrap_content" android:text="Hello World!" app:layout_constraintBottom_toBottomOf="parent" app:layout_constraintLeft_toLeftOf="parent" app:layout_constraintRight_toRightOf="parent" app:layout_constraintTop_toTopOf="parent" /> </ RelativeLayout>

Since Android is not yet a fully-fledged platform but is constantly evolving as per requirement, Google will periodically change various types of Defaults of Android Studio in future also. So now ConstraintLayout will always be Android Studio’s Default Layout for ever, it is not good to assume that instead Google may also improve this ConstraintLayout by defining another new type of Layout that will be available in future Android Studio Becomes the Default Layout of.

So whenever Google gives a new recommendation, always following the same is the only way to keep your Android App useful and supported for Maximum Android Devices for a long term.

Read Also – Event Handler Implementation using Member Class in Android Studio

About dmtechnolab

Check Also

Simplified Coding

Android Espresso Tutorial – Testing Fragment in Isolation – Android Coding by DMTechnolab

Welcome to another tutorial in the Android test series. And this post is called Android …

Leave a Reply

Your email address will not be published. Required fields are marked *