Wisdom of Helios

1 Comment

Angular JS QuickStart

Today I have uploaded a short presentation on Angular JS quick start. It is a laconic presentation on Angular JS for beginners only. I have emphasized on example rather than theory. There are self explained source code urls attached with slides. In the last slide I have attached source code for a real life example using Angular JS an BootStrap which may be very helpful to understand the concept of Angular JS.

Angular JS real life example

Angular JS real life example

Leave a comment

Javascript closure tutorial with example

A closure in JavaScript is like keeping a copy of all the local variables, just as they were when a function exited.
Simply accessing variables outside of your immediate scope creates a closure.

Example 1 :
Simplest Closure example

var a = 3; // global varibale
function t() {
console.log(a); // will output 3
console.log(b); // will output 4
var b = 4; //// global varibale

Example 2 :
Here a closure is formed, because f2 funtion can access the “temp” which was defined
as an member variable of f1. To become a closure function does not need to be returned all the time

function f1(a)
  var temp = 0;
  function f2(b)
    alert(++temp); // will alert 1

Example 3 :
Below code snippet also creates closure,
f2 function can still refer to temp even though it is no longer directly inside the scope.
However, since temp is still hanging around inside cls closure, it is also being incremented.
It will be incremented each time you call cls().

function f1(a)
  var temp = 0;
  return function f2()
var cls =  f1(5); // return function has been coppied
cls() // closure formed !!!!!  temp = 1;
cls(); // temp = 2;
cls(); // temp = 3;

Example 4 :
A closure is a stack-frame which is not deallocated when the function returns .
The three functions have shared access to the same closure — the local variables of s() when the three functions were defined.

Note that in the below example, if you call s() again,
then a new closure (stack-frame!) is created. The old sShow, sIncrease, sSetNumber
variables are overwritten with new functions that have the new closure.
(In JavaScript, whenever you declare a function inside another function,
the inside function(s) is/are recreated again each time the outside function is called.)

function s() 
    // Local variable that ends up within closure
    var num = 666;
    // Store some references to functions as global variables
    sShow = function() { alert(num); }
    sIncrease = function() { num++; }
    sSetNumber = function(x) { num = x; }

sShow(); // will alert 667 as sIncrease() is called earlier 
		//	and now num = num+1. 

sShow();  // will alert 10 as sSetNumber() is called earlier 
		//	and now num = 10. 
var oldVal = sShow(); // alert 10 as num is set to 10 earlier.
s() // new closure (stack-frame!) is created. All inner functions will 
    // generate new closures.
sShow(); // alerts 666

Example 5 :
This example shows that the closure contains any local variables that were declared inside
the outer function before it exited. Note that the variable greet is actually declared after
the anonymous function. The anonymous function is declared first; and when that function is
called it can access the greet variable because greet is in the same scope
(JavaScript does variable hoisting). Also yourName()() just directly calls the function reference
returned from sayName().

function yourName(name) {
    var sayName = function() 
                     alert(greet); // still can access greet, As 
                   }             // inner function has access on all local variables  
                              //of outer function. 
         var greet = 'Hello ' + name; 
          return sayName; 

Hopefully you have enjoyed this post. Happy coding. 🙂

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. 🙂 🙂 😀