Mark, > > 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.
Other than showing them a static picture from a website they visited previously, I don't think I could present anything to a user that wants to get to her content, asap. I don't see myself running a 1min animation to tell people I have to wait until the OS has finally decided that my app needs more room. And really, that's the message they should see, because that's the cause of the delay. And I don't want to lie to my users. > > > 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. > And I have to live with comments accusing me of not being able to use threads "properly" to make my application more responsive. > 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. All I'm asking for really. That and a statement form someone in the Android dev team admitting that there's a design flaw in this area. And maybe that just pointing to all default apps not having an "exit" button can't be the answer to this and related problems. >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. ;-) > I started on programmable calculators, until I moved up to a 1k Sinclair, which I considered roomy. I have no idea how the world got things done back then. Maybe we just didn't need to write code that gets interpreted/translated down several times before it finds an actual processor cycle that does some application related work. But then again, it didn't offer a "f*rt" application either. ;) Michael --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
