Bug in iPhone client

[CarelZA]

When the EVO or other phone client opens an app, it either sends a blank Normal message or blank Chat message to the app. When the iPhone client opens an app contact, it sends a non-blank Normal message of length 1, I suspect it's just a space.

So basically there are at least three inconsistent ways for an app to estimate that a client just opened it.

Is this a bug in the iPhone client?

[DeepFreez]

I wonder if this can some how be used to detect an iOS client <grin> That would be very useful

[CarelZA]

I'd like to say yes, but I can see two reasons why it would be a bad idea:
1. If this is not a bug, maybe some other phones also do it.
2. If this is a bug, maybe MXit fixes it.

[gvrooyen]

Just out of curiosity, why is the content of the arrival message important for your app? So far, just recognising that a message has arrived from a MXitID with whom I don't yet have an active session (and simply ignoring its content) has worked fine for me... or is this a naive approach?

[CarelZA]

We would like to send screen configs only once.
It is possible that a user's client can crash or his connection can fail and then an app is not notified of the user's departure. In other words, it can happen that you have been sending messages to a client and then suddenly receive such a blank message (or single white-space message in the iPhone's case) that sort of tells you he needs a new config message before you send him other updates.

The alternative is to include config set-up messages with every update, but this will waste bandwidth.

[DeepFreez]

What I have done is to send a config every time there is a "state change" which does not happen very often. This includes stuff like menu changes etc so it forms a nice natural boundary. But this is very app specific.

Of course you could simply send a config every Nth message, or every X seconds, but that's less elegant

[themonk]

gvrooyen is right: That should be your approach. There are still legacy clients out there that doesn't auto-load the main menu, but the user rather has to send a message themself (such as "hi").

[gvrooyen]

What works well for me (so far) is to model the app as a state machine, with expected responses (menu selections, input, etc.) leading to state transitions. Well-formed responses like these lead to a light state transition, without any setup messages. If an ill-formed response is received (including blank messages, single-space messages or just plain user-entered junk), the app assumes the worst, and can do the screen setup from scratch. This happens seldom enough not to cause significant overhead.

This approach is suited to an app that is mostly link-driven, i.e. each state has a finite number of expected responses; everything else is considered ill-formed. If your app mostly relies on free-form text entry from the user (e.g. a text adventure or an ELIZA clone) it becomes trickier to distinguish between well-formed and ill-formed responses.

[CarelZA]

gvrooyen, we also use the state machine approach, but handle "ill-formed" or "unexpected" responses as user input for a search string. From your and themonk's posts, it seems we would need to create an extra state (maybe after the user clicked a "search" button) and capture search input text in that state. The downside is that this requires an additional step on the user's part, something we would like to avoid. We are trying to avoid any unnecessary complexity in our interface as far as possible.

[themonk]

The whole send space or blank message thing is a bit of a hack (or trick, depending on your view :-) ).