Wisdom of Helios

Leave a comment

Image Postioning on Android

A picture is worth a thousand words” refers to the notion that a complex idea can be conveyed with just a single still image. It also aptly characterizes one of the main goals of visualization, namely making it possible to absorb large amounts of data quickly. In Android an image is typically shown in an ImageView which is a dedicated view for showing image. This view takes the charge of load, optimize and scaling of the image and make the developer free  to focus on app-specific details . Unless you need special optimizations for your application, you should take advantage of the built-in image view whenever possible.

To display an image simply we have to declare an ImageView inside a LayOut and set its source to a resource in your project. Image resources are placed in the /res/drawable folders. This example will display an image named “antelope”:







android:sacleType=“fitCenter”   />

[/sourcecode ]

Please have a look on the attribute  sclaeType . It defines how the image will fit and be scaled to the view. In this example scaleType  is set to “fitCenter” , so the image will be shown  in the center of container view with scaling and preserve the aspect ratio. I’m going to list the scale type options and how they alter the image.

Here is the code snippet :

<RelativeLayout xmlns:android=http://schemas.android.com/apk/res/android&#8221;



android:layout_height=“match_parent” >


















[/sourcecode ]

This is the original image which is taken for Nat Geo website.






Displays the image in the center of container view. No scaling . Preserves aspect ratio (native resolution) and centered in the view, regardless of how much space the view consumes.  Screenshot_2000-01-02-04-54-05


Displays the image in the center of container view. Scales in such a way that both the X axis (width) and Y axis(height) is equal or larger than the corresponding axis of the view (minus padding) , while maintaining the image aspect ratio; crops any part of the image that exceeds the size of the view.



Displays the image in the center of container view. Scales in such a way that both the X axis (width) and Y axis(height) is equal or smaller than the corresponding axis of the view (minus padding) to fit inside the view , while maintaining the image aspect ratio. If the image is already smaller than the view, then this is the same as center.  Screenshot_2000-01-02-05-18-55


same as center using Scaling. Maintains the Image aspect ratio to fit inside the center of the view. At least one axis (height or width) will exactly match the corresponding axis of the view.



Same as fitCenter but aligned to the top-left of the container view.



Same as fitCenter but aligned to the right-bottom of the container view.



Scales the X and Y dimensions of the image to exactly match the container view. Does not preserve the aspect ratio of the image.




Scales the image using supplied Matrix Class. Usually this Matrix is implemented using setImageMatrix(Matrix) method.  This type of scaling is use to transform/process the image such as rotation.


Hardware Acceleration on Android 4.0

Hardware acceleration carries out all drawing operations to draw 2D UI elements on a view’s canvas using GPU. 2D rendering pipeline is used to support this hardware acceleration. For instance, menus popping up, dialog boxes, sliding down the notification bar, and transitioning between activities are hardware accelerated.
Android 4.0(API 14 and higher APIs) supports “full” hardware acceleration. All UI elements in windows, and third-party apps will have access to the GPU for rendering. Android 3.0(API 11) had the same system, but now developers will be able to specifically target Android 4.0 with hardware acceleration. Unlike window compositing, drawing inside of a window has traditionally been accomplished by the CPU in Android 2.x and below. In Android 3.0 Honeycomb, however, these functions could be offloaded to the device’s GPU as long as android:hardwareAccelerated=”true” was placed in the application’s manifest.
If an application uses only standard views and Drawables then we can use Hardware Acceleration with no headache. But hardware acceleration may not suitable for some custom views or custom drawing calls. It may cause problems like invisible elements, exceptions, or wrongly rendered pixels.

Controlling Hardware Acceleration
We can control the hardware acceleration from different levels –
 Application
 Activity
 Window
 View
Application Level
Defines that all the views in the application will be rendered using Hardware acceleration. To do this we have to mention a line in the application’s manifest file –

<application android:hardwareAcclerated = “true” >

Activity Level
If hardware acceleration causes problem to render an activity then we can add in the manifest. The following example enables hardware acceleration for the entire application but disable it for an activity.

<application android:hardwareAcclerated = “true” >

…… …..       …..                ……                …..   ….

<activity android:hardwareAcclerated = “false” >

------------------------------------------------ -----------------


</application >

Window Level
It creates more fine ViewGroup and window-


