Thursday, February 9, 2017

Evolution of a Software Engineer coming from a different engineering background...


When i look at my progress as a software developer who came into this world from a different engineering background, i clearly see few major stages of learning process and i think many of the engineers who came into software from a background other than CS would agree to it... First i had to learn the concepts of programming language... And mind it, had it been procedural languages of earlier days, it would have been one story... But with the advent of OOAD the whole ballgame of learning programming concept had changed... To work independently i not only had to master the syntactical parts of the languages like C++ or Java but also the concepts of OOPS... Here i had to learn from varied parts of a language starting from VTBLE in C++ to inheritance concepts to alignment in memory of an user defined data type and data structure... And believe me its not easy... It took years to master only this part of the learning curve...Then i had to master subjects like UML and Design Pattern to wisely apply my OOAD knowledge for a practical purpose... And again it took a lot of perseverance to do this... Then i had to know about a OOPS framework and figure out where my OOPS knowledge may fit... For me i started my software journey with the MS MFC/VC++ framework...

However this was just the beginning... After learning the nitty gritty of a language, and by nitty gritty i mean even understanding the compilation error, i had to delve into the world of OS and had to pick up the real CS areas like threads, process, multithreaded application, thread synchronization, scheduler and other concepts... And then i became a little useful in the real software developement...

In the meantime, i wanted to foray into a specific domain like mobile domain, and for that i had to constantly search for what is going on in this space... it was not easy to mix up the telecommunication part of the industry with the software that drives that telecommunication world... i never got a chance to go into the core telecom side of the software and their management but i was lucky enough to be a part of the mobile apps world... And even after coming into the mobile world i had to switch over from a Symbian C++ engineer to an Android/Java engineer... And to learn Android at a basic minimal level i had to burn lot of midnight oil in front of Google to decipher the Android framework code like the Android service internals, Android mediaplayer framework or Android Asynctask nitty gritty etc... It took lot of patience and perseverance to master only a little portion of Android...

And these days when i am upskilling myself with the knowledge of Computer Vision and related subjects, i am again going through the old engineering concepts of mathematics and statistics like Matrices, bell curve, Gaussian noise, Gaussian filter and so many things... However this is just the tip of the iceberg vis-a-vis Computer Vision and AI... i know i have to go a long way to be useful in this world of computation... But frankly speaking the real joy of learning has started... i no longer worry about the programming syntaxes, but the real picture of the end technology...

So enjoying real programming after a long period of struggle... Here is one of my videos showing how i am getting my hands dirty in subjects like Computer Vision... This video is about how to use Gaussian filter to remove noise from an image...

https://youtu.be/dyczVYQOcFQ

Tuesday, January 10, 2017

Copy-on-Write

Wednesday, June 22, 2016

Paradigm shift in the World of Mobile Computing...

Since the day of July 1991 when the GSM network was first made operational in Finland lot of things have changed. In earlier days of Mobile Communication, the communication part was important and it was the most challenging part of mobile computing. Lots of research had taken place to develop Mobile Switching Center, Base Station Controller etc. Not only that, lots of inputs have been made to define how the different MSC’s will communicate with each other and how the interfaces between different parts of the network elements like Um, Abis, B interface, C interface will function. In those days, stresses were given to define Traffic Channel and Signalling Channel. Common Control Channel (CCCH) or Dedicated Control Channel (DCCH) were more important than the mobile device itself. Modulation and technologies like Frequency Hopping Spread Spectrum were more important than the voice and data itself. But days have changed. Once the telecommunication part of the mobile computing is more or less established and the OFCN is laid down, the focus is now on the usefulness of the data and the voice itself or what we do with the data that are being transmitted over the network. The focus has shifted from the network part to the mobile device part. And with the advent of smartphones, it is the Apps that have become more important than any other parts of the mobile ecosystem. The apps have created a complete paradigm shift in the mobility world and it is taking the world of mobility to a different concepts altogether. From late 2007 to approximately 2010 were the years when mobile apps became multi billion dollar business. And it forced every organization to take a policy that is called Mobility First policy. It means that for each and every service that a company offers, it first takes care of the mobile platform. And the latest paradigm shift in the mobility world is the mobile social computing. We have seen the proliferation of social apps like Facebook, Google Plus, Instagram, LinkedIn, Twitter and so many others and i can say that these apps are shaping the behaviors of the mobile users.

