I am trying to implement a Appwidget using view flipper. I declared two views in my view flipper and everything working fine. Now from developer options select "Don't keep activities option" and come back to home screen. You will find appwidget with viewflipper is hang.
Remove appwidget from screen and resinstall. It will start workin normally till you are on home screen. Launching any activity will result in same problem. Your appwidget stop working.
From the logs there are nothing coming to your appwidget provider. Every time we launch any activity Home screen activity get killed.
This problem happens every time with ViewFlipper in particular.
I am really frustrated, with every new release Google adding more instability. Android should decide either handle activity cycle OR simply handle it like iOS.
If any body able to get around this problem with View flippers on Appwidget please enlighten me. Or If anyone think better not use viewflipper on appwidget , please share.
Oh! this is my problem, I thought I just wasn't handling low memory situations with the appwidget id's correctly
this app uses viewflippers on a widget https://play.google.com/store/apps/details?id=co.ccltd.maplights.nyc.freemium&feature=nav_result#?t=W251bGwsMSwxLDMsImNvLmNjbHRkLm1hcGxpZ2h0cy5ueWMuZnJlZW1pdW0iXQ..
what I did increase the widget update time, which is now 30 minutes. for my particular application this is adequate. Basically it the viewflippers and pendingintents will hang after android deprioritizes it (won't even be able to get a response after a click), but after the widget updates it will be working again.
or so I think, more testing is needed! but its good to know that its not only my handling of appwidget ids in low memory situations, but possibly a glitch
Related
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!
I want to know the average start-up time of all the apps on android device. And this is supposed to be done by my app. So, is it possible to get such information from the app level programatically?
I assume you mean the time it takes for a given app to complete its onCreate() method. You might be able to do something on a rooted phone with extending onCreate() with a timer that logs to somewhere for your app.
This isn't going to work. You would have to start an app and time it, but you do not have access to the information about when another app has finished loading. Furthermore,.. how do you define start-up time? The time taken until the app opens or the time until past the loading screen.. or the time until past the splash screen...?
The way I am trying to solve this problem is by using a service to monitor the logs that will start a timer when app X is started. We have that working properly. The problem we are having is how to define the app as done loading. Once we have that we can gather data. But I am still looking for a way to know when app X moves from the onCreate() method from one activity to the onCreate() method of another. This will obviously only work for apps that have a loading activity for their app.
Effectively, this a really hard problem to both define and solve. If you ever come up with anything different than what I have, I'd love to hear it.
I know how Android works concerning killing not needed processes if the memory is needed by another app, bu I dont like the following behaviour of the App I develop at the moment:
I start my App, which has a lot of different screens/activities
After using it, i push the Home Button of my phone and switch to some other App.
(Lets say I did this while Activity C on Screen C was active).
My phone is a HTC One X, I checked, that there are always about 300MB of Memory available, when I run the Apps I usually need.
The Problem:
Even if I restart the App after a couple of days without using it, the App restarts with Activity C on screen C. In my opinion, after some days of not using the App, it should restart with the "Welcome Screen" i created.
As there are no Backgroundprocesses or ressources used (all these stuff is done by pushing buttons and has to be finished - so no automated backgroundprocesses are needed), I think, Android does not feel the need to kill it.
Does anybody know, how the "Android Best Practice" looks like for this or where I can read what behaviour the App should have in this case?
(... I am not looking for Code, but I dont know what way I should go to solve this)
Many Thanks for any help
I think you can easily do finish() the activity's on onPause() method.
Not sure whether this is a best practice. Awaiting other answers.
If I'm not mistaking, the following flag can help you when used by an Intent starting a new Activity: FLAG_ACTIVITY_NO_HISTORY. As the documentation says:
f set, the new activity is not kept in the history stack. As soon as the user navigates away from it, the activity is finished.
So if all your Activities, except of the welcome screen, are started using this flag, next time a user comes back to your app he arrives at the welcome screen. The drawback of this solution is that if a user receives a call while working with your application, he will also be transfered to welcome screen when the call is finished. Don't know if there is any other solution. Hope this helps.
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?
My app has a 1*4 icon size widget.
When a user tries to add a widget I provide with a configuration screen. and some data is collected - it is verified by the server - it is added to the local DB with appWidgetID as the key - all is good.
when user hits save, if there is not enough space, he is given a polite toast - "No more room on this home screen".
Now my problem is that the application is not informed of this. Application still assumes the widget was created and sits back and wait for the broadcast to update the widget after certain amount of time.
Can anyone tell me if i can find out via a broadcast or a call back or any method possible to determine if the widget was not successfully created, so that i can mark that record in my DB as deleted.
Or better if i can know the space available beforehand via some magic ninja code.
my whole application design is disturbed because of this problem.
please help.
This has been fixed in either 1.6 or 2.0.
Have you checked to see if onDeleted() in your AppWidgetProvider gets called in this case? I haven't tried it, but I would hope that would work.
If that doesn't get called, you can try onDisabled(), though that will only work if there is no other copy of your app widget on the home screen at the time.
I believe this is currently a bug in the OS where the onDeleted() method never gets called if there isn't enough room for the widget on the screen. I know I've seen this at least up through Android version 1.5. There is no fix that I'm aware of.