View Level
You can disable hardware acceleration of an individual view with this code –


Determining a Hardware Accelerated View
To determine a view whether it is hardware accelerated or not specially for the custom views there are 2 ways to check it –
View.isHardwareAccelerated() returns true if the View is attached to a hardware accelerated window.
Canvas.isHardwareAccelerated() returns true if the Canvas is hardware accelerated.
If you must do this check in your drawing code, use Canvas.isHardwareAccelerated() instead of View.isHardwareAccelerated() when possible. When a view is attached to a hardware accelerated window, it can still be drawn using a non-hardware accelerated Canvas. This happens, for instance, when drawing a view into a bitmap for caching purposes.

Tips & Tricks for drawing better views
The goal of hardware rendering for the interface is to get smoother operation. Switching to hardware accelerated 2D graphics can instantly increase performance, but you should still design your application to use the GPU effectively by following these recommendations:

Reduce the number of views in your application
The more views the system has to draw, the slower it will be. This applies to the software rendering pipeline as well. Reducing views is one of the easiest ways to optimize your UI.
Avoid overdraw
Do not draw too many layers on top of each other. Remove any views that are completely obscured by other opaque views on top of it. If you need to draw several layers blended on top of each other, consider merging them into a single layer. A good rule of thumb with current hardware is to not draw more than 2.5 times the number of pixels on screen per frame (transparent pixels in a bitmap count!).
Don’t create render objects in draw methods
A common mistake is to create a new Paint or a new Path every time a rendering method is invoked. This forces the garbage collector to run more often and also bypasses caches and optimizations in the hardware pipeline.
Don’t modify shapes too often
Complex shapes, paths, and circles for instance, are rendered using texture masks. Every time you create or modify a path, the hardware pipeline creates a new mask, which can be expensive.
Don’t modify bitmaps too often
Every time you change the content of a bitmap, it is uploaded again as a GPU texture the next time you draw it.
Use alpha with care
When you make a view translucent using setAlpha(), AlphaAnimation, or ObjectAnimator, it is rendered in an off-screen buffer which doubles the required fill-rate. When applying alpha on very large views, consider setting the view’s layer type to LAYER_TYPE_HARDWARE.

sourec : http://developer.android.com/guide/topics/graphics/hardware-accel.html



Running native codes (C codes) in Android using JNI and NDK

Although Android applications are mainly written by Java, developers sometimes may still want to leverage many good ready-made C/C++ libraries. Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts of your applications using native-code languages such as C and C++. This can provide benefits to certain classes of applications, in the form of reuse of existing code and in some cases increased speed.


JNI or Java Native Interface is the interface between the Java code running in a JVM and the native code running outside the JVM. It works both ways, that is you can use JNI to call native code from your Java programs and to call Java code from your native code. The native code normally resides within a library (.so file) and is typically written in C/C++.

Reasons to use JNI:

ü  Wrapping lower level functionality and make an abstraction level i,e, Camera, Sensors, audio devices etc.

ü  Suppose you have an existing C/C++ code library or a full game you’d like to port to Android, but you don’t want to translate them into Java. One solution is to keep as much code as possible in C/C++ and then use the Android NDK and the Java Native Interface to communicate between the two languages.

ü  Bypass performance bottlenecks.

Android NDK

Android NDK is a set of tools that embed native language (c\c++) in an android application. It’s easy to setup and use. Android applications run in the Dalvik virtual machine. The NDK allows you to implement parts of your applications using native-code languages such as C and C++. This can provide benefits to certain classes of applications, in the form of reuse of existing code and in some cases increased speed.

To build a shared library, you can use the ndk-build shell script included with the Android NDK. It needs to run in a Unix-like environment so, if you’re on Windows, you will require Cygwin.

You always have to compile your native code against a specific architecture. The Android NDK includes a cross-compiler (compilers and linkers etc) that will generate binaries for the ARM architecture. Since ARM is by far the most common architecture on the Android devices today it should work on most devices

NDK supports following instruction sets –

ü  ARMv5TE

ü  ARMv7-A

ARMv5TE runs on every ARM based Android devices. ARMv7-A will run only on devices such as the Verizon Droid or Google Nexus One that have a compatible CPU.

ARMv5TE is the default, but switching to ARMv7-A is as easy as adding a single line to the application’s Application.mk file, without needing to change anything else in the file.