With this ever changing mobile world the engineers also had to align themselves accordingly. For example i started my career as a Telecommunication engineer in SIEMENS India and now working on Android platform after working on other mobile OS like Symbian S60. And to do that i had to unlearn many things related to mobile network world and relearn software like C++, Java, Design Pattern, UML and such things. So here i am now. I was able to successfully transform myself from a telecommunication engineer to a mobile software engineer and presently working on Android. Probably many people of my age who started their career in 1994-95, have undergone such transformation. There were always some teething problems in this change management, but i feel happy that i have seen the world of mobile telecommunication changing in front of my eyes…..

Friday, June 3, 2016

Android Graphics & Animation

Here are my Youtube tutorial videos explaining Android Graphics and Animation. Hope you will  enjoy it.














Wednesday, November 25, 2015

Concurrent Programming in Android - Part II

Note : Here are my two tutorials on Android Concurrency Model. Please have a look at these:
  1. https://youtu.be/zWdVVI7kH4E
  2. https://youtu.be/1J6iqKJgvDU
In the part - I of the discussion on concurrent programming in Android, we have seen about the Handler-Message-Runnable & Asynchronous task framework. There we took a case study of downloading an image from an Internet server and found out how these methodologies can be applied for a long running task which has to be done in a background thread.

With the continuation of the same discussion we will today talk about the internals of the Android Concurrency Model - particularly about the topics like Looper, Message Queue, Handler and and how they work together to give us a better concurrent system. We will also develop an example in which we will pass a message from the main UI thread to a background worker thread immediately after the worker thread is created. We will also see the usefulness of the Java Synchronization technique, specifically the CountdownLatch synchronization object.

Here is a simplified diagram of Asynchronous Model of Android which shows how we can post Runnables or send Messages through Handler to the MQ of the Looper.



At the heart of any UI driven model, lies a loop called Message Loop whose task is to listen to any hardware events that the user may generate and dispatch them to the appropriate handler. In android this message looping is done by a class called Looper. The simpler version of the Looper class is as follws:

public class Looper {
    private static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
    // Looper message queue
  final MessageQueue mQueue;
    // The current thread
    Thread mThread;
    // . . . Other attributes
    // The message queue for each Looper object, and it belongs to the thread
    private Looper() {
        mQueue = new MessageQueue();
        mRun = true;
        mThread = Thread.currentThread();
    }
    // Initialize the current thread as a looper.
    public static final void prepare() {
        if (sThreadLocal.get() != null) {
            // Try to have Looper thread again to create the Looper will throw an exception
            throw new RuntimeException("Only one Looper may be created per thread");
        }
        sThreadLocal.set(new Looper());
    }
    // Other methods 
}

Important function of Looper is prepare.

As we can see from the above code that the prepare function actually constructs the Message Queue responsible for queuing up messages. Also in the prepare function we can see that there will be only one looper per thread. The looper gets stored as a Thread Local Storage object. And as we can see, the thread in which the Looper.prepare is called, becomes the looper's mThread object.

The other important function of the Looper class is the loop method. It has been defined as follows:

