[android-developers] onSaveInstanceState (View)
Hi, I've got some issues with onSaveInstanceState (the View one, not the Activity). I have in my main Activity several objects, here's a snippet of my two implementations, one through XML Inflate, and one in pure java code. //Inflated from XML dialbig = (Object1) findViewById(R.id.dialbig); //Implements a class directly dialsmall = new Object2(this, A name); dialsmall.setSaveEnabled(true); I had to do this because of this particular constructor in my custom view Object2, which needs to pass a String at runtime so I couldn't inflate it from XML. Let's explain my problem now. When my Activity is running and I press Home, my overriden method onSaveInstanceState in Object1 is properly called, allowing me to save the internal state. BUT the same method, overriden in Object2 is never called. Absolutely never... Is it because I created it programmatically, do we need to do something to enable saving while doing this ? Thanks for your help. Rgds, Alex -- 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
[android-developers] Re: CPU cost of a semi-infinite loop
Wonderful :) And you know what ? It's taking 1% of the CPU now... 3% @ 250 BPM with all quarter notes running. Absolutely amazing. Topic closed ! Thanks again. On 1 jan, 19:55, Dianne Hackborn hack...@android.com wrote: adb shell top will show CPU usage. My favorite version is adb shell top -t -m 10. On Sat, Jan 1, 2011 at 7:49 AM, Slash4 alex.cen...@gmail.com wrote: After several tests involving AudioTrack, both STATIC and STREAM mode, It was obvious I could not use this because of the specificity of my metronome, which can mix and play Notes, Half notes, quarter notes and triplets at the same time. Filling and reseting the AudioTracks buffers between each tempo change was way too long, even if after that no more CPU was needed because I used the loops (pretty interesting feature though, especially with the OnPlaybackPositionUpdateListener features allowing to sync between several AudioTracks, or UI). In STREAM mode, filling the buffer permanently was CPU consuming too, and I was facing a sync problem with my UI, which needs to react to each first beat of the bar. To answer Kristopher, I can testify that the latencies are very low and pretty appropriate to short loops (for Audiotrack at least, as I didn't test Mediaplayer). So, after that I followed Dianne 's idea and searched about delayed message posting. Finally I came up to a mix between delayed messages and Bret supposition with a timeStamp refreshed on each first beat to compensate the (eventual) jitter. GC doesn't bothers it seems, even if it happens, I see it in the debug log, but do not hear jitter anyway. Is there something like Task Manager on android to see how much CPU it costs now ? I would like to compare the two versions now :) Thanks for your reactive and precise help. And oh, happy new year :) Rgds, Alex On 30 déc 2010, 10:56, Slash4 alex.cen...@gmail.com wrote: Thanks Kostya, Streaming seems to be a great solution. And it is very interesting because this way I can mix sounds... Let's do this :) Rgds, Alex On 29 déc, 21:23, Kostya Vasilyev kmans...@gmail.com wrote: To elaborate a bit: http://developer.android.com/reference/android/media/AudioTrack.html AudioTrack supports streaming mode of operation, where data can be fed into it on the fly. You'd still need to do some sort of scheduled periodic loop, for feeding data to AudioTrack in chunks, but this way can deal with much larger jitter, which would be reasonable at application level. At some point, you'd need to queue the metronome click, presumably from an audio file packed within the application. This should help with that: http://mindtherobot.com/blog/580/android-audio-play-a-wav-file-on-an-. .. -- Kostya 29.12.2010 22:40, Frank Weiss пишет: I'd look into Kostya's suggestion. Ideally, you only need the click sample and you can program the audio player to play the sample at precise intervals. Trying to do precise timing with SDK programming is just frought with pitfalls, AFAIK. -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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
[android-developers] Re: CPU cost of a semi-infinite loop
After several tests involving AudioTrack, both STATIC and STREAM mode, It was obvious I could not use this because of the specificity of my metronome, which can mix and play Notes, Half notes, quarter notes and triplets at the same time. Filling and reseting the AudioTracks buffers between each tempo change was way too long, even if after that no more CPU was needed because I used the loops (pretty interesting feature though, especially with the OnPlaybackPositionUpdateListener features allowing to sync between several AudioTracks, or UI). In STREAM mode, filling the buffer permanently was CPU consuming too, and I was facing a sync problem with my UI, which needs to react to each first beat of the bar. To answer Kristopher, I can testify that the latencies are very low and pretty appropriate to short loops (for Audiotrack at least, as I didn't test Mediaplayer). So, after that I followed Dianne 's idea and searched about delayed message posting. Finally I came up to a mix between delayed messages and Bret supposition with a timeStamp refreshed on each first beat to compensate the (eventual) jitter. GC doesn't bothers it seems, even if it happens, I see it in the debug log, but do not hear jitter anyway. Is there something like Task Manager on android to see how much CPU it costs now ? I would like to compare the two versions now :) Thanks for your reactive and precise help. And oh, happy new year :) Rgds, Alex On 30 déc 2010, 10:56, Slash4 alex.cen...@gmail.com wrote: Thanks Kostya, Streaming seems to be a great solution. And it is very interesting because this way I can mix sounds... Let's do this :) Rgds, Alex On 29 déc, 21:23, Kostya Vasilyev kmans...@gmail.com wrote: To elaborate a bit: http://developer.android.com/reference/android/media/AudioTrack.html AudioTrack supports streaming mode of operation, where data can be fed into it on the fly. You'd still need to do some sort of scheduled periodic loop, for feeding data to AudioTrack in chunks, but this way can deal with much larger jitter, which would be reasonable at application level. At some point, you'd need to queue the metronome click, presumably from an audio file packed within the application. This should help with that: http://mindtherobot.com/blog/580/android-audio-play-a-wav-file-on-an-... -- Kostya 29.12.2010 22:40, Frank Weiss пишет: I'd look into Kostya's suggestion. Ideally, you only need the click sample and you can program the audio player to play the sample at precise intervals. Trying to do precise timing with SDK programming is just frought with pitfalls, AFAIK. -- 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 -- Kostya Vasilyev -- WiFi Manager + pretty widget --http://kmansoft.wordpress.com -- 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
[android-developers] Re: CPU cost of a semi-infinite loop
Thanks Kostya, Streaming seems to be a great solution. And it is very interesting because this way I can mix sounds... Let's do this :) Rgds, Alex On 29 déc, 21:23, Kostya Vasilyev kmans...@gmail.com wrote: To elaborate a bit: http://developer.android.com/reference/android/media/AudioTrack.html AudioTrack supports streaming mode of operation, where data can be fed into it on the fly. You'd still need to do some sort of scheduled periodic loop, for feeding data to AudioTrack in chunks, but this way can deal with much larger jitter, which would be reasonable at application level. At some point, you'd need to queue the metronome click, presumably from an audio file packed within the application. This should help with that: http://mindtherobot.com/blog/580/android-audio-play-a-wav-file-on-an-... -- Kostya 29.12.2010 22:40, Frank Weiss пишет: I'd look into Kostya's suggestion. Ideally, you only need the click sample and you can program the audio player to play the sample at precise intervals. Trying to do precise timing with SDK programming is just frought with pitfalls, AFAIK. -- 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 -- Kostya Vasilyev -- WiFi Manager + pretty widget --http://kmansoft.wordpress.com -- 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
[android-developers] Re: CPU cost of a semi-infinite loop
Hello,
thanks you so much for looking at my problem :)
First, my application is using a SCREEN_DIM_WAKE_LOCK so the screen is
always on, yet the backlight and the keyboard are dimmed. Did you say
in this case, the battery would not be consumed ?
So, about accuracy, the fastest callback that I can set is 60ms (a
quarternote at 250 BPM tempo). I can afford a 10ms, lets say 15ms
jitter, more and it will be noticeable at this tempo. Following this
idea, I added a Thread.Sleep(10) since yesterday, to avoid too much
iterations of my timing loop :
while(isRunning){
//Do stuff...
try {
Thread.sleep(10);
} catch (InterruptedException e) {
}
}//End while
Is it better for CPU or is it only cosmetic ?
I didn't try message posting, I'll check this immediately. Is it
suitable for so short callback times ?
I didn't specified a priority on the Thread, so I suppose it's
inherited from the parent's priority. What would be the best value for
it in your opinion ?
Regards, Alex
On 29 déc, 03:22, Dianne Hackborn hack...@android.com wrote:
This will run the CPU at 100%. With the screen off, this will tremendously
impact battery life. With it on, it will be at least noticeable.
How accurate do you need to be? Have you tried other approaches such as
posting messages at a time? What priority are you running your timing
thread at (priority would be the first thing I look at when it comes to
accuracy).
On Tue, Dec 28, 2010 at 4:06 AM, Slash4 alex.cen...@gmail.com wrote:
Hi,
I'm working on a metronome application, so I need a rather accurate
time-measuring system to fire the metronome sound at the right time.
Actually I found a solution, but I'm wondering if my method will not
be cpu consuming. Here is the code snippet :
t = new Thread() {
public void run() {
long neededTime = 0;
while(isRunning){
long curTime = SystemClock.uptimeMillis();
if(curTime=neededTime){
neededTime = curTime + (6/tempo);
playSound(clickSoundId,100);
incrementBeat();
mHandler.post(mUpdateUi);
}
}
}
};
t.setDaemon(true);
t.start();
You can see I set up a semi-infinite loop with rather frequent
accesses to uptimeMillis() . I chose this method after having some
issues with sleep() which is not accurate enough. When I want to stop
the metronome, I just have to set isRunning to false.
How can I evaluate the impact of this on CPU and battery ?
Thanks a lot.
Rgds, Alex
--
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.comandroid-developers%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
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
[android-developers] Re: CPU cost of a semi-infinite loop
I answered you but I don't see my message.. I hope it's OK :s
On 29 déc, 03:22, Dianne Hackborn hack...@android.com wrote:
This will run the CPU at 100%. With the screen off, this will tremendously
impact battery life. With it on, it will be at least noticeable.
How accurate do you need to be? Have you tried other approaches such as
posting messages at a time? What priority are you running your timing
thread at (priority would be the first thing I look at when it comes to
accuracy).
On Tue, Dec 28, 2010 at 4:06 AM, Slash4 alex.cen...@gmail.com wrote:
Hi,
I'm working on a metronome application, so I need a rather accurate
time-measuring system to fire the metronome sound at the right time.
Actually I found a solution, but I'm wondering if my method will not
be cpu consuming. Here is the code snippet :
t = new Thread() {
public void run() {
long neededTime = 0;
while(isRunning){
long curTime = SystemClock.uptimeMillis();
if(curTime=neededTime){
neededTime = curTime + (6/tempo);
playSound(clickSoundId,100);
incrementBeat();
mHandler.post(mUpdateUi);
}
}
}
};
t.setDaemon(true);
t.start();
You can see I set up a semi-infinite loop with rather frequent
accesses to uptimeMillis() . I chose this method after having some
issues with sleep() which is not accurate enough. When I want to stop
the metronome, I just have to set isRunning to false.
How can I evaluate the impact of this on CPU and battery ?
Thanks a lot.
Rgds, Alex
--
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.comandroid-developers%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Dianne Hackborn
Android framework engineer
hack...@android.com
Note: please don't send private questions to me, as I don't have time to
provide private support, and so won't reply to such e-mails. All such
questions should be posted on public forums, where I and others can see and
answer them.
--
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
[android-developers] CPU cost of a semi-infinite loop
Hi,
I'm working on a metronome application, so I need a rather accurate
time-measuring system to fire the metronome sound at the right time.
Actually I found a solution, but I'm wondering if my method will not
be cpu consuming. Here is the code snippet :
t = new Thread() {
public void run() {
long neededTime = 0;
while(isRunning){
long curTime = SystemClock.uptimeMillis();
if(curTime=neededTime){
neededTime = curTime + (6/tempo);
playSound(clickSoundId,100);
incrementBeat();
mHandler.post(mUpdateUi);
}
}
}
};
t.setDaemon(true);
t.start();
You can see I set up a semi-infinite loop with rather frequent
accesses to uptimeMillis() . I chose this method after having some
issues with sleep() which is not accurate enough. When I want to stop
the metronome, I just have to set isRunning to false.
How can I evaluate the impact of this on CPU and battery ?
Thanks a lot.
Rgds, Alex
--
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
