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.
User Dialogues
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.
User Interrupted
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.
Platform Ignorance
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.
I was saying nothing about the desirability or otherwise of modal forms in that post, merely warning of a buggy implementation. That said, I don’t really get what you’re trying to say, given on mobile platforms, modality is obviously the default. E.g., in an Android SDK context, initiate a new activity, and the new activity completely replaces the previous one on screen. To work with the previous activity again, the user then has to exit the second one (e.g. by pressing the back button).
Mind you, for me at least, there are times when a modal form is actually a good choice from the user’s POV on the desktop too – ‘IDE Insight’ in the Delphi IDE is a case in point…!
The fact that you didn’t address the desirability of modal forms was exactly the point. “Should it be done?” is the first, most important question to ask before addressing “can it be done?“.
First, not all activities cover the entire screen, though most do.
Second, Activities on Android are not “modal”. There is an activity stack, yes, but an application and the entire activity stack can be swept away without the user doing anything (sometimes precisely because the user hasn’t done anything).
That is not modality, it only looks like it when you are trying to view it as something that can be shoe-horned onto a desktop application view of the world.
The trouble with FireMonkey is that because applications are not first class citizens, they have to resort to such techniques. So to be entirely fair, the answer to the question Should It be done is simply: No, but you have no choice. 😉
My post’s entire purpose was to publicise a pair of bugs and the (pretty trivial) reasons for them, that’s all. As for your rather restrictive definition of ‘modal’ – I don’t share it, though I acknowledge the term can be used in different ways.
For me, the main difference from a coding perspective between multiple activities in an Android project and multiple forms in a Delphi one is the fact you can’t just pass around any old object or interface reference in the former case – and if anything, that speaks of an activity being more ‘modal’ than a TForm.
Apologies if you feel I was criticising your post, I really wasn’t. I was just noting that you didn’t pick up on the more fundamental issue with ShowModal. Responsibility for that fundamental issue rests fairly and squarely at the feet of Embarcadero. Mentioning your post was more a acknowledgment of it’s role in prompting my own musings. An attribution, if you will. 🙂
As for modal/modeless, on Android the situation seems far more similar to a web application to me. Not modal at all, but a web app often has to give the illusion of modality/statefulness. But not always, and users do not expect it on that platform.
Discussions of how activities actually behave on Android is of course utterly irrelevant to FireMonkey, given that the FireMonkey runtime exists entirely within a single activity and has to fake everything from that starting point and do so in a way that will transfer to the other versions of the FireMonkey runtime.
That implementation is a flaw per se. The claimed idea behind Delphi Mobile is reusing code as is (another one is CPU-Native code instead of OS-Native program).
However EMBT failed to achieve it: they changed ShowModal signature and hence anyway require reworking old code. Could they implement Continuation-passing for ShowModal calls ? Or maybe offload main thread context and show modal window in a newly created thread ?
Or whatever, but keep their holy cow of source-level compatibility… But without it – why bother. EMBT failed at providing good old ShowModal on mobile. They anyway demand code rework instead of code reuse in this context. Then why encourage an alien and alienating way to rework it, instead of instilling good OS-native practices ?
But.. but…but … there were talks about mobile at CodeRage and David I. gave one about “Top 5 Mobile Mistakes” (not sure that anyone at EMBT has any significant experience writing mobile apps, but….). Mistake #1 (as also listed in their white paper) is “Trying to fit a desktop experience onto a mobile device”. So you’re saying they need to take their own advice? 😉
How they manage to keep a straight face while presenting those Top #5 is one of the wonders of the modern world.
> for more resource constrained
FAR more
Thanks. 🙂
I’ve found users never like modal dialogues anyway. They always seem to need to check something on another window. btw I recently bought some tail coats with pockets which are very useful but not sure if the idea would transfer to the programming world.
LOL 🙂
Only basic algorithm(s) in application can be cross-platform. All other (gui, save data, registry…) is different on all other platforms.
True to an extent, but many (not all) of those operations can be projected into an abstracted API with an underlying adapter to the platform specific mechanisms. The area where this is least successful is the GUI since platforms specifically differentiate themselves in their UX and consequently in their UI.