I do have a more general question, without any specific code. I will explain what my application does and how and what issues I can monitor. Maybe one of you had the same issues and can lead me to the problem.
The App:
It reads car diagnostic data (OnBoardDiagnostics) over Bluetooth and shows them in real-time in a ListView. I can start the update function by a "update Button".
How:
Everytime a new value is received via Bluetooth, a background Class (which handles the Stringforming) sends an Intentto notify the UI to update the ListView.
The Adapter Class of my ListView has the listening BroadcastReceiver registered and if it gets triggered, it will notify the ListView by notifyDataSetChanged().
Issues:
1.If I use an WakeLock to keep the screen on, the UI refreshing slows down after approx. 10 minutes.
2.If I press the power button, so the screen is off, it still slows down (I can see that, because I send the values to an webserver) but furthermore: If I turn the screen back on. I see the ListView stops for about 20-30 seconds and than normally continues with normal speed (not slow anymore).
So.. I think this is a very general question. I searched for WakeLock and sleep behaviour, but I couldn't find any similar issues. Maybe one of you can give me a hint, what the problem could be. Maybe one of you had a similar problem.
Any hint is appreciated!
EDIT 1:
Maybe the problem of the 2. issue is based on the lifecycles of my objects / activity.
If I press the update Button, an AsyncTask is started, which sends the Data (JSON, which contains one new value for all list items) to my Webserver. If the device screen is off, I still get the data every 2 seconds. If I turn on the screen, it stops for these 20-30 seconds as well as the UI. So I think my UI works fine. The Update Intents were sent right.
I have to check if I still receive new values in that background class, mentioned above.
Thanks to zapl
Thanks!
Except all possibilities I checked, i came across this article:
AsyncTasks for long running Operations
Short: There are some points you need to keep in mind if you are using AsyncTasks in very long running operations (>20min). My Problem was, that I used the AsyncTask as an inner Class. After a long period, when the Activity that created the Task was destroyed, the AsyncTask still kept a reference of this activity.
After I used a Bus, described in the article above, the UI worked fine!!
So, if anyone else noticed performance problems of your App, I recommend that article.
Thanks for all the other hints!
Have fun coding!
Related
I have some confusion in mind. Being new to android, I am writing an App which should:
check if bluetooth is available
if it is, enable it if turned off
scan for nearby devices and show them to the user
the user clicks (chooses) a device
the app, cyclically, pools the device and shows it status
while polling, the user can ask for more operations (other activities on the same device), then return to main screen
Passages from 1 to 4 are mandatory, but it seems difficult to lay them down in a straight (simple) manner: the main activity, which calls two intents (to enable BT and to scan devices) seems to interfere. It seems that the main activity's onCreate is called too often...
Question #1: should I do all the work in the onActivityResult() method? Or should that method be used to collect results, and the true work should be done in onResume()? I say so because while in step 5, when trying to launch other activities, android complains about "not having a context and you need to set the flag NEWTASK in the intent - "is that really what you want?")" (sorry, can't remember the exact message).
Moreover: the main screen shows some statuses from device, refreshed via postDelayed(), and also accepts button's clicks. When the user clicks a button and a new activity is created, what happens to the main activity? Does it lose its variables, context, or whatever? In that loop, I don't need anymore any result from the user clicked activities, so question #2 is should I use onResume? Or is onCreate() called again? If using onResume() I need to keep track of the app status, where to store that status? I am using a static global class, and it seem to work, but I've read that it is not a good idea.
I know this question is kind of a mess, but I've read google documentation and many questions here in SO, and found a mess. In this moment the app is more or less working, but it does strange things at times and, worse (question #3) by using it a few minutes it gets slower and slower - can it be it leaks memory, or it creates too many threads because of postDelayed()?
For some strange reason, which I'm not entirely sure why, I'm getting not only an ANR for my application, but also of the entire systemui. It's so bad that I HAVE to reboot, and after rebooting it has to "Optimize" all of my apps like it corrupted something (anyone have an explanation as to why this happens?).
I'm assuming that parts of my code are so bad that they're causing this, but should even malicious code be able to overload the systemui? Anyway...
What I am doing is that I'm attempting to launch a service to handle screen recording. The activity (from a fragment) asks for permission (which is obtained, and I see the Screencast icon in the top right corner of the screen), then it binds a service which handles any state changes. What I mean by state changes is this...
States:
Dead - Means it needs to be initialized and prepared
Alive - Means it needs to be start and is fully initialized/prepared
Started - Means it is currently recording.
Paused - Means it will start a new video after starting again, which it will combine all temporary videos into one (haven't worked out that details yet).
Stopped - Means combine any and all files into one, then send the URI through an intent in a broadcast (haven't gotten this far yet).
It goes from Dead -> Alive -> Started <-> Paused -> Stopped -> Dead. At least that's the overall plan. I plan on having a floating button that acts as remote for controlling the service, and hence broadcasting on a receiver (local) to my fragment which is waiting for it to be finished.
Now, enough of what I intend to have, lets get into what I have right now. It's kind of a mess, I've never done this stuff before, hence why I'm asking on here. Trust me when I say that I have tried a lot of stuff, and the unfortunate bit is, the only way to test out a new solution is to reboot and wait 15 minutes while Android optimizes everything again. Now I understand it's a "Long" code-segment, but I'll say that one place it crashes is stopRecording(), at line 216.
Code here.
Let me know if I should make any changes.
Lastly: Should any of this be run on another thread? Could that be the issue? Why doesn't the app crash only instead of systemui?
I have developed an application that is used very intensively for hours, makes a lot of web services calls, uses a lot of async tasks and does a lot of operations on an sqlite database. The problem is that absolutely randomly the display dims, as if it goes in power saving mode (this is happened also when the battery was charged) and the UI does not respond at all (the log written for buttons click are not written). If I click the home button the phone works correctly and every app works fine. If I go back to my app the display dims again. I really don't have any idea about the cause of this behavior, I really hope some of you can help me because my boss wants an explanation because the customer wants an answer.
EDIT: I've noticed that when the problem occurs, it's just after unlocking the screen, so it should have something to do with app resuming, but I don't really have any idea of what is causing this behavior.
It seems that some operations may be blocking the main UI thread and the app goes to not responding state. Check if any such intensive operations are done in UI thread.
As jaibatrik says, this might be caused by doing too much work in the UI thread rather than in background threads, AsyncTasks etc. One way this may be achieved which is less obvious is if all the work is correctly done in a background thread (of some type) but a UI thread operation is waiting for the outcome of a background thread operation.
you could prevent display dim like this.
ll.setKeepScreenOn(true);
you should handle onresume(), onpause() & co.
maybe you create memoryleaks within your backgroundtasks or services.
I have a ListActivity that instantiates an AsyncTask, makes a call to a web service, and populates the ListView with the results.
How should I handle device rotation while the AsyncTask is still running? Should I cancel it, save off whatever data I need, and start a new one when the ListActivity is recreated? Does Android somehow already handle such a case?
It seems like what you require here is a service, not an Asynchtask - as you are running a long query that should persist and deliver it's results the same way regardless of orientation.
BTW, killing the Asynctask is NOT straightforward - best not to go there at all, but let a service run truly in the background.
Do you require that your ListActivity is recreated on orientation change? I would expect that your users would not want that - but would rather have the populating of the ListView carry on.
I have an app that does a series of HTTP GETs and POSTs within a string of AsyncTasks, without restarting the activity each time the orientation changes. All you need is a line similar to the following in your manifest.
android:configChanges="orientation"
See the docs at http://developer.android.com/guide/topics/manifest/activity-element.html
Torid's suggestion of overridding the config changed handler works in most situations. However, I've found that some manufacturer's devices still recreate the activity, even when you've done this (I've seen 1 HTC phone that does it so far).
The proper solution is CommonsWare's answer in the following link:
Background task, progress dialog, orientation change - is there any 100% working solution?
can someone please help me?
I would like to write a program which uses a service to periodically update a text view on an activity.
I do this by having ActivityA with a 2 buttons to start/stop my service. In the service I run a timer which triggers every second. From here I need to have this launch and update a text view on ActivityB which at present is just a counter value.
I'm sure there are likely better ways to do this, such as using only one activity, maybe using a thread but the main design consideration is to have the service running even if my activity is destoyed (the counter value would instead go trigger some alarm or file write instead of a text view update).
Sorry for rambling. I find the android developer resources offer too many solutions!
Thanks
Ben
In the service I run a timer which triggers every second.
Why? Most Android devices run on batteries. Batteries are never big enough. What value are you giving the user to justify your expenditure of CPU and RAM (and, hence, battery life)?
From here I need to have this launch and update a text view on ActivityB which at present is just a counter value.
Where is "here"?
I'm sure there are likely better ways to do this, such as using only one activity
I would think so.
maybe using a thread
Probably not.
but the main design consideration is to have the service running even if my activity is destoyed
This is significantly more complicated than you are perhaps thinking.
(the counter value would instead go trigger some alarm or file write instead of a text view update).
If your goal is to do something at a particular time, use AlarmManager.
I suspect that there is a better approach for whatever it is that you are trying to do than the path you are presently headed down. Unfortunately, since I do not know what it is that you are trying to do, I have limited ability to provide more specific advice.
I think what you want to do is at best done with an simple AsyncTask. If you use the onProgressUpdate method you can increase the value in the textview at every time you reach a certain point during your background work. It is also able to cancel the background work etc. There is no need for the full Service, Thread work.