Android: I wish somebody warned me about this!
-
I am getting to the stage of conquering Kotlin where I start feeling comfortable regarding myself as a Kotlin coder. Kotlin, of course, is the primary tool for writing code for the Android platform. Yes, Java can code for Android as well, but Java is getting long in the tooth. A couple of days ago, I had to code a dialog box with CANCEL and PROCEED buttons, where the user can confirm some choice (or cancel out of it.) The idea was for the UI to stop and wait for user input. But I tried everything and there was no way to stop the UI. It would pop up my dialog, but instead of waiting it went on its merry way, continuing to execute statements. It nearly drove me nuts, until in desperation I googled the problem. And there was the answer: Some Android expert said there is no way to stop the Android UI, as everything in Android is async. Aaaargh! I wish somebody told me that! I bought 3 books on writing Kotlin code for Android and not one shared that little gem with me. It seems you may have to make some fancy moves while waiting for user input, to make sure the UI doesn't wander off and do something stupid!
Get me coffee and no one gets hurt!
-
I am getting to the stage of conquering Kotlin where I start feeling comfortable regarding myself as a Kotlin coder. Kotlin, of course, is the primary tool for writing code for the Android platform. Yes, Java can code for Android as well, but Java is getting long in the tooth. A couple of days ago, I had to code a dialog box with CANCEL and PROCEED buttons, where the user can confirm some choice (or cancel out of it.) The idea was for the UI to stop and wait for user input. But I tried everything and there was no way to stop the UI. It would pop up my dialog, but instead of waiting it went on its merry way, continuing to execute statements. It nearly drove me nuts, until in desperation I googled the problem. And there was the answer: Some Android expert said there is no way to stop the Android UI, as everything in Android is async. Aaaargh! I wish somebody told me that! I bought 3 books on writing Kotlin code for Android and not one shared that little gem with me. It seems you may have to make some fancy moves while waiting for user input, to make sure the UI doesn't wander off and do something stupid!
Get me coffee and no one gets hurt!
Not nearly as nuclear, but I found a nice replacement for js alert that is real cool and lightweight but unlike alert, does not stop execution. it's the last statement in the readme.md as if the dev is sorry about it. :doh:
-
I am getting to the stage of conquering Kotlin where I start feeling comfortable regarding myself as a Kotlin coder. Kotlin, of course, is the primary tool for writing code for the Android platform. Yes, Java can code for Android as well, but Java is getting long in the tooth. A couple of days ago, I had to code a dialog box with CANCEL and PROCEED buttons, where the user can confirm some choice (or cancel out of it.) The idea was for the UI to stop and wait for user input. But I tried everything and there was no way to stop the UI. It would pop up my dialog, but instead of waiting it went on its merry way, continuing to execute statements. It nearly drove me nuts, until in desperation I googled the problem. And there was the answer: Some Android expert said there is no way to stop the Android UI, as everything in Android is async. Aaaargh! I wish somebody told me that! I bought 3 books on writing Kotlin code for Android and not one shared that little gem with me. It seems you may have to make some fancy moves while waiting for user input, to make sure the UI doesn't wander off and do something stupid!
Get me coffee and no one gets hurt!
UWP is the same way; the methods for their "content dialog" control are .Hide and .ShowAsync().
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
I am getting to the stage of conquering Kotlin where I start feeling comfortable regarding myself as a Kotlin coder. Kotlin, of course, is the primary tool for writing code for the Android platform. Yes, Java can code for Android as well, but Java is getting long in the tooth. A couple of days ago, I had to code a dialog box with CANCEL and PROCEED buttons, where the user can confirm some choice (or cancel out of it.) The idea was for the UI to stop and wait for user input. But I tried everything and there was no way to stop the UI. It would pop up my dialog, but instead of waiting it went on its merry way, continuing to execute statements. It nearly drove me nuts, until in desperation I googled the problem. And there was the answer: Some Android expert said there is no way to stop the Android UI, as everything in Android is async. Aaaargh! I wish somebody told me that! I bought 3 books on writing Kotlin code for Android and not one shared that little gem with me. It seems you may have to make some fancy moves while waiting for user input, to make sure the UI doesn't wander off and do something stupid!
Get me coffee and no one gets hurt!
Regardless of Java vs Kotlin, mobile apps in general are non-blocking (bad UX otherwise). That's one of the ways in which they differ from desktop apps.
Cp-Coder wrote:
It seems you may have to make some fancy moves while waiting for user input, to make sure the UI doesn't wander off...
I've yet to have to resort to fanciness. It's mostly just making sure the design is correct and then taking advantage of what the OS already provides.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
-
Regardless of Java vs Kotlin, mobile apps in general are non-blocking (bad UX otherwise). That's one of the ways in which they differ from desktop apps.
Cp-Coder wrote:
It seems you may have to make some fancy moves while waiting for user input, to make sure the UI doesn't wander off...
I've yet to have to resort to fanciness. It's mostly just making sure the design is correct and then taking advantage of what the OS already provides.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles