Modelling Abstractions, Using Classes and Objects

Abstractions is one of the fundamental ways in which we handle complexity. An abstraction denotes the essential properties and behaviors of an object that differentiate it from other objects. The essence of OOP is modelling abstractions, using classes and objects, and the hard part in this endeavour is finding the right abstractions.

A class denotes a category of objects, and acts as a blueprint for creating such objects. A class models an abstraction by defining the properties and behaviors for the objects representing the abstraction. An object exhibits the properties and behaviors defined by its class. The properties of an object of a class are also called attributes, and are defined by fields in Java. A field in a class definition is a variable which can store a value that represents a particular property. The behaviors of an object of a class are also known as operations, and are defined using methods in Java. Fields and methods in a class definition are collectively called members.

As an example, we will implement different versions of a class that models the abstraction of a stack that can push and pop characters. The stack will use an array of characters to store the characters, and a field to indicate the top element in the stack. Using Unified Modeling Language (UML) notation, a class called CharStack is graphically depicted in Figure, which models the abstraction.  

Its intention is to illustrate the salient features of a class definition in Java, and not effective implementation of stacks.

A class definition consists of a series of member declarations. In the case of the class CharStack, it has two fields:

• stackArray, which is an array to hold the elements of the stack (in this case characters)
• topOfStack, which denotes the top element of the stack (i.e., index of the last character stored in the array)

The class CharStack has five methods that implement the essential operations on a stack:

• push() pushes a character on to the stack
• pop() removes and returns the top element of the stack
• peek() returns the top element of the stack for inspection
• isEmpty() determines whether the stack is empty
• isFull() determines whether the stack is full

The class definition also has a method-like declaration with the same name as the class, (2). Such declarations are called constructors. As we shall see, a constructor is executed when an object is created from the class. However, the implementation details in the example are not important for the present discussion.

Use XML-Based Layouts for User Interface

 بِسۡمِ ٱللهِ ٱلرَّحۡمَـٰنِ ٱلرَّحِيمِ

It is technically possible to create and attach widgets to our activity purely through Java code, but the more common approach is to use an XML-based layout file. Dynamic instantiation of widgets is reserved for more complicated scenarios, where the widgets are not known at compile-time.
An XML-based layout is a specification of widgets' relationships to each other encoded in XML format. Specifically, Android considers XML-based layouts to be resources, and as such layout files are stored in the res/layout directory inside each Android project.
Each XML file contains a tree of elements specifying a layout of widgets and containers that make up one View. The attributes of the XML elements are properties, describing how a widget should look or how a container should behave. For example, if a Button element has an attribute value of android:textStyle = "bold", that means that the text appearing on the face of the button should be rendered in a boldface font style.
Most everything you do using XML layout files can be achieved through Java code. For example, you could use setTypeface() to have a button render its text in bold, instead of using a property in an XML layout. Since XML layouts are yet another file for you to keep track of, we need good reasons for using such files.
Perhaps the biggest reason is to assist in the creation of tools for view definition, such as a GUI builder in an IDE like Eclipse. Such GUI builders could, in principle, generate Java code instead of XML. The challenge is re-reading the definition in to support edits – that is far simpler if the data is in a structured format like XML than in a programming language. Moreover, keeping the generated bits separated out from hand-written code makes it less likely that somebody's custom-crafted source will get clobbered by accident when the generated bits get re-generated. XML forms a nice middle ground between something that is easy for tool-writers to use and easy for programmers to work with by hand as needed.

How to Create Android Application to Support All Screen Sizes

بِسۡمِ ٱللهِ ٱلرَّحۡمَـٰنِ ٱلرَّحِيمِ

Android devices come with a wide range of screen sizes, from 2.8" tiny smartphones to 46" Google TVs. Android divides these into four buckets, based on physical size and the distance at which they are usually viewed: Small (under 3"), Normal (3" to around 4.5"), Large (4.5" to around 10"), Extra-large (over 10"). By default, your application will not support small screens, will support normal screens, and may support large and extra-large screens via some automated conversion code built into Android. We may want to test Android application on an emulator, or we may want to test it on a phone, or we may want to test it on a tablet. To run the Android application work better, we need to modify the manifest for our project, to add a <supports-screens> element, declaring what sizes we support and do not by modifying the AndroidManifest.xml file in the root of your project tree. Below is the example:

<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="apt.tutorial" android:versionCode="1" android:versionName="1.0"> <supports-screens android:xlargeScreens="true" android:largeScreens="true" android:normalScreens="true" android:smallScreens="false" /> <application android:label="@string/app_name"> <activity android:name=".LunchList" android:label="@string/app_name"> <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </application> </manifest>

The application will not run on a small-screen device (typically under 3" diagonal screen size). However, it will run well on everything bigger than that.