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




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

struct TestStruct
{
    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);
    }
};
template.cpp
#include "template.h"

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()
{
    BaseClass baseClass;

    unsigned int value = 10;
    TestStruct testStruct;

    baseClass.callFunction(testStruct);
}
 so what, what, what was happeningggggg

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!