kolby wrote: >> 1. How long is "some time"? >> > Anecdotal evidence suggests for the first few (< 5 mins). I have too > many > other things to debug still, so this hasn't been one of my priorities > yet, but it > has been to some of my users according to feedback.
That's a lot longer than I would have expected. > Between opening at least one WebView and potentially showing a virtual > keyboard, there's really very little in terms of managing user > expectations. No, but you can make some choices here. For example, for a consulting customer, I have an activity that incorporates a WebView, loading up some local content. This takes a few seconds to load, even with everything local, due to a combination of content complexity and prototype-level local content serving code. So, rather than have a blank screen, we're running a loading animation first, with the WebView invisible, only "popping" the WebView when the page is finished loading (through a WebViewClient callback). Does this speed things up? No. In fact, it probably slows them down, as the device has to spin the little animation. Does the customer -- who has lots of UI design and human factors experience -- feel that this will improve the *perceived* loading time? Yes. I'm not saying this specific technique is appropriate for Steel. However, I am saying that there are probably steps you can take to make Steel both *be* more responsive once it's ready and *feel* more responsive through judicious use of tricks akin to the one described here. > The windows analogy is not 100% working for me here, because I believe > in > Android everything is in memory, we're not trying to access a hard > drive, and > even then, freeing room in a pagefile is much less resource intensive, > than > actually closing other applications based on demand, with callbacks to > allow > those apps to clean up, and having a garbage collector run in a java > environment. > All this while my poor app is trying to look good ;) I didn't say they were the same in implementation. I said they have the same impacts upon a newly-opening application. Hard drive thrashing for swapfile access slows things down. Terminating activities in Android slows things down. Which one does its work faster is contingent on way too many environmental considerations (# of apps open, amount of available memory, fragmentation of the hard drive, etc.) to make a clear statement that one is necessarily always better than the other. > Sometimes a user really does know when she wants to close an app and > not > use it again for a while, but Android is denying them the decision. I can see arguments from *users* that they should have the ability to close up unwanted applications. But as a developer, you need to handle all scenarios, including those where users, for whatever reason, aren't closing up other applications. Just because a facility *exists* doesn't mean people will use them. Heck, I've seen senior civil engineers try opening 1GB (yes, 1GB) TIFF files on 1GB RAM Windows XP machines and then wonder why Outlook gets unhappy. And these guys are sharper than the average mobile device user, I suspect. As a user, I'm in agreement that a proactive close-the-app-and-I-really-mean-it-this-time facility would be A Good Thing, so long as it is not required for users to use it. As a developer, I gotta live with the fact that some users just won't use it and therefore I have to take whatever steps I can to make the user happy regardless. Of course, I'm an old fogey, having started developing apps in 16K of RAM on 1MHz CPUs. So my perspective may be out of touch with the whippersnappers who dominate the industry today. ;-) -- Mark Murphy (a Commons Guy) http://commonsware.com _The Busy Coder's Guide to Android Development_ Version 2.0 Available! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
