A while ago Marco Cantu posted about an issue with implementing ShowModal in FireMonkey, specifically with reference to the difficulties this entailed on iOS and Google Android platforms. Chris Rolliston recently picked this same topic up and highlighted some problems that still remain in the FireMonkey “solution”. Both Marco and Chris however have missed a key point.
Neither Google nor Apple are stupid.
If modal dialogs are “difficult” on their platforms, perhaps there is a good reason for this ?
And if you stop and think about a mobile computing platform properly, rather than simply trying to steam-roller a desktop application model onto it on the coat-tails of a cross-platform graphics rendering engine, the problems become obvious.
On a desktop computer if I am working with an application and that application requires a modal dialogue with the user then it makes perfect sense to do so. The application cannot proceed until the dialogue has completed.
Note that I use the dialogue spelling here to emphasise the fact that I am talking about the concept of a conversation with a user, not a specific software/UI technology that implements that concept.
On the desktop, such conversations will not (other than in exceptional circumstances) be interrupted. Even if the user is distracted, goes away, perhaps performs some other task (even on the same computer), when they return to that application it will still be there, waiting patiently for them to respond and to complete the dialogue.
The user can even switch off their computer and if they use the “hibernation” facility of their system then the application, patiently waiting for their response, will still be patiently waiting when it has been restored from it’s hibernated state.
And the application developer gets all this for free with a simple ShowModal call.
Mobile platforms are somewhat different.
Even as well specified as they often are, mobile devices are far more resource constrained, relatively speaking, than desktop systems and the operating systems far more aggressive in limiting wasteful use of those resources.
As a result, a conversation can be simply cut off by the system if the user does not respond in a timely fashion.
On mobile platforms, long running user dialogues make very little sense and tend to be limited to much shorter exchanges obtaining simple responses from a user. Pick from a list, confirm or reject an option etc etc.
And even here, if the user doesn’t pick from the list or confirm the option, well.. so what ? Obviously it wasn’t important enough for the user to do so at that time and the application must and will allow for that.
More crucially, in a long running conversation if a user is distracted and switches to some other application then in the meantime the system may decide that the dialogue with the original application was not important enough and sweep the entire thing away to make room for other things that are more important (i.e. what the user is actually working with right now).
There are obvious good reasons for this.
Users don’t even seem to mind. They have accepted this behaviour of mobile applications without fuss or bother.
In part this is because some applications can maintain an illusion of modality, using the platform behaviours that the platform designers thoughtfully provided.
If a dialogue with a user is sufficiently important then an application can respond to being cleaned up by the system and (if it is important to do so) can save information about the current state of that dialogue which will allow it to resume that state when the user returns (re-starts) the application.
But sitting there presenting a blocked UI would prevent the system from cleaning up such an application.
Or rather, it would require that to do so would involve having a facility for hibernating and resuming an applications entire state, rather than simply flushing it and leaving it to resume into whatever state the application deems appropriate.
Again, there are obvious reasons why such an approach would be impractical and undesirable on a mobile device.
But as even this simple case demonstrates FireMonkey isn’t concerned with fostering, encouraging or in some cases even supporting correct behaviour on mobile platforms. It is concerned only with allowing developers to code in ignorance of such concerns.
It’s all about whether FireMonkey can do something and never about whether it should.
It also means studiously ignoring all the things that FireMonkey simply cannot do that users of the “supported” platforms expect. On Android this means obvious things like Services and AppWidgets, and less obvious things like using the system provided AlarmManager to reliably and (more importantly) efficiently invoke application behaviours at scheduled times.
In doing so, it does those developers – not to mention the users of those developers’ applications – a great disservice.