Home » Xamarin.Android Application Fundamentals

Xamarin.Android Application Fundamentals

by Online Tutorials Library

Xamarin.Android Application Fundamentals

Here, we will explain some tasks or concepts with which the developer needs to be aware of during the development of the Android applications.

Accessibility

Here, we will discuss how to use the Android Accessibility APIs to build the apps.

UI Elements

Android provides a ContentDescription property that is used by the screen reading APIs to describe the purpose of control’s accessibility.

The description of the content is in the AXML layout file.

AXML layout

In XML layout, we use the android:contentDescription attribute:

Hint for TextView

For the data input, EditText and TextView controls use the Hint property to provide the description of the expected input. When the text is entered, text itself will “read” instead of hint.

AXML layout

XML layout files uses the android:hint attribute:

LabelFor links input fields with labels

To associate label with a data input control, we use the labelFor property.

AXML layout

In XML layout we use the android:labelFor property to reference the another control’s identifier:

Announce for Accessibility

We use the AnnounceForAccessibility method on any view control to communicate an event or status change to users when accessibility is enabled. AnnounceForAccessibility is not required for all the operations where the built-in narration provides sufficient feedback. We can use AnnounceForAccessibility where additional information will be helpful for the user.

The code below shows a simple example calling AnnounceForAccessibility:

Changing Focus Settings

Navigation depends on controls having focus on the user’s understanding of the availability of the operation. Android provides a Focusable property that can have the tag controls specifically able to receive the focus during navigation.

AXML layout

In layout XML files, set the Android: focusable attribute:

We can focus on the order of the control with the nextFocusDown, nextFocusLeft, nextFocusup attributes, which is set in the XAML layout. We use these attributes to ensure that the user can navigate easily through the controls on the screen.

Android Resources

Here, we will show the concept of Android Resources in Xamarin.

An Android application is just a source code. Many files can make the application such as video, images, fonts, and audio files. The non-source code file referred to as resources and compiled during the build process and packaged as an APK for the distribution and installation into the devices:

Xamarin.Android Application Fundamentals

Resources offer different advantages to an Android application:

  • Code-Separation: Resources separates the source code from images, strings, menus, animations, colors, etc. Resources also help in localization, as well.
  • Target multiple devices: Resources provide support for different devices without changing the code.
  • Compile-time checking: In the application, Resources are static and compiled into the application. At compile time, this allows the verification of the Resources. At that time, it is easy to catch and correct mistakes. At the run time, it is more difficult to find out the error, and the correction of the error is costly.

When a new Xamarin.Android project is started, an exclusive directory Resources is created, along with some subdirectories:

Xamarin.Android Application Fundamentals

This screenshot shows that the application resources are arranged according to their type into the subdirectories. Drawable Directory has the Images; views go in the layout subdirectory, etc.

Here, are the two ways to access the Resources in Xamarin. Android application: Programmatically in code and declaratively in XML using XML syntax.

These Resources are called the Default Resources and used by all the devices unless a more specific match is found. Each type of resource may have Alternate Resources that Android may use to target particular tools.

For example, resources provided to target the locale and screen size of a user. If the device rotates in 90 degrees from portrait to landscape, then in all the cases, Android will load the resources for the application without any extra coding effort.

At the end of the directory which holds other resources are specified by adding a short string is known as a qualifier.

For example, resources/drawable-de will specify the images for devices that are set to a German locale, while resources/drawable-fr hold the images for devices set to a French region. The example of providing other resources can be seen in the image below where the same application is being run with changing the locale of the device:

Xamarin.Android Application Fundamentals

Here, we will discuss some more basics terms related to Resources. These are:

Android Resource Basics

Almost all the Android application has some Resources. Applications often have the user interface layout in the form of XML files. When we create the Xamarin.Android application first, default resources are set up by the Xamarin.Android project template.

Xamarin.Android Application Fundamentals

As shown in the screenshot, here are the five files which created the default Resources in Resource Folder:

  • Icon.png – This is the default icon for the application
  • Main.axml – Main.axml is the default user interface layout file for an application. Android uses the .xml file extension, while Xamarin.Android uses the .axml file extension.
  • Strings.xml – String table helps in the application localization.
  • AboutResources.txt – This file is not necessary for the application and can delete safely. It just provides a Resources folder overview and the files located in it.
  • Resource.designer. Cs – This file generated automatically and maintained by Xamarin.Android which holds the unique ID and the ID is assigned to each Resource. Resource.designer. Cs is very similar and identical to the R.java file. Xamarin automatically creates it. Android tools will be regenerated from time to time.

Creating and Accessing the Resource

Creating the Resources is as simple as adding the files to the directory for the Resources. When Strings.xml added to the file, Build Action was automatically set to AndroidResources by the Xamarin.Android tools:

Xamarin.Android Application Fundamentals

This allows the Xamarin. Android tools to compile properly and embed the resources into the APK file. If, for any reason, Build Action not set to Android Resources, then the data will be excluded from APK. At the time of loading or access, the Resources give the Run-Time error, and the application crashes.

