By the way, Romain, you bring up a good point regarding ANRs. And it's
not going to help splitting my work up into small groups of operations
because a busy CPU might make one group of operations last long enough
to trigger an ANR. Instead, I need to break the work into time slices
so that the runn
I'm not blocking the UI thread. In my test I stubbed out doDraw so it
returns immediately and the behavior is the same. It's due to calling
dismissDialog from the runnable.
On Nov 7, 11:51 am, Romain Guy wrote:
> It doesn't work because you are blocking the UI thread. You are not
> "streaming" th
It doesn't work because you are blocking the UI thread. You are not
"streaming" the UI at all like I suggested you do. You need to show the
dialog, then build the views by little batches so that you never block the
UI thread for more than a few milliseconds at a time. Otherwise your app
will appear
I just figured out a slick workaround for this bug. The progress
dialog stuff is clearly hosed so I just brute force it. I do a
setContentView with the resource
R.layout.tellsuserthatworkingisbeingdone, which tells the user to wait
a moment. Then I give the framework 100 mS to update the screen, th
Following Romain's suggestion, I changed the code above to look as
below. The interesting thing to note is that the behavior remains
exactly the same. The dialog gets dismissed when the activity is new
but won't dismiss when there is a configuration change. According to
my understanding, the runnab
Since the views are all different sizes, the various ListViews,
GridViews, and Adapters don't work. Part of the secret sauce of my app
is the algorithm for arranging the views in the most compact way to
present the maximum amount of information in the screen space
available. The main benefit of the
On Sat, Nov 6, 2010 at 4:08 PM, Romain Guy wrote:
> Have you thought about using a ListView instead btw?
Agreed. Or any other AdapterView. Or writing your own AdapterView.
Anything to reduce your heap and stack consumption.
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.c
Well, if you were to show 1000s views on the screen, you would obviously
need more memory. Try creating a list view (a dumb one which returns a new
view every-time) and see if the amount of memory is substantial.
Delay is fine, but I cannot think of a situation where someone might have to
bring up
You can display a progress bar or even a progress dialog and still stream
the UI. Have you thought about using a ListView instead btw?
On Sat, Nov 6, 2010 at 1:05 PM, Bret Foreman wrote:
> In what way is it too much? I'm not using much memory and the delay is
> only a few seconds. It will all be
In what way is it too much? I'm not using much memory and the delay is
only a few seconds. It will all be fine if I can figure out how to
present the user a progress dialog or other indication that work is in
progress.
On Nov 6, 12:58 pm, Kumar Bibek wrote:
> 1000's of views I guessThats too
1000's of views I guessThats too much...
On Sun, Nov 7, 2010 at 1:27 AM, Bret Foreman wrote:
> My Moto Droid builds the Views in a few seconds and everything else
> works great - scrolling is fast and pretty, memory utilization is
> modest. The _only_ problem is how to handle the brief delay
My Moto Droid builds the Views in a few seconds and everything else
works great - scrolling is fast and pretty, memory utilization is
modest. The _only_ problem is how to handle the brief delay while the
Views are built. I'm not sure what you mean by sensible.
On Nov 6, 12:44 pm, Mark Murphy wrot
On Sat, Nov 6, 2010 at 3:29 PM, Bret Foreman wrote:
> A few hundred Views in a typical case but it could be up to a couple
> thousand in some cases.
And what makes you think that "a couple thousand" is sensible, on any platform?
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://git
A few hundred Views in a typical case but it could be up to a couple
thousand in some cases.
On Nov 6, 12:19 pm, Mark Murphy wrote:
> On Sat, Nov 6, 2010 at 3:10 PM, Bret Foreman wrote:
> > I've used Traceview extensively on this code - it used to take 20
> > seconds and now it's down to 3, all
On Sat, Nov 6, 2010 at 3:10 PM, Bret Foreman wrote:
> I've used Traceview extensively on this code - it used to take 20
> seconds and now it's down to 3, all of which is in the View
> constructors and the code where I set various drawing parameters.
Most Views take next to no time to set up. How
I've used Traceview extensively on this code - it used to take 20
seconds and now it's down to 3, all of which is in the View
constructors and the code where I set various drawing parameters. It's
just a lot of Views and there is no smoking gun where a lot of time is
being spent. I thought about cr
On Sat, Nov 6, 2010 at 3:04 PM, Bret Foreman wrote:
> Streaming the UI creates an added complication - in what way should I
> notify the user that the UI is finished drawing? Partial data is going
> to confuse the user unless they know that more is coming. Since this
> is a limitation imposed by t
Streaming the UI creates an added complication - in what way should I
notify the user that the UI is finished drawing? Partial data is going
to confuse the user unless they know that more is coming. Since this
is a limitation imposed by the Android framework, others must have
encountered it. Is the
On Sat, Nov 6, 2010 at 2:51 PM, Bret Foreman wrote:
> The time
> taken is just in building the view hierarchy itself - creating and
> initializing the Views takes a few seconds.
Use Traceview and find where your performance issue lies. "Building
the view hierarchy itself" is a very broad statemen
I see. Well, I'm not doing much in the way of computations. The time
taken is just in building the view hierarchy itself - creating and
initializing the Views takes a few seconds. So it looks like I'll have
to stream the UI with a Handler as I build it. It's a shame that the
framework imposes so mu
She did not suggest you crated the Views themselves in background thread,
but that your computations were done in a background thread. You need to
split the creation of the Views and whatever you are doing that's taking a
long time to compute. You can also stream the UI by adding Views one after
th
I should point out, by the way, that Dianne Hackborn recommended my
current approach in this thread:
http://groups.google.com/group/android-developers/browse_thread/thread/8c3fe5692fb6b0b0/79c04e8bf41843?q=#0079c04e8bf41843
--
You received this message because you are subscribed to the Google
Gr
What is the best way to handle the case where drawing takes a few
seconds? I need to put up some sort of progress dialog while I work on
building the screen.
On Nov 6, 11:18 am, Romain Guy wrote:
> You should NEVER create or draw Views from a background thread. The UI
> toolkit (and the framework
23 matches
Mail list logo
