Android View, Layout / ViewGroup and Namespaces

Android View – User Screen पर जो कुछ भी देखता है, उसे ही User Interface (UI) कहते हैं और User के सामने कौनसा User Interface दिखाई देगा, इसे Set करने की जिम्‍मेदारी Activity की होती है।

किसी भी Android App में User Interface मूल रूप से दो Sub-Components के बने होते हैं, जिन्‍हें Views व Layouts या ViewGroups के नाम से जाना जाता है।

किसी Android App के User Interface (UI) Elements जैसे कि Button, Label, Text Box, Radio Button, Checkbox आदि को Views कहते हैं जो कि Android App का User Interface Create करते हैं, ताकि User उस Android App से Interact कर सके।

जबकि इन View Elements को Hold करने के लिए Container की तरह काम करने वाले अन्‍य Container Views को Layouts अथवा ViewGroups कहते हैं, क्‍योंकि ये Containers वास्‍तव में Multiple UI Views को Hold करते हुए हमारे Android App के User Interface का Layout Define करते हैं और क्‍योंकि एक User Interface, Multiple UI View Elements का Group होता है इसलिए इन Container Views को ViewGroup भी कहा जाता है जो कि Group of Views को Represent करते हैं।

चूंकि Layout, अन्‍य UI View Elements का Container होते हैं, इसलिए ये मूल रूप से किसी Android App के Screen पर दिखाई देने वाले View Elements के Pattern को Specify करते हुए इस बात को तय करते हैं कि विभिन्‍न User Interface Elements Screen पर Visually (Height, Width, Position, etc…) किस तरह से दिखाई देंगे।

उदाहरण के लिए LinearLayout Use करने पर इसके अन्‍दर Render होने वाले विभिन्‍न User Interface Elements Vertically (एक UI Element के ऊपर या नीचे दूसरा) अथवा Horizontally (एक UI Element के पहले या बाद में दूसरा) Stack होते हैं जबकि RelativeLayout Use करने पर इसके अन्‍दर Render होने वाले विभिन्‍न User Interface Elements अपने Parent अथवा Sibling UI Element के संदर्भ में Render होते हैं।

Android Application के User Interface को XML Markups के माध्‍यम से ठीक उसी तरह से Define किया जाता है, जिस तरह से हम किसी Webpage पर किसी Registration Form को HTML के <form> Markup द्वारा Define करते हैं।

यानी जिस तरह से एक Web Browser का HTML Parser हमारे HTML Webpage के <form> Element में Specify किए गए <button>, <input>, <label> आदि HTML Markups को Button, TextBox व Label जैसे GUI Controls के रूप में Render करता है, ठीक उसी तरह से एक Android App के User Interface को हम जिन XML Markups का प्रयोग करते हुए Define करते हैं, Android App का XML Parser उन XML Markups के आधार पर Android Device की Screen पर User Interface Controls को Display कर देता है।

उदाहरण के लिए जब भी हम RelativeLayout पर आधारित कोई नई Activity Create करते हैं, उस Activity के साथ ही Automatically एक Layout View भी Create हो जाता है और उस Automatically Create होने वाले View में Default रूप से निम्‍न XML Markups होते हैं-

<?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>

Create होने वाली View File मूलत: एक XML File होती है इसलिए किसी भी XML File की तरह ही इसकी शुरूआत भी निम्‍नानुसार  <?xml /> Element से होती है:

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

जो Android Framework के XML Parser को इस बात की जानकारी देता है कि Current File एक XML File है, जो कि Android App के Visual Part यानी GUI Part को Control करता है।

साथ ही किसी भी Framework की तरह ही Android Framework में भी Files का Naming Convention महत्‍वूपर्ण Role Play करता है। इसलिए इस File का नाम इसके साथ Create होने वाली Activity File के नाम से सम्‍बंधित होता है।

उदाहरण के लिए जब MainActivity.java नाम का Activity File Create होता है, तो उसके साथ Create होने वाले Layout View File का नाम activity_main.xml होता है। इसी तरह से यदि हम हमारे Current Android App में SecondActivity नाम की एक और Activity Create करें, तो Create होने वाली SecondActivity.java File के साथ जो Layout View File Create होता है, उसका नाम activity_second.xml होता है।