//Run the message queue in this thread.
public static void loop() {
//Other code
final Looper me = myLooper();//returns the current looper
//other code......
 for (;;) {
            Message msg = queue.next(); // might block
            if (msg == null) {
                // No message indicates that the message queue is quitting.
                return;
            }
//other code...........
 msg.target.dispatchMessage(msg);
//other code....

Have a look infinite for loop and the following dispatchMessage method. This is what is responsible for listening events and dispatching those messages to the right handler.

Next important Class is the Handler class. The bare minimal version of this Handler class is as follows:
public class Handler {
    final MessageQueue mQueue;  // The associated MQ
    final Looper mLooper;  // The associated looper
    final Callback mCallback; 
    // Other attributes
    public Handler() {
//Other code ......
        // The default will be associated with the current thread looper
//returning the Thread Local storage's Looper
        mLooper = Looper.myLooper();
        // Looper cannot be empty, the construction method of the default can only be used on the looper thread
        if (mLooper == null) {
            throw new RuntimeException(
                "Can't create handler inside thread that has not called Looper.prepare()");
        }
       //Associating the MQ with the Looper
        mQueue = mLooper.mQueue;
        mCallback = null;
    } 
    // Other methods
}

The handler class is a utility class and is responsible to help users to send messages to the Message queue. If we take the current thread's Handler to send message, the messages will be posted to the current thread's looper's Message Queue.

The main thread or the UI thread of Android will automatically have a looper. But if we want to create an worker thread, we need to specifically add the Looper for that thread. The below code is an example of such an worker thread. Lets call it as LooperThread.

class LooperThread extends Thread {
    public Handler mHandler;
    public void run() {
      Looper.prepare();
//Other works such as handler      
mHandler = new Handler() {
          public void handleMessage(Message msg) {
              // process incoming messages here
         }
      };
      Looper.loop();
   }
}

As we can see from the above code snippet, the moment we declare the above piece of code in any Android worker thread, it becomes capable of handling incoming messages.

Its all theories. Now lets write an example of sending messages from the UI thread of Android (or Activity) to a background thread. You can download the source code from here

The WorkerThread class is defined as follows:

/**
 * Created by som on 24/11/15.
 */
public class WorkerThread extends Thread{

    public Handler workerThreadHandler;
    CountDownLatch mLatch;

    public WorkerThread(CountDownLatch latch){

        mLatch = latch;
    }


    public void run() {
        Looper.prepare();
        workerThreadHandler = new Handler() {
            @Override
            public void handleMessage(Message msg) {

                Log.i("MsgToWorkerThread", "Message received from UI thread...");
                        MainActivity.getMainApp().runOnUiThread(new Runnable() {

                            @Override
                            public void run() {
                                Toast.makeText(MainActivity.getMainApp().getApplicationContext(), "Message received in worker thread from UI thread", Toast.LENGTH_LONG).show();
                                //Log.i("MsgToWorkerThread", "Message received from UI thread...");
                            }
                        });

            }

        };
        Log.i("MsgToWorkerThread", "Worker thread ready...");
        mLatch.countDown();
        Looper.loop();
    }
}

 And the MainActivity from where the message is sent to the WorkerThread is defined as follows:

public class MainActivity extends AppCompatActivity {

    private static MainActivity mainApp;
    private CountDownLatch mCountDownLatch;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);
///.....................Other Code......////
        mCountDownLatch = new CountDownLatch(1);
        mainApp = this;
        WorkerThread workerThread = new WorkerThread(mCountDownLatch);
        workerThread.start();
        try {
            mCountDownLatch.await();
            Log.i("MsgToWorkerThread", "Worker Thread is up and running. We can send message to it now...");
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        Toast.makeText(this, "Trial run...", Toast.LENGTH_LONG).show();
        Message msg = workerThread.workerThreadHandler.obtainMessage();
        workerThread.workerThreadHandler.sendMessage(msg);
        //Toast.makeText(this, "Trial run...", Toast.LENGTH_LONG).show();
    }

This is simple. Only one issue that i would like to discuss about that to avoid the Race Condition, i have used the Java Synchronization object CountdownLatch. For this countdownlatch, we send the message only when the worker thread becomes ready.
Hope i am able to throw some lights on the internals of Android Concurrency Model.

Share