MMS / Observer

[lieuwe]

All,

I am fiddling around with a little Symbian app to see if I can catch and read MMS messages coming in on the phone. There does not seem to be much documentation around, but there are some whitepapers on this site describing the mechanisms (Using MMS on Symbian phones parts 1 -3) and an example as well (S60_Platform_MMS_Example_v2_1_en.zip). So I created this observer and just have it display what it receives while I send an MMS to my phone (an N95-8GB). What is ment to happpen (according to the documentation) is that you see a EMsvEntriesCreated event when the message arrives and a EMsvEntriesChanged event when the phone has (automatically) downloaded the MMS (both for the KMsvGlobalInBoxIndexEntryId - i.e. inbox). Now I am sending a simple MMS, just one picture and some text. What I see on the phone though is 2 EMsvEntriesCreated events (presumably the first one is the wap push notification) then about 7 or 8 EMsvEntriesChanged events and then a deleted event (that I guess is the notification being removed).

Could anyone explain, or point me to some relevant docs that describe the mechanism for retrieving MMS messages. Are there flags I can check to see which changed event is the last one (i.e. the message is now fully downloaded - the Complete() flag seems to be always set), and why do I get so many changed events? Is this because the MMS is being downloaded in stages? - ifso for the above example it should only download the SMIL and 2 attachments (text and picture) shouldn't it? - so what are all those change events about? I basically need to know at what stage the MMS is fully downloaded/accessable.

Another question. Out of interest, I get EMsvEntriesChanged events with the arg2 of the observer::HandleSessionEventL method (which is ment to be a TMsvId*) is not something I recognise. Is there a complete enum somewhere?

Thanks,

Lieuwe

[symbianyucca]

you could open the program in carbide and huighlight the EMsvEntriesChanged in it, then just click F3 and it will open the header where the enumeration is defined,so with that trick you could find the other enums easily.

And the MMS receiving monitoring can be done just as with SMS, and that is by monitoring the events in that HandleSessionEventL function.

[lieuwe]

Just pushing this one up, hopefully someone has any ideas.

I am still struggling with this HandleSessionEventL mechanism.

The above is called 3 times with the second argument set to KMsvGlobalInBoxIndexEntryId for each MMS that my N95-8GB receives.

Once where the event is EMsvEntriesCreated, but twice with an EMsvEntriesChanged event. All 3 have a CMsvEntrySelection first argument with Count() is 1, and the TMsvId for the entry in that selection is the same for all 3 calls.

I am interested in why the changed event is being called twice. When I create a CMsvEntry* iEntry from Session->GetEntryL(TMsvId), both calls report the iEntry->Entry() to be Complete() and Visible(). There must be a difference (it is after all a changed event) but I can't find it at the moment.

I want to process each MMS once as it comes in. I could obviously keep a counter on how many times each message gets a changed event and only process it after 2 calls (or alternatively, I could check the deleted event for the notification message that I receive), but surely I should be able to distinguish the 2 changed calls from one another.

On a sidenote, for an incoming SMS, I have only 1 created event and 1 changed event.

Any thoughts?

Lieuwe

[symbianyucca]

EMsvEntriesChanged is called each time a change occues, thus depending on the message and the implementation of the receiving component, it can indeed be called multiple times, and I think you can not actually assume that it would always be called excatly twice, thus if you want to care about it, you should make up a logic than can handle the changes on the messages you are interested in.

[lieuwe]

I think I'll just watch the Complete() flag (I think I can safely assume that this flag is correctly stating the fact that the whole message is there and ready)and process the message if that is ETrue. That does mean I have to keep track of the id's that I have processed in order not to process the same message multiple times. I tried deleting the message after the first changed event, but somehow the message didn't get deleted at all.

Lieuwe