हालांकि यदि हम चाहें तो Android Framework के इस Naming Convention को Follow न करते हुए इन नामों को अपनी इच्‍छानुसार बदल भी सकते हैं, लेकिन बेहतर यही होता है कि हम इन नामों को न बदलते हुए Android Framework के Naming Convention को ज्‍यों का त्‍यों Follow करें क्‍योंकि जब हम इन Naming Conventions को ज्‍यों का त्‍यों Follow करते हैं, तो Android Development के लिए हम जिस किसी भी IDE को Use कर रहे होते हैं, वह IDE हमारे लिए काफी Android Codes Automatically Generate कर देता है, जिससे हमारे App Development की Speed काफी बढ़ जाती है।

चूंकि Android App का Layout व GUI Part, XML Markup आधारित Language द्वारा Create किया जाता है, जिसे Android Framework का  XML Parser Parse करता है, इसलिए हम जब कोई नया Activity Create करते हैं, उसके साथ Create होने वाले Layout View में उपरोक्‍तानुसार Specified <RelativeLayout … /> व <TextView … /> नाम के दो Elements होते हैं और जैसाकि हमने पहले बताया कि Android App के User Interface मूलत: दो प्रकार के Sub-Components Views व Layout या GroupViews के बने होते हैं।

अत: इस Automatically Generate होने वाले XML Code में <RelativeLayout … /> Element एक प्रकार का Layout अथवा GroupViews है, जो कि <TextView … /> जैसे कई View Elements को एक Group के रूप में Contain करते हुए Create होने वाले Android App के User Interface को Organize करता है।

अन्‍य शब्‍दों में कहें तो Layout/GroupViews Element स्‍वयं Visually दिखाई नहीं देता, लेकिन Android App का User Interface कैसा दिखाई देगा और User Interface के विभिन्‍न UI Elements (Button, Textbox, Checkbox, Radio Button, Images, etc…) Screen पर कहां Place होंगे और कैसे दिखाई देंगे, इस बात को तय करके User Interface को Organize करने का काम Layout/GroupViews Element द्वारा ही तय होता है।

इसी वजह से उपरोक्‍त XML Code में <TextView … /> Element को <RelativeLayout … /> Element के बीच Enclose किया गया है क्‍योंकि <TextView … /> Element एक View Element है, जिसे हमेंशा किसी न किसी Layout/GroupViews Element के अन्‍दर Contained होना होता है और <RelativeLayout … /> Element किसी भी Android App का Default Container Layout होता है, जिसके अन्‍तर्गत प्रत्‍येक View Element (Button, Textbox, Radio Button, Checkbox, etc…) की Screen Positioning (Mobile/Tablet की Screen पर Control Situation), उसके Parent या Sibling UI Element की Screen Positioning से सम्‍बंधित होती है। इसलिए Current UI Element के Parent/Sibling की Screen Position Change करने पर उसका प्रभाव Current UI Control की Screen Position पर भी पड़ता है।

Android Framework हमें कई प्रकार के Layout Views Provide करता है, जहां <RelativeLayout … />, Android Framework द्वारा Automatically Generated Code का Default Layout View होता है और हम हमारे Android App के लिए अपनी जरूरत के अनुसार चाहे जो भी Layout View Use करें, सभी में सबसे पहले हमें निम्‍नानुसार दो XML Namespaces को Specify करना जरूरी होता है, जो कि Android के View Parser को इस बात की जानकारी देते हैं, कि उन्‍हें किसी Mobile/Tablet Screen पर Android App के GUI को किस प्रकार से Render करना है:

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

चूंकि जब Android Framework का UI Part पूरी तरह से XML File द्वारा Control होता है, तब एक XML File में Specify किए जाने वाले विभिन्‍न Elements की कुछ न कुछ Descriptions होती हैं, जिनके आधार पर XML Parser उस XML File की Parsing करना है, यानी XML File को Run करता है और Description के आधार पर ही Output Generate करता है। इसी Description को XML Namespace के नाम से xmlns Attribute द्वारा Specify किया जाता है।

Namespace के Concept को ठीक से समझने के लिए हम एक C/C++ Program की Analogy लेते हैं जहां हम जानते हैं कि किसी C/C++ Program File में हम Header Files को इसीलिए Include करते हैं, ताकि उसमें Defined Functions, Class, Constants आदि को अपने Current C/C++ Program में Use कर सकें।

उदाहरण के लिए C/C++ में <stdio.h> नाम की Header File में scanf() नाम के Function को परिभाषित (Define) किया गया है, जो कि Keyboard से अपने वाले Input Data को किस तरह से Accept करना है, इस बात को Describe करता है।

इसलिए जब तक हम हमारे C/C++ Program में <stdio.h> Header File को Include न करें, तब तक हम हमारे Program में Keyboard से Input नहीं ले सकते क्‍योंकि Input कैसे लेना है, इस बात की जानकारी केवल scanf() Function के अन्‍तर्गत Specify किया गया है और ये Specification, <stdio.h> नाम की Header File में लिखा गया है।