Android supports only lowercase filenames for resource items while Xamarin. Android supports both uppercase and lowercase. The convention for image names is to use the lowercase with underscores as a separator, for example, my_image_name.png. The name of the Resources cannot be processed if dashes or spaces are used as separators.

Referencing the Resources Programmatically

To access all the Resource files programmatically, Unique ResourceID is assigned to the data. The resource ID is an integer defined in a particular class called Resources, which is found in the file Resource.Designer.CS.

Code looks something like this:

Each ResourceID is found inside the nested class, which corresponds to the type of Resources.

When the icon.png file was added to the project, Xamarin.Android updated the Resource class and created a nested class known as Drawable with a constant name icon. Drawable allows the file icon.png to be referred to in the code as Resource.Drawable.Icon.

Resource class should not be edited manually; the Xamarin will overwrite all changes in the Android.

When we reference the Resource programmatically, they can be accessed by the Resource Class hierarchy. Here we use the following syntax:

PackageName: Package, which provided the Resource that required the resources from another package where it is used.

Resource Type: This is the type of nested Resource within the Resource class.

Resource Name: This is the filename of Resource (without file type extension) or the value of the Android: name attribute for resources that are in the XML element.

For example, the content of the layout file, main. axml are:

In this example, we used the ImageView, which requires a drawable resource name flag. ImageViewhas an src attribute which is set to @drawable/flag. When an activity starts, Android will look inside the directory Resource/Drawable for a file flag.png (the file extension could be another image format, like flag.jpg) and load the file and display it in the ImageView. When this application run, it would look something like the following image:

Xamarin.Android Application Fundamentals

Default Resources

Default Resources are the items that are not specific for any particular device. If no specific resource found, then it is the default choice for the Android OS. Default Resources is the most common Resource. They are arranged into the sub-directories of the Resource directory according to the type of Resources.

Xamarin.Android Application Fundamentals

From the above image, it shows the default values for the drawable resources, layouts, and values (XML file, which contains simple value).

The list of the type of Resources are:

  • Drawable: Drawable Resources are the general concept of the graphics. Drawable Resources can be compiled into the application and accessed by the API calls or referenced by the other XML resources. Examples of Drawable images are: bitmap files (.png,.gif,.jpg), special resizable bitmaps are known as Nine-Patches, generic shapes defined in XML, etc.
  • Layout: In layout, XML files describe the user-interface layout, such as an activity or row in a list.
  • Animator: XML files that describe the animations property, which introduced the API 11 (Android 3.0) and provided the properties of the object for the animations. Property animations are more flexible and powerful way to describe the animations of any object.
  • anim: XML files describe the tween animations. Tween animations are a series of animation instruction on the contents of the view object, for example, rotation of the image and growing the size of the text. Tween animations are limited to View objects only.
  • color: XML files describe the list of colors. To understand the list of colors, we consider a UI widget, such as Button. Color may have different states such as pressed or disabled, and the Button may change the color with each change in the state. The list is shown in the state list.
  • menu: XML files that describe the menus of the application such as Option menu, Context Menu, and submenu. Example of menus is the Popup menu, Standard control menu.
  • raw: Arbitrary files saved in the raw and the binary form. These files are compiled in the Android application in a binary format.
  • Values: XML files which contain the simple amounts. In the XML file value, the directory does not define the single Resource but instead can identify multiple resources. For example, one XML file holds a list of string values, and the XML file may contain the color values.
  • xml: The function of the XML files is similar to the .Net configuration files. These are the arbitrary XML that can be read at run time by the application.

Alternate Resource

Alternate Resources are those resources that target the specific device. Alternative Resource is also defined as a run-time configuration such as the current language, screen size, and the pixel density. If android can match the Resource that is specific to particular devices or configuration than the default resource, in that case, we will use Alternate Resources. If Android didn’t find any other resources that match the current configuration, then we will load default resources. The name of the Alternate Resource Sub-Directory is Resource-type-qualifier.

The qualifier is a name that identifies the configuration of the specific device. A name can contain more than one qualifier; dash separates each of them.

Xamarin.Android Application Fundamentals

From the above screenshot, it shows that this contains the other resources for various configurations such as locale, screen size, screen density, and orientation.

The rules apply while adding the qualifiers to the Resources are:

  1. There may be more than one qualifier and a dash that separates the qualifier.
  2. Qualifiers may be specified only once.
  3. Qualifiers must be in order when they show in the table.

