Monday, May 7, 2012

Component design for web projects

JSP lets web designers employ the same component design principles that other software developers have been using for years. Rather than having to embed complex logic directly into pages through scripting code, or building page content into the programming logic, they can simply employ HTML layout around components. The component model’s ability to reuse common components can reduce development time and project complexity.
Isolating application logic from presentation layout is a necessity for web development organizations that are built around teams whose members have a diverse set of complementary skill sets. In many enterprises the web team is composed of both application developers and web developers. Java application developers are skilled in tasks such as exchanging information with a database and optimizing back-end server code for performance, while web developers are good with the presentation aspects such as interface design and content layout. In a componentized JSP development project, application developers are free to concentrate on developing components that encapsulate program logic, while web developers build the application around these components, focusing their energies on its presentation.
In some cases a single person may handle both aspects of design, but as project complexity grows, splitting up the tasks of the development process can yield a number of benefits. Even for web projects being handled by a small, unified team of developers, a component-based architecture makes sense. The flexibility offered by components allows a project to handle the sudden changes in requirements that often seem to accompany web projects.

Monday, April 23, 2012

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.

Tuesday, April 17, 2012

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.

Saturday, April 14, 2012

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.

Monday, March 26, 2012

Inheritance In Java

One of the fundamental mechanisms for code reuse in OOP, is inheritance. It allows new classes to be derived from an existing class. The new class (a.k.a. subclass, subtype, derived class, child class) can inherit members from the old class (a.k.a. superclass, supertype, base class, parent class). The subclass can add new behavior and properties, and under certain circumstances, modify its inherited behavior.
In Java, implementation inheritance is achieved by extending classes (i.e., adding new fields and methods) and modifying inherited members Inheritance of members is closely tied to their declared accessibility. If a superclass member is accessible by its simple name in the subclass (without the use of any extra syntax like super), then that member is considered inherited. This means that private, overridden, and hidden members of the superclass are not inherite. Inheritance should not be confused with the existence of such members in the state of a subclass object.
 Example Extending Classes: Inheritance and Accessibility
class Light {                       // (1)
    // Instance fields
              int     noOfWatts;    // wattage
    private   boolean indicator;    // on or off
    protected String  location;     // placement

    // Static fields
    private static int counter;     // no. of Light objects created

    // Constructor
    Light() {
        noOfWatts = 50;
        indicator = true;
        location  = "X";
        counter++;
    }

    // Instance methods
    public  void    switchOn()  { indicator = true; }
    public  void    switchOff() { indicator = false; }
    public  boolean isOn()      { return indicator; }
    private void    printLocation() {
         System.out.println("Location: " + location);
    }

    // Static methods
    public static void writeCount() {
         System.out.println("Number of lights: " + counter);
    }
    //...
}

class TubeLight extends Light {     // (2) Subclass uses the extends clause.
    // Instance fields
    private int tubeLength = 54;
    private int colorNo    = 10;

    // Instance methods
    public int getTubeLength() { return tubeLength; }

    public void printInfo() {
        System.out.println("Tube length: "  + getTubeLength());
        System.out.println("Color number: " + colorNo);
        System.out.println("Wattage: "      + noOfWatts); // Inherited.
    //  System.out.println("Indicator: "    + indicator); // Not Inherited.
        System.out.println("Indicator: "    + isOn());    // Inherited.
        System.out.println("Location: "     + location);  // Inherited.
    //  printLocation();                                  // Not Inherited.
    //  System.out.println("Counter: "    + counter);     // Not Inherited.
        writeCount();                                     // Inherited.
    }
    // ...
}

public class Utility {               // (3)
    public static void main(String[] args) {
       new TubeLight().printInfo();
    }
}
Output from the program:
Tube length: 54
Color number: 10
Wattage: 50
Indicator: true
Location: X
Number of lights: 1

The superclass is specified using the extends clause in the header of the subclass declaration. The subclass only specifies the additional new and modified members in its class body. The rest of its declaration is made up of its inherited members. If no extends clause is specified in the header of a class declaration, then the class implicitly inherits from the java.lang.Object class. This implicit inheritance is assumed in the declaration of the Light class at (1). Also , the subclass TubeLight at (2) explicitly uses the extends clause and only specifies additional members to what it already inherits from the superclass Light (which, in turn, inherits from the Object class). Members of the superclass Light that are accessible by their simple names in the subclass TubeLight, are inherited by the subclass.

Private members of the superclass are not inherited by the subclass and can only be indirectly accessed. The private field indicator of the superclass Light is not inherited, but exists in the subclass object and is indirectly accessible.
Using appropriate accessibility modifiers, the superclass can limit which members can be accessed directly and, thereby, inherited by its subclasses. The subclass can use the inherited members as if they were declared in its own class body. This is not the case for members that are declared private in the superclass. Members that have package accessibility in the superclass are also not inherited by subclasses in other packages, as these members are only accessible by their simple names in subclasses within the same package as the superclass.

Thursday, March 22, 2012

J2ME Configurations Overview

The configuration defines the basic run-time environment as a set of core classes and a specific JVM that run on specific types of devices. Currently, two configurations exist for J2ME, though others may be defined in the future:
  • Connected Limited Device Configuration (CLDC) is used specifically with the KVMfor 16-bit or 32-bit devices with limited amounts of memory. This is the configuration(and the virtual machine) used for developing small J2ME applications. Its sizelimitations make CLDC more interesting and challenging (from a development point ofview) than CDC. CLDC is also the configuration that we will use for developing ourdrawing tool application. An example of a small wireless device running smallapplications is a Palm hand-held computer.
  • Connected Device Configuration (CDC) is used with the C virtual machine (CVM) and is used for 32-bit architectures requiring more than 2 MB of memory. An example of such a device is a Net TV box.

Sunday, March 18, 2012

Major Categories of Markup Tags Provided by JSP

بِسۡمِ ٱللهِ ٱلرَّحۡمَـٰنِ ٱلرَّحِيمِ
JSP provides four major categories of markup tags. The first, directives, is a set of tags for providing the JSP container with page-specific instructions for how the document containing the directives is to be processed. Directives do not affect the handling of individual requests, but instead affect global properties of the JSP page that influence its translation into a servlet.
example:
<jsp:directive.page attribute1="value1" 
                 attribute2="value2" attribute3=… />
 
Scripting elements are used to embed programming instructions, written in the designated scripting language for the page, which are to be executed each time the page is processed for a request. Some scripting elements are evaluated purely for their side effects, but they may also be used to generate dynamic content that appears in the output of the page.
example:
<jsp:declaration> declaration(s) </jsp:declaration>

Comments are used for adding documentation strings to a JSP page. JSP supports multiple comment styles, including one which enables documentation to appear in the output from the page. Other JSP comments can only be viewed in the original JSP file, or in the source code for the servlet into which the page is translated.
example:
  <% /* comment */%>

Actions support several different behaviors. Like scripting elements, actions are processed for each request received by a page. Actions can transfer control between pages, specify applets, and interact with server-side JavaBeans components. Like scripting elements, actions may or may not generate dynamic content. All custom tags incorporated via extended tag libraries take the form of actions.