i posted the code for the android app i mentioned earlier in github here: https://github.com/esdee-git/missed-calls
since the app itself was my coding test for android platform, a good decision was to use it as test of github :)
must say that github's windows app is pretty cool, although i thought it was capable to do more - tortoiseSvn style maybe? still checking things around so it may turn more powerful yet, for now i'll do mostly with the git console
grasping git easier as i have svn experience, but i realise the two differ a lot, but i guess it is mostly on a higher/architecture level
in any case, it would be nice if someone found the code useful, and maybe even make it better
enjoy and a Happy New Year
2013 yeyyyy!
Tuesday, January 01, 2013
Thursday, October 04, 2012
my first complete android app
well, what can i say - it is fun to program for android; i enjoy java and the android apis are ok.
my own android phone is quite old, running android 1.5 so i had to write for api level 3.
i see some improvements in the following apis, when i have time i'll probably try to root and upgrade to 2.1 (no intention to buy a new phone yet).
what else can i say - eclipse is great! so great, i started using it at work, instead of kdeveloper. it definitely is an accomplished platform
on the app itself - it irritated me that there was no sound notification for missed calls, so i thought, why not write one myself (it is only a few days ago, about 4 months since i started working on and off on this app that i found out that there already were couple of solutions for this on the droid market - which is absolutely not surprising).
first of course there was the alarm manager api, but i quickly dismissed it.
i decided to go with a service that checks the status of the calls periodically. but how often should this period reoccur? what if we miss some important notifications?
so i decided to hook the incoming calls intent (actually PhoneStateListener). this worked quite well - after the call is finished, if it wasn't answered my app plugged in and started sounding the alarm every few seconds.
this eventually completed the flow.
there was something strange that i observed. actually the biggest horror a developer may stumble upon - the app worked fine in the emulator, but occasionally when deployed on the phone it wouldn't pick the missed call and remain in obscure state.
so what do you do when you don't know what you program does? hook a logger and watch what your program says it is doing. after some staring at the logger output, it turned out that the system database i read phone calls from (android.provider.CallLog.Calls) registers the (missed) call a few seconds later than the call occured. unfortunately this mismatches the app's own timeline and so - the notification never gets to be fired. the fix was to wait a few seconds before quering the database.
so now i have some more confidence in my app and can show it to the world. i don't think anyone will pay attention, but the satisfaction of getting to "do something" and bring it to completion is priceless.
now if i can only find my way around to actually figuring out how to publish to google play market...
my own android phone is quite old, running android 1.5 so i had to write for api level 3.
i see some improvements in the following apis, when i have time i'll probably try to root and upgrade to 2.1 (no intention to buy a new phone yet).
what else can i say - eclipse is great! so great, i started using it at work, instead of kdeveloper. it definitely is an accomplished platform
on the app itself - it irritated me that there was no sound notification for missed calls, so i thought, why not write one myself (it is only a few days ago, about 4 months since i started working on and off on this app that i found out that there already were couple of solutions for this on the droid market - which is absolutely not surprising).
first of course there was the alarm manager api, but i quickly dismissed it.
i decided to go with a service that checks the status of the calls periodically. but how often should this period reoccur? what if we miss some important notifications?
so i decided to hook the incoming calls intent (actually PhoneStateListener). this worked quite well - after the call is finished, if it wasn't answered my app plugged in and started sounding the alarm every few seconds.
this eventually completed the flow.
there was something strange that i observed. actually the biggest horror a developer may stumble upon - the app worked fine in the emulator, but occasionally when deployed on the phone it wouldn't pick the missed call and remain in obscure state.
so what do you do when you don't know what you program does? hook a logger and watch what your program says it is doing. after some staring at the logger output, it turned out that the system database i read phone calls from (android.provider.CallLog.Calls) registers the (missed) call a few seconds later than the call occured. unfortunately this mismatches the app's own timeline and so - the notification never gets to be fired. the fix was to wait a few seconds before quering the database.
so now i have some more confidence in my app and can show it to the world. i don't think anyone will pay attention, but the satisfaction of getting to "do something" and bring it to completion is priceless.
now if i can only find my way around to actually figuring out how to publish to google play market...
Tuesday, October 02, 2012
fun with specialized function templates in c++
i was quite sad a few days ago for a reason some of you may be familiar with all to well:
a program was working fine in debug, but didn't return results in release build. luckily this was not in production (phew).
what valgrind said was that some variables weren't initialized. my setup is such that i had to refactor a templated class and add a few templated methods, which were specialized in a few locations. everything built fine and seemingly the workflow shouldn't have allowed for uninitialized variables when the specialized function templates were called. eventually and only in the impossible case that the base template function was called. which was impossible to happen, because the compiler would now to instantiate the correct specialization, right?
right, but not exactly. a few debug prints proved that in release the impossible happened - the base template function was called instead of the specialization. but why??
all the arguments should be giving clear directions to the compiler which function to create and call, so why wasn't it? why my beautifully crafted specialization functions were not called??!!
ok, i tried not specializing, but overloading - something similar to this GOTW, but it didn't quite fit, so on went the struggle making the compiler SEE the specialized templates. what if the argument is not const, what if the number of argument varies, what if the return value is different.
but you have to remember that in debug build everything works fine, so then the compiler does know about the specialization and invokes it, so it isn't the code, may be it is in the compiler settings, or the linker? or the compiler it self??
btw, a simple test case that is similar to the situation worked fine in debug and release:
template.h
the evident conclusion is in release the compiler decides to ignore the specializations, so can we help it see and use them? turns out the solution is so simple i had to kick myself in the backspace i missed it:
forward declare the specializations in the code location were they will be used
yep, somehow this solved it. i know, it is probably on first page of the book C++ templates 101, but well, how often do you have to write explicitly specialized template functions that will be used in a templated class where one of the template arguments is a function, and the other is the return value of the function?
me, not very often
good luck, keep coding!
a program was working fine in debug, but didn't return results in release build. luckily this was not in production (phew).
what valgrind said was that some variables weren't initialized. my setup is such that i had to refactor a templated class and add a few templated methods, which were specialized in a few locations. everything built fine and seemingly the workflow shouldn't have allowed for uninitialized variables when the specialized function templates were called. eventually and only in the impossible case that the base template function was called. which was impossible to happen, because the compiler would now to instantiate the correct specialization, right?
right, but not exactly. a few debug prints proved that in release the impossible happened - the base template function was called instead of the specialization. but why??
all the arguments should be giving clear directions to the compiler which function to create and call, so why wasn't it? why my beautifully crafted specialization functions were not called??!!
ok, i tried not specializing, but overloading - something similar to this GOTW, but it didn't quite fit, so on went the struggle making the compiler SEE the specialized templates. what if the argument is not const, what if the number of argument varies, what if the return value is different.
but you have to remember that in debug build everything works fine, so then the compiler does know about the specialization and invokes it, so it isn't the code, may be it is in the compiler settings, or the linker? or the compiler it self??
btw, a simple test case that is similar to the situation worked fine in debug and release:
template.h
struct TestStructtemplate.cpp
{
int intValue;
char * charValue;
public:
TestStruct() : intValue(0), charValue(NULL) {};
};
template
unsigned int templatedFunction(const T& value)
{
assert(false && "not implemented");
return std::numeric_limits::max();
}
template
class BaseClass
{
public:
void callFunction(const CC& value)
{
templatedFunction(value);
}
};
#include "template.h"so what, what, what was happeningggggg
template <>
unsigned int templatedFunction(const unsigned int& value)
{
printf("implemented for unsigned int");
return std::numeric_limits::max();
}
template <>
unsigned int templatedFunction(const TestStruct& value)
{
printf("implemented for testStruct");
return std::numeric_limits::max();
}
int main()
{
BaseClassbaseClass;
unsigned int value = 10;
TestStruct testStruct;
baseClass.callFunction(testStruct);
}
the evident conclusion is in release the compiler decides to ignore the specializations, so can we help it see and use them? turns out the solution is so simple i had to kick myself in the backspace i missed it:
forward declare the specializations in the code location were they will be used
yep, somehow this solved it. i know, it is probably on first page of the book C++ templates 101, but well, how often do you have to write explicitly specialized template functions that will be used in a templated class where one of the template arguments is a function, and the other is the return value of the function?
me, not very often
good luck, keep coding!
Tuesday, June 26, 2012
log4cxx insights
i really liked log4cxx and while i did a thorough research, turned out there were a few things i hadn't realised log4cxx featured or was capable of
- hierarchy is awesome, i had used it with test cases like
log4j.logger.main=ERROR, console, file
log4j.logger.main.another=INFO
where`another` inherits console and file appenders from `main`
but i hadn't realised that if `another` featured, well, another console appender, then the log message would be displayed twice - once for the console appender from `main` and once from `another`
log4j.logger.main.another=INFO, console2
the way to avoid this is to tell log4cxx we don't want the child to inherit any appenders from the parent, like this -
log4j.additivity.main.another=false
it is actually quite evident from the quick tutorial on the log4cxx site, but i guess i kindda missed that
- different log levels for each appender - now i really hadn't realised that log4cxx was capable of this: when you want console to print all messages, but file output would feature only errors
turns out this can be easilly done with
log4j.appender.console.Threshold=TRACE
log4j.appender.file.Threshold=ERROR
isn't this beautiful!!
there hasn't been official release for log4cxx for quite a few years which might be startling, but then this library is so awesome, i'd rather risk and use it in production then go for another one, or (no way) write a custom framework...
- hierarchy is awesome, i had used it with test cases like
log4j.logger.main=ERROR, console, file
log4j.logger.main.another=INFO
where`another` inherits console and file appenders from `main`
but i hadn't realised that if `another` featured, well, another console appender, then the log message would be displayed twice - once for the console appender from `main` and once from `another`
log4j.logger.main.another=INFO, console2
the way to avoid this is to tell log4cxx we don't want the child to inherit any appenders from the parent, like this -
log4j.additivity.main.another=false
it is actually quite evident from the quick tutorial on the log4cxx site, but i guess i kindda missed that
- different log levels for each appender - now i really hadn't realised that log4cxx was capable of this: when you want console to print all messages, but file output would feature only errors
turns out this can be easilly done with
log4j.appender.console.Threshold=TRACE
log4j.appender.file.Threshold=ERROR
isn't this beautiful!!
there hasn't been official release for log4cxx for quite a few years which might be startling, but then this library is so awesome, i'd rather risk and use it in production then go for another one, or (no way) write a custom framework...
Wednesday, May 02, 2012
simple android service not starting
i'm new to android.
but it seems a nice platform so far.
been away from java for quite some time and find some syntax shortcuts are quite amazing but on the problem at hand;
i wanted to write a very simple test service and eventually settled for this scenario:
- start an activity
- on button click the activity starts a service
- thats it!
and this gave me hours of grinding google and stackoverflow, because this very simple service never seemed to start
one of the first issues was "newinstance failed no()" that was quite easy to solve thanks to http://stackoverflow.com/questions/2120699/newinstance-failed-no-init. but then non of the debug loggers i put through out the code seemed to be fired
i the service i had onCreate(), onStartCommand(), onStart() and none was ever triggered
i had big suspicions on the AndroidManifest.xml as it is still quite a blank area for me. startService() returned Null whatever i passed to it.
my service was declared in the file that countained the activity so the name i tried to input as service android:name were like mainNamespace.Activityname.ServiceName, but this didn't work, nor did mainNamespace.ServiceName, not any of the other attempts
to save some hdd space on the blog host - i moved the code of the service outside the file containing the activity class, added new service name in the manifest xml and suddenly i started seeing the debug messages i waited to see for quite some time!
so what was i doing wrong? what should've been the name of the service in the manifest xml for the service class contained within the same file? or was it the naming in the Intent constructor?
just another android mystery
by the way, i had a glimpse of some iOs code, and must say i was startled to extent of appalled - is this C++, or some attribute based language, how do you program in this? maybe i've seen only some weird bits of code, i don't know - but i was hoping for some clean C++ code (Objective-C?) and didn't see any
bye..
oh yes - some helpful links, these were very helpful in grabbing some basic knowledge and sample code
- http://zaman91.wordpress.com/2010/04/22/android-how-to-start-a-service-in-application/
- http://marakana.com/forums/android/examples/60.html
- http://stackoverflow.com/questions/4480340/sample-alarmcontroller-application-service-registeration-in-androidmanifest
but it seems a nice platform so far.
been away from java for quite some time and find some syntax shortcuts are quite amazing but on the problem at hand;
i wanted to write a very simple test service and eventually settled for this scenario:
- start an activity
- on button click the activity starts a service
- thats it!
and this gave me hours of grinding google and stackoverflow, because this very simple service never seemed to start
one of the first issues was "newinstance failed no
Sunday, September 25, 2011
linux threads and forking (and zeroc ice)
so we have this nice icegrid setup with python nodes tied with sip to underlying c++ code. on new rpc call, ice creates a new thread to handle it, but as the underlying c++ code is not threadsafe we fork from this thread and continue execution in a new process.
everything works perfectly, but one day we decide to remove the python layer and go with c++ all the way
and then something weird started happening - forked processes started hanging, crashing, a total mess...after some research we found out several articles mentioning that it is a bad idea to mix linux threads and forks because of possible copied locked mutexes in the child process and this is exactly what we had observed.
so how we solve this? and why the python+cpp solution worked fine?
as a second solution we modified our code to use a thin python wrapper again over the main c++ functionality in attempt to copy the behavior from the original solution, but again the forked child processes had copied locked mutexes that caused them to hang
so, how come? in the original solution A the underlying code is pretty much the same as B and C, what appears is that some ice threads are calling localtime_r in the moment when we fork and when the forked code tries to execure localtime_r it locks.
but why does it not happen in the original python/cpp solution? why does it happen in the new python/cpp solution? are there some python flags to help avoid this? the original code would spend some time jumping from python to cpp, while the new code would only enter cpp code once and return the results.
in any case it seems a mess so we went for another completely different solution, but the headache was/is huge
everything works perfectly, but one day we decide to remove the python layer and go with c++ all the way
and then something weird started happening - forked processes started hanging, crashing, a total mess...after some research we found out several articles mentioning that it is a bad idea to mix linux threads and forks because of possible copied locked mutexes in the child process and this is exactly what we had observed.
so how we solve this? and why the python+cpp solution worked fine?
as a second solution we modified our code to use a thin python wrapper again over the main c++ functionality in attempt to copy the behavior from the original solution, but again the forked child processes had copied locked mutexes that caused them to hang
so, how come? in the original solution A the underlying code is pretty much the same as B and C, what appears is that some ice threads are calling localtime_r in the moment when we fork and when the forked code tries to execure localtime_r it locks.
but why does it not happen in the original python/cpp solution? why does it happen in the new python/cpp solution? are there some python flags to help avoid this? the original code would spend some time jumping from python to cpp, while the new code would only enter cpp code once and return the results.
in any case it seems a mess so we went for another completely different solution, but the headache was/is huge
Saturday, April 30, 2011
using apache qpid with persistence
that's just a quick post about two weeks struggle with a problem which was eventually solved in half an hour.
as at my company we (i) decided to use apache QPID as a message queue framework, we certainly needed to use persistance for a queues and messages. building qpid itself was really easy and straight forward, and for building the persistance module msgstore.so i was following the directions posted at Lahiru Gunathilake's Blog here. i build the whole setup on my local machine and everything was working just perfectly - messages were sent persitently, queues were durable etc.
then i started deploying on the dev servers
the qpid broker started crashing on startup.
the qpid broker started crashing on startup.
the qpid broker started crashing on startup.
and on and on and on
it was easy to detect that the problem appeared when the broker was started with --load-module=msgstore.so and that it seg faulted when attempting to create a berkeley db database. but why??
well...on my local machine i am running fedora, and the dev server rules with CentOs.
my fedora has berkeley db 4.8 and the server has 4.5. this was the first 'ding'.
now, how to trick the qpid configure into using db4.8 instead of db4.5? we couldn't just install the new libs as there might have been incompatibilities with the product, so what to do? we tried modifying configure scripts, playing with sym links etc - i myself don't have much experience with linux so was relying mostly on the admin guy, but he was helpless with this too - seg fault after segfaul, while on my machine the broker hummed silently, transfering persistant messages and maintaining durable queues.
then after a loooot of reading we came to an obvious solution - the qpid configure itself gave it too us, and hadn't i been too shortsighted, this would have been done days ago -
just build berkeley 4.8 with --perfix to place it in a separate directory (say $BDB48), away from the db4.5 libs the product needs, and then, before running qpid configure, run these
(i'm writing these by memory, check qpid's configure script with --help to see the correct ones)
after that run configure and it will find and use the berkeley libs you wanted it too!
awesome!
now lets do the same in production where we have RedHad 5. BOOM! here goes the so familiar seg fault that we managed to escape by the clever export trick. why? what is so different on redhat???
another week of research, testing, breaking, hair-tearing followed, this time with no result.
i was even contemplating to run a virtual fedora machine on the redhat server, just and so to have the familiar setup and start the broker with persitancy there.
luckily i didn't have to -
one day i sat with the it manager to explain him the situation and while we were scratching our heads we looked at persistance module's readme.txt where it said that it was tested with berkeley db 4.3.
so what? we have db4.8 and it should be fine, right?
what if we gave it another try, but not with the 4.8, but 4.3 set-up the same way?
this took about10 minutes to setup and when i hit 'enter' for qpidd --load-module=msgstore.so, before my eyes was the beautiful log dump, saying that the module was loaded and so on and so on ....
aaah....rtfm? the thing is we actually tested db4.3 when facing the initial problem of setting up the dev servers. this failed somehow, and so we didn't consider this when fighting with production setup
anyways - this post grew as long as the first two episodes of "game of thrones" that i watched today :D
have a good night and don't give up the fight!
as at my company we (i) decided to use apache QPID as a message queue framework, we certainly needed to use persistance for a queues and messages. building qpid itself was really easy and straight forward, and for building the persistance module msgstore.so i was following the directions posted at Lahiru Gunathilake's Blog here. i build the whole setup on my local machine and everything was working just perfectly - messages were sent persitently, queues were durable etc.
then i started deploying on the dev servers
the qpid broker started crashing on startup.
the qpid broker started crashing on startup.
the qpid broker started crashing on startup.
and on and on and on
it was easy to detect that the problem appeared when the broker was started with --load-module=msgstore.so and that it seg faulted when attempting to create a berkeley db database. but why??
well...on my local machine i am running fedora, and the dev server rules with CentOs.
my fedora has berkeley db 4.8 and the server has 4.5. this was the first 'ding'.
now, how to trick the qpid configure into using db4.8 instead of db4.5? we couldn't just install the new libs as there might have been incompatibilities with the product, so what to do? we tried modifying configure scripts, playing with sym links etc - i myself don't have much experience with linux so was relying mostly on the admin guy, but he was helpless with this too - seg fault after segfaul, while on my machine the broker hummed silently, transfering persistant messages and maintaining durable queues.
then after a loooot of reading we came to an obvious solution - the qpid configure itself gave it too us, and hadn't i been too shortsighted, this would have been done days ago -
just build berkeley 4.8 with --perfix to place it in a separate directory (say $BDB48), away from the db4.5 libs the product needs, and then, before running qpid configure, run these
export CPP_PATH=$BDB48/include
export LIB_PATH=$BDB48/libs
(i'm writing these by memory, check qpid's configure script with --help to see the correct ones)
after that run configure and it will find and use the berkeley libs you wanted it too!
awesome!
now lets do the same in production where we have RedHad 5. BOOM! here goes the so familiar seg fault that we managed to escape by the clever export trick. why? what is so different on redhat???
another week of research, testing, breaking, hair-tearing followed, this time with no result.
i was even contemplating to run a virtual fedora machine on the redhat server, just and so to have the familiar setup and start the broker with persitancy there.
luckily i didn't have to -
one day i sat with the it manager to explain him the situation and while we were scratching our heads we looked at persistance module's readme.txt where it said that it was tested with berkeley db 4.3.
so what? we have db4.8 and it should be fine, right?
what if we gave it another try, but not with the 4.8, but 4.3 set-up the same way?
this took about10 minutes to setup and when i hit 'enter' for qpidd --load-module=msgstore.so, before my eyes was the beautiful log dump, saying that the module was loaded and so on and so on ....
aaah....rtfm? the thing is we actually tested db4.3 when facing the initial problem of setting up the dev servers. this failed somehow, and so we didn't consider this when fighting with production setup
anyways - this post grew as long as the first two episodes of "game of thrones" that i watched today :D
have a good night and don't give up the fight!
Subscribe to:
Posts (Atom)