I definitely agree with just working on making the UI faster to load - I rewrote the activity so the UI loads in a staggered manner. It's a ScrollView with several irregularly shaped sub views (which don't fit nicely in a ListView). Therefore I am adding each subview one at a time to the ScrollView, but this can take some time.
I create only the first few subviews and add them to the ScrollView in the onCreate() method. The activity starts immediately and the user can start interacting. However, the remaining views are generated in delayed intervals (using a series of postDelayed()), and appended to the bottom of the ScrollView. This works, it's just a little annoying to see all that work being redone on each load of the Activity. I tried looking at overriding the back button and tweaking the history stack to somehow keep the activity around, but yeah you're right, it's a bit dangerous and will probably not end nicely. In this case, it's probably best to keep everything in one activity, and switch views on the back button (not the greatest either, but manageable). This comes at the expense of keeping all the UI stuff in memory then, but I haven't seen this go above 5mb. Thanks On Nov 23, 1:10 pm, Mark Murphy <[email protected]> wrote: > Mark Wyszomierski wrote: > > It's only causing a slight annoyance to the user. Although the UI > > takes about 1.5 seconds to completely build, I am doing a staggered > > load. This lets the user see content immediately, but they're > > wondering why every time they leave the search activity, then come > > back, all the content must be reloaded. The actual search data is kept > > in a global static singleton, no problem there, just the UI is kind of > > heavy to keep regenerating around it. > > I'd focus on making the UI faster to load, but that's just me. And > apparently Ms. Hackborn, seeing her reply as I was typing this one. > > > This would work better as a tabbed-view in a single Activity, but my > > spec calls for the search screen to be in a separate Activity. I like > > keeping it separated too, just wish I could pause the app to resume it > > later since I'm sure it's an Activity users will keep coming back to > > while using the app. > > You might achieve your desired effect by overriding onBackPressed() (or > perhaps onKeyUp() if onBackPressed() is too late) and using > startActivity() with an Intent and some likely flags to try to get > control to the other activity. This, coupled with > android:launchMode="singleTop", should mean you'll have 0-1 instances of > your search activity at all times. > > However: > > 1. This assumes that the search activity knows who to go "back" to via > startActivity(). That may be easy to determine in your case. > > 2. You'd also need to arrange to finish() this activity at some point, > otherwise your app is never exitable. > > 3. If you have N other activities besides the search one, all this > bookkeeping gets much more icky. > > Hence, I'd focus on making the UI faster to load. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://twitter.com/commonsguy > > Android App Developer Books:http://commonsware.com/books -- 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
