There is something like that... But I'm not sure if it works for daemons. Maybe adding a dummy executable that would 'handle' certain tags could work, but that seems quite hackish solution.

Ideally I would like that for all tag uids that have been entered to ProfileMatic, I could tell to the system that "these are handled, don't show thy redundant message". But I couldn't see any APIs that clearly does that.

I will need to experiment with it a bit... throw ideas if you have them, maybe something sticks.

what about write something to the tag , like the name of the rule as text format , so i just guessing that the nfc api will not tell that is empty and maybe profilematic can handle it in some way...

True, it does not tell that it is empty. Instead the system tells it can't handle such tag .

check this app:
https://gitorious.org/nfctagtool/nfc...l/trees/master
i can handle text

not sure if you already read this , but maybe have some clue:
http://doc.qt.nokia.com/qtmobility/q...ldmanager.html

Unfortunately it's not that straight forward. I've tested many of these apps, and the crux of the situation seems to be this:

If an application using NFC is in the foreground, the system only complains about an empty tag. But if the tag has for example text or other content, it doesn't complain that the tag couldn't be handled. However, if there is no application in the foreground that handles NFC, it will complain about not being able to handle the tag.

It can be easily reproduced even with ProfileMatic. If you're collecting tags in the NFC condition page, only empty tags raise the message. Tags that have, for example, Text record do not raise the message.

Now the problem of course is that ProfileMatic's daemon is never in the foreground. So even as it can handle the tag, system will raise the message.

It begins to look like the ugly hack of installing a dummy handler for some tag type (Text maybe?) is the only solution.

maybe i don't have a clue about what i am talking about but im trying read the profilematic code ( i know almost nothing about qt or C++ ) and reading the API and i don't se where you set the enum property of targetaccessmode something like:

public:
enum TargetAccessMode {
NoTargetAccess = QNearFieldManager::NoTargetAccess,
NdefReadTargetAccess = QNearFieldManager::NdefReadTargetAccess,
NdefWriteTargetAccess = QNearFieldManager::NdefWriteTargetAccess

where QNearFieldManager::NoTargetAccess is
"The application cannot access NFC capabilities."
so don't try/fire the notification error about not know how handle the tag content.

First of all thanks for taking the extra step to look at the code! You read it correctly.

I don't think setting those modes will help, since the ProfileMatic's UI uses the same kind of code. And as I wrote earlier, if you have ProfileMatic's UI open on the NFC condition page and tap a tag with content then system doesn't display the message. But if it's in background, system gives the message. So it seems to be related to whether there is a NFC application in the foreground if that message is displayed or not.

But, I will nevertheless try if setting target access mode would help.

What if you approached Nokia with an enhancement/bug request so that maybe they include it in the next update hopefully

That isn't an option unfortunately, the next update will probably be the last and it has been frozen for a month or so. The bugzilla no longer accepts new bugs the only update we will get now is if a security breach needs to be closed similar to what they did on the N900 with PR1.3.1