परिणामस्‍वरूप जब हम ऐसे C/C++ Program को Compile करते हैं, जिसमें User Input Accept करने के लिए scanf() Function को तो Use किया गया है, लेकिन <stdio.h> Header File को Include नहीं किया गया है, तो Compilation के दौरान C/C++ का Compiler, Program में Use किए गए scanf() Function का Description खोजता है, ताकि उसे पता चल सके कि उस इस Function के माध्‍यम से क्‍या और कैसे करना है।

किन क्‍योंकि हमने हमारे C/C++ Program में <stdio.h> नाम की Header File को Include ही नहीं किया है, इसलिए Compiler को पता ही नहीं चलता कि scanf() नाम के Code को Execute कैसे करना है, फलस्‍वरूप Program Compile नहीं होता और Compiler हमें “Missing Symbol : scanf” का Error देता है।

ठीक इसी तरह से उपरोक्‍त Code में xmlns Attribute के माध्‍यम से हम Android Framework के XML Parser को बताते हैं कि Current XML File में लिखे गए XML Codes को कैसे Parse करना है।

अत: यदि हम xmlns Attribute को Specify न करें, और <TextView … /> UI Element को Specify करते हुए Activity Screen पर कोई Text Display करना चाहें, तो उस स्थिति में Android Platform के XML Parser को पता ही नहीं होगा कि <TextView … /> Element मिलने पर उसे करना क्‍या है, क्‍योंकि <TextView … /> XML Code मिलने पर उसे एक Text Message को Display करना है, इस बात का Description उस URI में है, जिसे xmlns Attribute में Value के रूप में Set किया जाता है। इसलिए जब हम निम्‍नानुसार xmlns Specify करते हैं:

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

तो हम Android Platform के Layout/View XML Parser को ये बता रहे होते हैं कि Screen पर दिखाई देने वाले विभिन्‍न Visual User Interface Controls को Mobile/Tablet Screen पर कहां और कैसे Render करना है।

क्‍योंकि Layout/View XML File की Parsing के दौरान <TextView … /> XML Code मिलने पर एक Label Control बनना चाहिए और <Button … /> XML Code मिलने पर Screen पर एक Button दिखाई देना चाहिए, XML Parser को इस बात का Description, xmlns Attribute में Value के रूप में Specify किए गए URI द्वारा ही चलता है और हम अपने View (User Interface) को Create करने से सम्‍बंधित जितने भी Symbols (<RelativeLayout … />, <TextView … />, <Button … />, आदि) Use करते हैं, उन सभी का Description इसी URI से सम्‍बंधित होता है।

यदि बिल्‍कुल ही सरल शब्‍दों में कहें, तो ये xmlns Attribute में Value के रूप में Specify किए गए जाने वाले ये URIs एक प्रकार से C/C++ की Header Files के समान ही होते हैं अत: यदि xmlns में इन्‍हें Specify नहीं किया, तो User Interface नहीं बनेगा, ठीक उसी तरह से, जिस तरह से यदि <stdio.h> Header File को अपने C/C++ Program में Include नहीं किया, तो Keyboard से Input Accept नहीं होगा।

XML Specification हमें एक ही XML File में एक से ज्‍यादा URI से सम्‍बंधित Symbols यानी XML Elements को एक ही XML File में ठीक उसी तरह से Use करने की सुविधा Provide करता है, जिस तरह से हम किसी C/C++ Program में एक से ज्‍यादा Header Files को Include करते हुए उनकी Functionalities को समान Program File में प्राप्‍त कर लेते हैं। लेकिन किसी XML File में एक से ज्‍यादा URI से सम्‍बंधित Symbols को Use करने के लिए हमें xmlns के Prefix Concept का प्रयोग करना पडता है।

उदाहरण के लिए उपरोक्‍त XML Code के xmlns:android Attribute में xmlns Namespace है जबकि Colon के बाद Specify किया गया android शब्‍द Prefix है। इसी तरह से xmlns:tools Attribute में xmlns Namespace है जबकि Colon के बाद Specify किया गया tools शब्‍द Prefix है।

इस प्रकार से Prefix युक्‍त URI Specify करके हम दो अलग Namespaces से सम्‍बंधित Descriptions पर आधारित Symbols (XML Codes or XML Elements) को समान XML File में Use कर सकते हैं और दोनों Namespaces से सम्‍बंधित Symbols द्वारा Provide की जाने वाली Functionalities को समान XML File में प्राप्‍त कर सकते हैं।

