Thursday, February 18, 2010
A lot to write about....
...but no time to write it. Will write a long one after exams which end next Friday. Till then, must study, must study, must study....
Thursday, February 11, 2010
OCS# and Custom Invitations
Some time back I checked out an interesting project called Social Web for the KDE desktop. It brings the power of social networking into normal desktop apps. The back end of this systems is a REST based API called Open Collaboration Services. Although there is a QT based C++ binding for it called Attica, I thought it might be fun to whip up a C# binding for the library. And while I am at it, an Android client as well? ;)
Its quite fun to think about the kind of apps one could dream up using OCS. If normal desktop apps integrate OCS into their services, one would not need to start their browser, go to facebook or myspace or whichever social site they are a member of, login and access their apps. You could do all that from your desktop itself. Consider a music player. Say you really liked a particular song and want it to appear on the recommendation listing of your friends. All you have to do is mark it with a 5 star rating and make that data public. The backend will post this data to your profile on the web using OCS and your friends can pull this data as and when they need it. Creating a robust recommendation on top of this system should then be a pretty easy task.
Also I am taking care of custom messages in SMS Invite. I had a solution using XML in mind but I have not really started off on it yet. Lets see where this goes...
Its quite fun to think about the kind of apps one could dream up using OCS. If normal desktop apps integrate OCS into their services, one would not need to start their browser, go to facebook or myspace or whichever social site they are a member of, login and access their apps. You could do all that from your desktop itself. Consider a music player. Say you really liked a particular song and want it to appear on the recommendation listing of your friends. All you have to do is mark it with a 5 star rating and make that data public. The backend will post this data to your profile on the web using OCS and your friends can pull this data as and when they need it. Creating a robust recommendation on top of this system should then be a pretty easy task.
Also I am taking care of custom messages in SMS Invite. I had a solution using XML in mind but I have not really started off on it yet. Lets see where this goes...
Saturday, February 6, 2010
Antibiotics and antihistamines
I have fallen ill thrice since the beginning of the new year. I recovered the last two times without taking any medicines but now I am not taking any chances. Primarily because I am running a fever and my throat's hurting. When this happens there is a chance that the infection will spread to the ear causing the worst suffering I could ever imagine. So I am currently taking Roxithromycin (150 mg) and Fexofenadine Hydrochloride. Roxithromycin is a broad spectrum antibiotic that takes care of most respiratory infections. Fexofenadine is an antihistamine, and is used as an antiallergen.
Anyway, all I can say is that never take good health for granted.
Anyway, all I can say is that never take good health for granted.
Wednesday, February 3, 2010
WeakAsyncTasks
My friend pointed out a very interesting construct used in the Android native app, Contacts.
I learned a couple of things along the way.
Firstly what are weak references? Well you need to know what is a strong reference. In Java, there is a garbage collector at work that removes dead objects from the heap. An object is dead when its reference goes out of scope.
So supposing I write a code
void foo()
{
myObj obj = new myObj();
// Do something
}
obj is my strong reference to an instance of the class myObj. When I am done with foo and return the flow of control to the function that called foo, it goes out of scope, and the memory allocated for that instance of the class myObj is garbage collected and freed.
As long as an object is reachable via a chain of strong references, it will not be garbage collected.
However there are some issues to consider. Suppose you want to track the number of objects in the program that are currently in play. Or suppose you want to assign serial numbers to instances of a class. Now although these problems can be easily solved by merely extending the classes in question, many a time that is not the case (in case the class is marked as final in Java or sealed in C#). So if you use, say a Hashmap to track the objects, you will have a strong reference to it. So when the object goes dead and should be garbage collected, it won't because of the strong reference to it. So despite the presence of a GC, the programmer will have to worry about when to garbage collect and has to perform manual memory management. Not good.
The solution to this conundrum is a weak reference. Simply put, having a weak reference to an object will not prevent it from being garbage collected. So if the hashmap stores weak references to live objects, once they go dead, you do not have to worry about the garbage collection. However you will have to poll the hashmap to see which objects have died and remove the corresponding weak references. So to save yourself the trouble, use the WeakHashmap generic.
Now what is an AsynTask. Asynchronous tasks in Android, are basically thread-like in their behaviour with a few key differences, they do not require you to worry about the complexities of threading and handlers, but you can call them ONLY from the UI thread. So you can perform background operations in the AsyncTask and then publish the result on the UI without holding up the UI thread.
A WeakAsyncTask allows you to perform asynchronous tasks on objects with weak references. Why is it required? Suppose you launch an AsyncTask , show a nice progress dialog while the AsyncTask is running, and have the progress result be posted back to your UI.
But what happens if the phone rings? Or you rotate your display? Your activity be terminated with extreme prejudice. But AsyncTask will continue to hold a stale reference to the object you created earlier, and although you cannot access it, the strong reference to that object within the AsyncTask will prevent it from being garbage collected. Also the result of the AsyncTask would have been posted to the original instance of your activity, but because it will have been restarted, AsyncTask will not post to this new instance and be effectively floating about in limbo. What we have here is essentially a memory leak.
This is where the WeakAsyncTask comes in. Since it has a weak reference to the target object, when the object is garbage collected, the WeakAsyncTask knows the target object has gone out of scope and will automatically terminate itself, thus solving the issue of memory leaks. This is a pretty useful class and I think it should be a part of the primary Android API.
I learned a couple of things along the way.
Firstly what are weak references? Well you need to know what is a strong reference. In Java, there is a garbage collector at work that removes dead objects from the heap. An object is dead when its reference goes out of scope.
So supposing I write a code
void foo()
{
myObj obj = new myObj();
// Do something
}
obj is my strong reference to an instance of the class myObj. When I am done with foo and return the flow of control to the function that called foo, it goes out of scope, and the memory allocated for that instance of the class myObj is garbage collected and freed.
As long as an object is reachable via a chain of strong references, it will not be garbage collected.
However there are some issues to consider. Suppose you want to track the number of objects in the program that are currently in play. Or suppose you want to assign serial numbers to instances of a class. Now although these problems can be easily solved by merely extending the classes in question, many a time that is not the case (in case the class is marked as final in Java or sealed in C#). So if you use, say a Hashmap to track the objects, you will have a strong reference to it. So when the object goes dead and should be garbage collected, it won't because of the strong reference to it. So despite the presence of a GC, the programmer will have to worry about when to garbage collect and has to perform manual memory management. Not good.
The solution to this conundrum is a weak reference. Simply put, having a weak reference to an object will not prevent it from being garbage collected. So if the hashmap stores weak references to live objects, once they go dead, you do not have to worry about the garbage collection. However you will have to poll the hashmap to see which objects have died and remove the corresponding weak references. So to save yourself the trouble, use the WeakHashmap generic.
Now what is an AsynTask. Asynchronous tasks in Android, are basically thread-like in their behaviour with a few key differences, they do not require you to worry about the complexities of threading and handlers, but you can call them ONLY from the UI thread. So you can perform background operations in the AsyncTask and then publish the result on the UI without holding up the UI thread.
A WeakAsyncTask allows you to perform asynchronous tasks on objects with weak references. Why is it required? Suppose you launch an AsyncTask , show a nice progress dialog while the AsyncTask is running, and have the progress result be posted back to your UI.
But what happens if the phone rings? Or you rotate your display? Your activity be terminated with extreme prejudice. But AsyncTask will continue to hold a stale reference to the object you created earlier, and although you cannot access it, the strong reference to that object within the AsyncTask will prevent it from being garbage collected. Also the result of the AsyncTask would have been posted to the original instance of your activity, but because it will have been restarted, AsyncTask will not post to this new instance and be effectively floating about in limbo. What we have here is essentially a memory leak.
This is where the WeakAsyncTask comes in. Since it has a weak reference to the target object, when the object is garbage collected, the WeakAsyncTask knows the target object has gone out of scope and will automatically terminate itself, thus solving the issue of memory leaks. This is a pretty useful class and I think it should be a part of the primary Android API.
Tuesday, February 2, 2010
Monodevelop Codemetrics
I have been working on the open source IDE, Monodevelop for some time now. The module I was working on was one that measured code quality using several metrics like, depth of inheritance and code source cyclomatic complexity. To do this, I had to use the NRefactory parser infrastructure and walk through the AST. A lof of cool things can be done with it.
Get it here!
http://code.google.com/p/monodevelopcodemetrics/downloads/list
Here are some screenshots.
The TreeView shows the classes in the projects. The right hand side column shows the depth of inheritance.
Expanding the TreeView you get the methods implemented within the class. The right hand side shows cyclomatic complexity.
Expandable inner entries are inner classes.
Get it here!
http://code.google.com/p/monodevelopcodemetrics/downloads/list
Here are some screenshots.
The TreeView shows the classes in the projects. The right hand side column shows the depth of inheritance.
Expanding the TreeView you get the methods implemented within the class. The right hand side shows cyclomatic complexity.
Expandable inner entries are inner classes.
Subscribe to:
Posts (Atom)