search

Arunkarthicknallasami / alogcat

Automatically exported from code.google.com/p/alogcat
1 stars 0 forks source link

Paused capture re-starts itself when coming back from black screen/lock screen #18

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Start aLogCat & Wait for logs to be read
2. "Pause" log
3. Screen goes dark while I'm reading
4. sweep screen or/and unlock
5. aLogCat restarted capturing and i need to pause/scroll up again

What is the expected output? What do you see instead?
aLogCat stays paused

What version of the product are you using? On what operating system?
aLogCat 2.1.4, Samsung Galaxy S I9000, Android 2.2 / Doc Froyo 7.6.2

Original issue reported on code.google.com by johannes...@gmail.com on 12 Nov 2010 at 5:34

GoogleCodeExporter commented 8 years ago 
understood. turns out this is not very easy to fix, at least with how i have 
the app structured now. here is why,

i could save the current set of log entries when the app pauses, and restore 
them when it is resumed. it could remember the pause. however, what it cannot 
remember is the context of where it was paused at. for example, suppose you 
have log entries 

1
2
3
4

and you pause the log. now the app is paused (screen goes dark). now you wake 
your device up and the screen again shows 

1 
2
3

now you play the log. since the app was paused, all it can do is load *all* of 
the log entries again. so you'd end up with a log like,

1
2
3
1
2
3
4
5

or something.

normally, how pause works is that it keeps reading the log entries and saves 
them up in memory until the user hits play. this way it doesn't lose the 
context of what it has already logged and what it needs to log after the user 
plays the log. 

perhaps, the right thing to do is just re-load all of the logs after a pause 
then play, and restore the log's paused state after an app resume. this 
degrades the pause functionality to some degree i think though.

Original comment by jeffrey.blattman@gmail.com on 14 Nov 2010 at 4:08

GoogleCodeExporter commented 8 years ago 
i have a prototype of this. could you give it a try?
http://code.google.com/p/alogcat/downloads/detail?name=alogcat-2.1.4.1.apk

when unpaused (played), it will re-read all the logs. it will not lose the 
state on orientation changes or screen blanks though, hopefully.

Original comment by jeffrey.blattman@gmail.com on 14 Nov 2010 at 7:20

GoogleCodeExporter commented 8 years ago 
Just installed and tried 2.1.4.1 - covers my use case perfectly!
From your explanation above I now understand why this is not an easy thing to 
do. 

My use of pause is usually this, maybe this helps:

- i start alogcat because of a) general curiosity or b) tracking an error to 
report the details to a developer. 
- when doing a), the old-pause serves better than the new-pause because I am 
able to pause for a moment and then go on quickly. 
- when doing b) I am just interested in one specific error that i want to keep 
displaying for as long as it takes me to read/transcribe/send/save the log. 
When i am done then i close it again.
the new-pause works much better in this case because of the screen 
blanking/locking.

Original comment by johannes...@gmail.com on 14 Nov 2010 at 8:31

GoogleCodeExporter commented 8 years ago 
updated test build,
http://code.google.com/p/alogcat/downloads/detail?name=alogcat-2.1.4.2.apk

with this one, as long as you don't rotate or let the screen blank, pause / 
play should work like before (case a). if you rotate etc. however you will get 
behavior b.

this also fixes several bugs that i introduced. as of now this is the candidate 
market build for 2.5.

Original comment by jeffrey.blattman@gmail.com on 15 Nov 2010 at 4:52

GoogleCodeExporter commented 8 years ago 
another possibility is to always restore the state, and *smartly* concat the 
new logcat output onto it. by smartly, i mean it would have to check if the log 
entry exists in the restored state. that means comparing it to every log entry. 
worse, there's not really a way to tell when to stop doing the compares, so in 
general it would happen for every cat'd log entry. this is probably not an 
option for performance reasons.

Original comment by jeffrey.blattman@gmail.com on 15 Nov 2010 at 4:59

GoogleCodeExporter commented 8 years ago

Original comment by jeffrey.blattman@gmail.com on 25 Nov 2010 at 4:37