Prefix युक्‍त Namespaces को Specify करने का एक फायदा ये भी होता है कि यदि दोनों Namespaces में समान Symbol (XML Element) को Define किया गया हो, तब भी दोनों के बीच Name Conflict नहीं होता।

उदाहरण के लिए यदि xml:android Attribute से Associated URI की Definition में <red> नाम का एक Symbol यानी XML Element है, जिसे Use करने पर XML Parser एक Red Color की Line Draw करता है, जबकि xml:tools Attribute से Associated URI की Definition में भी <red> नाम का एक Symbol यानी XML Element है, लेकिन इसे Use करने पर XML Parser एक Error Message Display करता है।

हम समझ सकते हैं कि दोनों ही URI Definitions में <red> Symbol Exist है, लेकिन XML File में जब हम <android:red … /> XML Element Use करते हैं, तो Parsing के बाद Output में एक Red Line Render होता है, जबकि <tools:red … /> XML Element Use करते हैं, तो Parsing के बाद Output में एक Error Message Render होता है और हम इन Prefixes को तभी Use कर सकते हैं, जबकि हमने Prefix युक्‍त Namespaces को Specify किया हो। यदि हमने इन्‍हें Prefixed तरीके से Specify न किया हो, तो उस स्थिति में एक से अधिक Namespaces में समान Symbol होने पर XML Parsing के दौरान Name Conflict होगा।

चूंकि Android Platform व इसका Development Environment दोनों अभी पूरी तरह से Stable नहीं हैं और Google इनमें समय-समय पर उपयुक्‍त Modifications करके Different Defaults Set करता रहता है। इसीलिए Android Studio 2.2 तक जब भी कोई नया Android Project Create करते थे, Default रूप से RelativeLayout आधारित Layout ही Create होता था। लेकिन Android Studio 2.2 के बाद के Versions वाले Android Studio में हम जब भी कोई नया Project Create करते हैं, तो Default Layout के रूप में RelativeLayout के स्‍थान पर अब ConstraintLayout Create होता है जिसका XML Codes निम्‍नानुसार होता है-

<?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>

क्‍योंकि Google ने RelativeLayout को ही और बेहतर करके इसके Improved Version को ConstraintLayout की तरह Android Studio के विभिन्‍न Projects के लिए Default की तरह Set कर दिया है।

लेकिन Android Studio हमें ये सुविधा देता है कि हम इस Default ConstraintLayout को अपनी जरूरत के अनुसार फिर से RelativeLayout में Convert कर सकते हैं और इसके लिए हमें केवल मात्र इतना ही करना है कि हम उपरोक्‍त XML Code में Highlighted ConstraintLayout Code को निम्‍नानुसार RelativeLayout से Replace कर दें-

<?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>

जैसे ही हम उपरोक्‍तानुसार ConstraintLayout को RelativeLayout से Change करते हैं, हमारा Layout एक Relative Layout बन जाता है।

हालांकि इस Section में हमने जो भी Discussion किया वो RelativeLayout के XML Codes पर आधारित था लेकिन इस बात से कोई फर्क नहीं पड़ता क्‍योंकि Layout Change करने के बावजूद हमने Namespace व Prefix से सम्‍बंधित जो भी Discussion किया, वो सबकुछ ज्‍यों का त्‍यों है और क्‍योंकि अब Google, Android Apps के लिए Default Layout के रूप में ConstraintLayout को ही Recommend करता है इसलिए अब आप जब भी कोई नया Android App Create करें, जहां तक सम्‍भव हो, उसे ConstraintLayout के आधार पर ही Develop करें।

चूंकि Android अभी पूरी तरह से वि‍कसित Platform नहीं है बल्कि जरूरत के अनुसार निरंतर विकासशील है इसलिए Google समय-समय पर Android Studio के विभिन्‍न प्रकार के Defaults को भविष्‍य में भी Change करेगा। इसलिए अब ConstraintLayout ही हमेंशा के लिए Android Studio का Default Layout रहेगा, ऐसा मान लेना ठीक नहीं है बल्कि हो सकता है कि Google इस ConstraintLayout को भी और Improve करके कुछ और नए तरह का Layout Define कर दे जो कि आने वाले भविष्‍य में Android Studio का Default Layout बन जाए।

अत: Google जब भी कोई नया Recommendation दे, हमेंशा उसी को Follow करना अपने Android App को Long Term तक Maximum Android Devices के लिए Useful व Supported बनाए रखने का एकमात्र तरीका है।