NDK provides headers and libraries that allow you to build activities, handle user input, use hardware sensors, access application resources, and more, when programming in C or C++.  Note that native code accessible via JNI still runs inside the Dalvik VM, and as such is subject to the same life-cycle rules that any Android application lives by.


List of NDK Development tools –

The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.

It provides a set of system headers for stable native APIs that are guaranteed to be supported in all later releases of the platform:

  • libc (C library) headers
  • libm (math library) headers
  • JNI interface headers
  • libz (Zlib compression) headers
  • liblog (Android logging) header
  • OpenGL ES 1.1 and OpenGL ES 2.0 (3D graphics libraries) headers
  • libjnigraphics (Pixel buffer access) header (for Android 2.2 and above).
  • A Minimal set of headers for C++ support
  • OpenSL ES native audio libraries
  • Android native application APIS

The NDK also provides a build system that lets you work efficiently with your sources, without having to handle the toolchain/platform/CPU/ABI details. You create very short build files to describe which sources to compile and which Android application will use them — the build system compiles the sources and places the shared libraries directly in your application project.

Ways to write native codes in Android

  • Write your application using the Android framework and use JNI to access the APIs provided by the Android NDK. This technique allows you to take advantage of the convenience of the Android framework, but still allows you to write native code when necessary. You can install applications that use native code through the JNI on devices that run Android 1.5 or later.
  • Write a native activity, which allows you to implement the lifecycle callbacks in native code. The Android SDK provides the NativeActivityclass, which is a convenience class that notifies your native code of any activity lifecycle callbacks (onCreate(), onPause(), onResume(), etc). You can implement the callbacks in your native code to handle these events when they occur. Applications that use native activities must be run on Android 2.3 (API Level 9) or later.

You cannot access features such as Services and Content Providers natively, so if you want to use them or any other framework API, you can still write JNI code to do so.

Basic procedures to run native code

1)  A folder named ‘jni’ (lowercase) must be created by you in the Eclipse project’s root directory. This would place a folder at the same level as the Eclipse/Java ‘bin’, ‘src’, and ‘res’ folders. It would also be at the same level as the ‘AndroidManifest.xml’ file. Inside this folder is where the source c or c++ documents need to be placed.




2)  Create Android mk file, before the NDK build tools will compile your code they need a ‘Makefile’ file. Android.mk file describes your sources to the build-system.Information on writing the ‘Android.mk’ file can be found in the ‘docs’ folder inside the ‘android-ndk-***‘ folder.

The file syntax is designed to allow you to group your sources into ‘modules’. A module is one of the following: – a static librarya shared library. Only shared libraries will be installed/copied to your application package. Static libraries can be used to generate shared libraries though. You can define one or more modules in each Android.mk file, and you can use the same source file in several modules.

We can consider an example –

  LOCAL_PATH := $(call my-dir)

   include $(CLEAR_VARS)

   LOCAL_MODULE    := hellojni

   LOCAL_SRC_FILES := NativeSource.c


Let us explain these lines:

LOCAL_PATH := $(call my-dir)

An Android.mk file must begin with the definition of the LOCAL_PATH variable. It is used to locate source files in the development tree. In this example, the macro function ‘my-dir’, provided by the build system, is used to return the path of the current directory (i.e. the directory containing the Android.mk file itself).

include $(CLEAR_VARS)

The CLEAR_VARS variable is provided by the build system and points to a special GNU Makefile that will clear many LOCAL_XXX variables for you (e.g. LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, etc…), with the exception of LOCAL_PATH. This is needed because all build control files are parsed in a single GNU Make execution context where all variables are global.

LOCAL_MODULE    := hellojni

The LOCAL_MODULE variable must be defined to identify each module you describe in your Android.mk. The name must be *unique* and not contain any spaces. Note that the build system will automatically add proper prefix and suffix to the corresponding generated file. In other words, a shared library module named ‘hellojni’ will generate ‘libhellojni.so’.  [If you name your module ‘libhellojni’, the build system will not add another ‘lib’ prefix and will generate libhellojni.so as well. This is to support Android.mk files that originate from the Android platform sources, would you need to use these.]

LOCAL_SRC_FILES := NativeSource.c