List of Qualifiers are:

  • MCC and MNC: Full form of MCC Mobile Country Code and MNC is Mobile Network Code. Sim card will provide the MCC, and the network device will provide the MNC. It is possible to target the locales with the Mobile Country Code, and the Recommended approach is to use the Language Qualifier. For example: focus the Germany resources; qualifier would be mcc262. In US target resources for T-mobile, the usable qualifier is mcc310-mnc206.
  • Language: The two-letter ISO 639-1 language code and followed by the two-letter ISO-3166-alpha-2 region code. If both the qualifiers are presented, then they separated by -r. For example, to target the French-speaking locales, then the qualifier fr is used. To target French-Canadian areas, the fr-rCA would be used.
  • Smallest Width: To execute the application, we should have to specify the smallest width of the screen. API level 13 or above is available (Android 3.2).
    For example, Qualifier sw320 dp is used to target the devices whose height and width are at least 320 dp.
  • Screen Aspect – Screen Aspect is based on the aspect ratio, not the screen orientation. A large screen is more comprehensive. I have added in API level 4 (Android 1.6). Possible values are long.
  • Screen Orientation – This includes the Portrait or landscape screen orientation. Screen Orientation can change during the application’s life. The possible values are port and land.
  • Dock Mode – The device in a car is a dock or a desk dock. Dock Mode added in API level 8 (Android 2.2.x). The possible values in the Dock Mode are car and desk.
  • Night Mode – Whether the application is running at night or in the day. Night Mode may change during the lifetime of an application and is meant to allow developers to use darker versions of an interface at night and added in API level 8 (Android 2.2.x). Possible values in Night Mode are night and not night.
  • Screen Pixel Density (dpi) – Screen Pixel Density shows the number of pixels in a given area on the physical screen. Typically expressed as dots per inch (dpi). Possible values are:
    • ldpi – Low-density screens.
    • mdpi – Medium density screens
    • hdpi – High-density screens
    • xhdpi – Extra high-density displays
    • nodpi – Resources that are not scaled
    • tvdpi – This includes in level 13 of API(Android 3.2) for the screens in between mdpi and hdpi.
  • Touchscreen – Defines the type of touchscreen a device may have. Possible values are stylus (a resistive touchscreen suitable for a stylus), finger (a touchscreen), and notouch (no touch screen).
  • Keyboard Availability – Defines the type of keyboard is available. Keyboard Availability may change during the lifetime of an application – for example, when a user opens a keyboard. Values are:
    • keysexposed – keysexposed qualifier is defined as when the device has a hardware keyboard. If there is not any software keyboard enabled, then keysexposed is used when the hardware keyboard is opened.
    • keyshidden – keyshidden qualifier is used when the device has keyboard hardware, but it is not visible, and no keyboard software is enabled.
    • keyssoft – keyssoft qualifier is used when the device has a keyboard software enabled.
  • Primary Text Input Method – This Qualifier is used to specify the types of hardware keys available for input. Possible values are:
    • nokeys – There are no hardware keys for input.
    • qwerty – There is a qwerty keyboard available.
    • 12key – There is a 12-key hardware keyboard
  • Navigation Key Availability – For 5-way or d-pad (directional-pad), navigation is available. Navigation Key Availability can change during the lifetime of your application. Possible values are:
    • navexposed – navigational keys are available to the user
    • navhidden – It does not include the navigation keys.
  • Primary Non-Touch Navigation Method – This type of navigation is available on the device. Possible values are:
    • nonav – the only navigation facility available is the touch screen
    • d-pad – d-pad (directional-pad) is available for navigation
    • trackball – the device has a trackball for navigation
    • wheel – the uncommon scenario where there are one or more directional wheels available
  • Platform Version (API level) – The Platform Version is supported by the device in the format vN, where N is the API that is being targeted. For example, v11 target the API level 11 device.

Android Determine what Resources to use

The android application contains many resources. Here we will study how Android will select the Resources for the application when it runs on a device.

Android shows the base of the Resources by iterating over the rules of the Test:

  • Eliminate contradictory qualifiers – for example, if the orientation device is a portrait, then landscape resource directories will be dismissed.
  • Ignore qualifiers not supported – All qualifiers are not available to all API levels. If a resource directory contains a qualifier that is not supported by the device, then the resource directory will be avoided.
  • Identify the next highest priority qualifier – As per the above table, choose the next highest priority qualifier (from top to bottom).
  • Keep any resource directories for qualifier – if any resource directories match the qualifier to the above, select the next highest priority qualifier (from top to bottom).

When the system is looking for resources and cannot find them, it will find other resources and scale them. Android cannot find the default resources. For example, when Android is looking for a low-density resource, and it is not available, Android may select the version of high-density Resource over the default or medium-density resources. It does this because, the high-density Resource can be measured by a factor of 0.5, which will result in a few visibility issues than measured a medium-density resource, which would require a factor of 0.75.

For example: Consider an application which has the following drawable resource directories:

And then the application runs on a device with the following configuration:

French resources are eliminated conflict with the locale of en-GB:

The first qualifier is selected from the qualifiers table MCC and MNC. There are no resource directories which contain this qualifier, so the MCC/MNC code is ignored.

The next qualifier selects the language. Some resources match the language code. All resource directories which do not match with the language code are rejected and list of resources are now:

The next qualifier present for screen orientation is the resource directories that do not match with the screen orientation port are eliminated:

The qualifier for screen density is ldpi, which results in the exclusion of one more resource directory:

As a result, Android will use the drawable resources in the resource directory drawable-en-port-ldpi for the device.


Next TopicXamarin vs Ionic

You may also like