I'm stuck in someone's for loop
This is a rant. More and more I'm finding myself using mobile devices, often on my iPhone, but also desktop applications in Windows and I'll push a button and find myself, as user, stuck inside your for loop.
Have you felt like this? The application locks up and you're stuck. Maybe it's Outlook saying Not Responding as the Curtain of Patience (tm) comes down, or perhaps it's Facebook on your iPhone updating Contact photos. Regardless, it's a for loop over a thousand or a million, or perhaps just one more data item than the developer tested, and you're stuck. Do you shut down and corrupt the data store? Do you wait? How long DO you wait?
Asynchronous programming can be hard, but the tools and languages support it, my friends.
Please don't block the UI.
Have you seen this? Why does it happen? What are you doing to avoid blocking calls? Perhaps it's a better UX pattern, or perhaps it's Reactive Programming?
Sound off in the comments!
Related Links
- Windows Phone 8 - Understanding Async and Awaitable Tasks
- Handling Asynchronous Data in Windows Store Apps
- PODCAST: Everything .NET programmers know about Asynchronous Programming is wrong
- The Magic of using Asynchronous Methods in ASP.NET 4.5 plus an important gotcha
- Async methods in ASP.NET 4.5
Sponsor: Big thanks to my friends at Octopus Deploy. They are the deployment secret that everyone is talking about. Using NuGet and powerful conventions, Octopus Deploy makes it easy to automate releases of ASP.NET applications and Windows Services. Say goodbye to remote desktop and start automating today!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
"Oops, I made that call to SmtpClient/SmartyStreets/FedEx inside of the database transaction." (Normally the e-mail is sent/address is validated/rate is returned quickly, so I never noticed, but when they or you have an outage, it hurts real bad -- all those transactions get blocked and pile up ... then deadlock, deadlock, tears, tears streaming down my face.
(You can extend this out to pretty much anything that you assume is "fast enough", though. A File.Open() works great on your machine but the call fails to return quickly on someone else's because whoops! the network share their file was on has achieved a higher state of entropy. I think only recently has the async everywhere mantra been driven home, really with just WinRT, so that's gonna take a while to come round....)
Apps also have to be tested for all the operations that _might_ block the UI ... and that's hard to. Complex systems behave in unexpected ways - and something that was taking 100ms in 99.9% of cases might under rare conditions take 100x longer. Better tools might help with that.
While(user.CanWaitLonger) { BlockUI(); }
On the desktop, I find that Windows is a bit quick to report Not Responding sometimes. I'm sure the amount of time you get to respond has reduced with successive versions of windows. Sadly, not everyone has the budget to rewrite large parts of their code to take advantage of Async/Await.
Stop whining get better at debugging ;-). !analyze -v is not the end of a Debugging session.
This may sound like we're not progressing yet the space smartphones exist now are so totally different when "personal assistants" started us down the super tiny ultra portable computer path, but we still have a long way to go. That's really the exciting part of being a developer, something I can easily lose track of if I'm not reminded in posts like this.
Async/await is still pretty new, and a lot of devs are still learning it. WinRT helps by forcing devs to do it right instead of being lazy, but most other platforms don't. So, reason #1 is that a lot of devs just haven't learned async/await yet. And if you think the lack of async in UIs is bad, the lack of async on websites is far more extensive (in my experience).
Reason #2 is that async is hard on a lot of platforms. Sure, .NET has async/await, but have you ever tried it on JavaScript, Java, or Objective C? Proper asynchronous code is a *lot* harder. Considering JavaScript in particular (since it's everywhere now), it is getting async/await-like features in its vNext, but mobile app devs will have to wait a considerable time before async-enabled JS runtimes exist on the majority of mobile platforms. Until then, async is a real pain.
The third reason - which is kind of like reason #2 - is that backwards compatibility really throws a wrench in things. In particular, STA COM objects are all over the place in a lot of MS products including Office and VS. They have a thread affinity that many times *forces* you onto a UI thread.
IMHO. :)
In particular, STA COM objects are all over the place in a lot of MS products including Office and VS.That IS really a pain. We just created a new piece of software at work which is driving a hardware-device so a lot of IO is happening and we created it "async all the way", but at the end we where forced to "wrap a Sync-Layer on top" because we needed to support an old COM API...
In our UI we use async/await and for .NET also an "async-API" is available, but for that "old API support" we broke the "don't do sync over async"-rule (mostly using Stephen Toubs AsyncPump to avoid deadlocks) so we did not need to "duplicate most of the code/methods" by introducing a "sync-path" next to the async methods.
I get a SAVE FILE DIALOG, and choose to fold out the "my computer" to find a drive and then the UI locks up until all drives have responded.
The same thing happens too often when you open "My computer" to op en a drive.
Why not simply show drives that are ready and then show drives as they get ready ?
Its pretty unforgivable in modern applications, in older legacy applications that are hard to change because of shear weight of code its difficult to fix. So:
1) Address technical debt early
2) Don't block the UI
3) Don't block the UI
it really annoys me when the UI is blocked because of poor design. ARRRGHHHH.
Also, a lot of business folks don't see the benefit of refactoring code or spending time on maintaining. It's sad, but true.
$ > UX
I am pretty sure this happens only when Windows hits the HDD (I am on an SSD too!). I just was able to repro, but only on the first try. I bet it will not happen for a few hours now.
"Script not responding, do you want to wait for it..." (no, 3 minutes before I got a response like this, no...)
"A pop-up is being blocked..." (No sh%^&t, that's why I installed a pop-up blocker, AD blocker, flash blocker, Google analytics opt-out, etc.)
Ranking WAY UP THERE in the Windows UI:
"The Flash of F&*^%ked Up-ness" (Do you wonder how much fun that would be to have Windows X as your vehicle operating system? Do you wonder how many accidents the FFoU would create? Seriously, do we need to flash the entire fricken screen if I'm already logged in as an Administrator?)
Copy-n-Paste from Win7 + has been a basket case. Using it between Win 8 and Hyper-V is laughable at best.
Don't get me started Scott :)
the endless Visual Studio 2013 prompt? "You have mixed spaces and tabs..." fix it, ..., ..., ignore and don't ask again
telling VS2013 to not ask again is like telling your 2 year old, "yes, we are REALLY out of ice cream :)
Chrome 38 has this new bandwidth/latency throttler under the new mobile testing view. It's not perfect, but it already helps to see how slow page loads work, and where async is done right. We need more easy tools to slow things down, and simulate normal user conditions. Or even better, we need a chaos monkey that occasionally makes some computational and IO operations really slow. :-)
This must of course be pronounced in a Scottish accent.
Comments are closed.