The LOCAL_SRC_FILES variables must contain a list of C and/or C++ source files that will be built and assembled into a module. Note that you should not list header and included files here, because the build system will compute dependencies automatically for you; just list the source files that will be passed directly to a compiler


The BUILD_SHARED_LIBRARY is a variable provided by the build system that points to a GNU Makefile script that is in charge of collecting all the information you defined in LOCAL_XXX variables since the latest ‘include $(CLEAR_VARS)’ and determine what to build, and how to do it exactly. There is also BUILD_STATIC_LIBRARY to generate a static library.

3)  This is just a Java file that lives in standard src directory in your Eclipse project. It serves as the glue to the native code that we’ll write later.

package com.ndkadd.munir;

public class UseNDK {



System.loadLibrary("hellojni"); // we will load all the modules described in the Android.mk file


public native int AddNumbers(int value1 , int value2);


                 A C header file named  com_ndkadd_munir_UseNDK.h will be created    on the defined path.Next, copy the JNI header from NDKAddDemo/bin/class    to   NDKAddDemo/jni

4) Create the Native code header file, to do this , run Cygwin, go to the bin directory of the project in Cygwin. Enter one more step farther into classes folder. In my case, I entered /cygdrive/c/workspace/NDKAddDemo/bin/classes in Cygwin terminal. Run javah tool in this location to create jni header file

m.hoque@S-11627522 /cygdrive/c/workspace/NDKAddDemo/bin/classes

$ javah -jni com.ndkadd.munir.UseNDK

A C header file named  com_ndkadd_munir_UseNDK.h will be created    on the defined path.Next, copy the JNI header from NDKAddDemo/bin/class    to   NDKAddDemo/jni


5)  Writing C/C++ code is little tricky here. In the JNI framework, native functions are implemented in separate .c or .cpp files. When the JVM invokes the function, it passes a JNIEnv pointer, a jobject pointer, and any Java arguments declared by the Java method. You must have to implement the methods in the header file here. You can consider an example here –

JNIEXPORT jint JNICALL Java_com_ndkadd_munir_UseNDK_AddNumbers
(JNIEnv *env, jobject obj, jint v1, jint v2)

The env pointer is a structure that contains the interface to the JVM. It includes all of the functions necessary to interact with the JVM and to work with Java objects. Example JNI functions are converting native arrays to/from Java arrays, converting native strings to/from Java strings, instantiating objects, throwing exceptions, etc. Basically, anything that Java code can do can be done using JNIEnv.

 6) Compile everything and build you Shared Library, We will use the Android NDK ToolChain here. Go to Project root, the project root is the base folder for the Eclipse Android project.

m.hoque@S-11627522 /cygdrive/c/workspace/NDKAddDemo

$ /cygdrive/c/workspace/android-ndk-r7b/ndk-build

The NDK build tools will compile the code, and then if there are no errors it will name the object code ‘libndkadd.so’ and place it in the Android project in a new folder that it creates especially for this purpose. The name of the folder is ‘libs/armeabi/‘. The build tools also manage the creation of some other files that are necessary.

Use your native code inside Android activity,  here is my main.xml file –

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical" >
        android:textAppearance="?android:attr/textAppearanceMedium" />

        android:inputType="number" >

        <requestFocus />

        android:inputType="number" />

        android:text="Add" />

        android:textAppearance="?android:attr/textAppearanceLarge" />


And, here is the Activity –

package com.ndkadd.munir;

import android.app.Activity;
import android.os.Bundle;
import android.util.Log;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.EditText;
import android.widget.TextView;

public class NDKAddDemoActivity extends Activity implements OnClickListener {
	UseNDK ntv = new UseNDK();
	private Button btnCalculate;
	private EditText editResult;
	private EditText editV1;
	private EditText editV2;
	private TextView result;

    /** Called when the activity is first created. */
    public void onCreate(Bundle savedInstanceState) {
        btnCalculate = (Button)findViewById(R.id.btnAdd);
        // editResult = (EditText)findViewById(R.id.textResult);
         editV1 = (EditText)findViewById(R.id.editV1);
         editV2 = (EditText)findViewById(R.id.editV2);
         result = (TextView)findViewById(R.id.textResult);


 	public void onClick(View v) {
 		// TODO Auto-generated method stub
 		if(v.getId() == R.id.btnAdd)
 		int v1, v2, res = 0;
         v1 = Integer.parseInt(editV1.getText().toString());
         v2 = Integer.parseInt(editV2.getText().toString());
         res = ntv.AddNumbers(v1, v2);
         Log.d("Result", "dsdfsf");
         result.setText(new Integer(res).toString());


I had a wish to write more about JNI and NDK by someday. Enough for today. 🙂 🙂 😀


Static Block in JAVA

Static blocks are blocks defined within the body of a class using the static keyword. A static block is executed when the JVM loads the class. The static block will execute ONLY at the FIRST TIME the class is loaded to the JVM.
Let us explore a very simple example.

public class SampleStatic
  static int x = 100;
  static int y;

      y = x*5;

Output: 500
So when you will run this code snippet you will get the output 500. Because when the class is first loaded the static block will execute first and print the 500 to the output stream.

Now , I’m going to elaborate something about the static block –
1. The static block will execute ONLY at the FIRST TIME the class is loaded to the JVM.
2. A class can have any number of static initialization blocks, and they can appear anywhere in the class body. But when executing the static blocks will execute in order to the source file. JRE is responsible for making this order. After the serial is done JVM will account these static blocks as a single static blocks and execute them.

public class StaticExmple1 {

String str = null;
StaticExmple1(String s)
str = s;
static String strString = null;

System.out.println("First Static block");
static {
System.out.println("Second Static block");

Output: First Static block
Second Static block

3.  As static method and variable static block is also uses ONLY static variable and data.

4.  Inside the Static block you can ONLY declare non-static variables.

5.  Static block  / Static blocks can not be inherited.

6.  If  you declare a static variable after the last static block then no static block can access this static variable and a compile-time error will occur.

7.   You cannot return a value  from  a static block. Inside a static block you can not use this and super keyword. Static block cannot throw an exception.

Now, I’m going to demonstrate an example that will contain all characteristics of  a static block.

public class StaticExmple1 {
String str = null;
StaticExmple1(String s)
str = s;
static String strString = null;

System.out.println("First Static block");
static {
System.out.println("Second Static block");
static String staticMethod()
strString = "Static Method";
return strString;

static {
String s ="";
s = staticMethod();

public static void main(String[] args)
StaticExmple1 se1 = new StaticExmple1("First Object");

StaticExmple1 se2 = new StaticExmple1("Second Object");

Output: First Static block
Second Static block
Static Method
First Object
Second Object

This code snippet is self-explained  🙂 .

Advantages of  static block

1. The primary use of static initializers blocks are to do various bits of initializations that may not be appropriate inside a constructor.

2.  If you need to do computation in order to initialize your static variables,you can declare a static block which gets executed exactly once,when the class is first loaded.   (In one of my job training the trainer told us to run a Java code without a main method. I simply wrote a static block and inside this block I printed a “Hello World” message ……… It worked …….. 😛  😀 ).

3.  Security related issues or logging related tasks.



[This portion is copied from JustForTechies  Blog . I’m grateful to them]

Again if you miss to precede the block with “static” keyword, the block is called “constructor block” and will be executed when the class is instantiated. The constructor block will be copied into each constructor of the class. Say for example you have four parameterized constructors, then four copies of contructor blocks will be placed inside the constructor, one for each. Lets execute the below example and see the output.

public class ConstructorBlockExample{

        System.out.println("This is first constructor block");

    public ConstructorBlockExample(){
        System.out.println("This is no parameter constructor");

    public ConstructorBlockExample(String param1){
        System.out.println("This is single parameter constructor");

    public ConstructorBlockExample(String param1, String param2){
        System.out.println("This is two parameters constructor");

        System.out.println("This is second constructor block");

    public static void main(String[] args){
        ConstructorBlockExample constrBlockEx =
		             new ConstructorBlockExample();
        ConstructorBlockExample constrBlockEx1 =
		             new ConstructorBlockExample("param1");
        ConstructorBlockExample constrBlockEx2 =
		             new ConstructorBlockExample("param1", "param2");

Output:   This is no parameter constructor

This is first constructor block

This is second constructor block

This is single parameter constructor

This is first constructor block

This is second constructor block

This is second parameter constructor

This is first constructor block

This is second constructor block

The above example is self-explanatory.  🙂