I'm currently having issues with my widget. I'm using a Droid 2 phone and when I open the keyboard the screen rotates and my widget never calls the onUpdate() function call.
In efforts to debug the issue I overwrote the onReceive() and noticed that after the screen is rotated I get the intent action:
com.motorola.blur.home.ACTION_WIDGET_ADDED
After the rotation of the screen the TextViews loose their content so I need to be able to set text after the rotation. I usually set the text at the onUpdate() call.
Anyone have any ideas why this issue? I'm sure I'm doing something wrong...
Thanks,
-Jona
After a lot of testing and searching online I realized something so important about Widgets.
When the screen is rotated and the widget needs to be restored the Android system will restore it using the data from the last RemoteViews update.
I was updating parts of the widget separately so when it needed to restore only one part got updated.
The fix is always update everything on your RemoteViews all at once.
Related
When I rotate the screen on a tablet, my widget's list view disappears and the buttons become unclickable. I'm not sure what happening with the most recent remote view to cause this. Any suggestions?
Here is my onUpdate function
onUpdate
Since we do not have the full code, it's kind of hard to give an actual answer to your problem.
However, I might have an idea & the cause of your problem could be in your .XML file. The same way your app looks great in a certain rotation, most surely on the one you originally designed your work on, it is very possible that it might result in problems when you changed the rotation.
However, it all depends of the layouts you are using & how they are used. I would advise to share your entire code so we can go through it.
I was wondering why not use android:configChanges="keyboardHidden|orientation" in every (almost every ;)) activity?
Goods:
no need to worry about your activity been rotated
it's faster
Not so nice:
need to change your layouts if they are depending on screen size (e.g. layouts with two columns or so)
Bad:
no flexible way to have different layouts on different orientation
not so good when using fragments
But if we don't use different layouts, why not?
Quick Background
By default, when certain key configuration changes happen on Android (a common example is an orientation change), Android fully restarts the running Activity to help it adjust to such changes.
When you define android:configChanges="keyboardHidden|orientation" in your AndroidManifest, you are telling Android: "Please don't do the default reset when the keyboard is pulled out, or the phone is rotated; I want to handle this myself. Yes, I know what I'm doing"
Is this a good thing? We shall soon see...
No worries?
One of the pros you start with is that there is:
no need to worry about your activity been rotated
In many cases, people mistakenly believe that when they have an error that is being generated by an orientation change ("rotation"), they can simply fix it by putting in android:configChanges="keyboardHidden|orientation".
However, android:configChanges="keyboardHidden|orientation" is nothing more than a bandaid. In truth, there are many ways a configuration change can be triggered. For example, if the user selects a new language (i.e. the locale has changed), your activity will be restarted in the same way it does by an orientation change. If you want you can view a list of all the different types of config changes.
Edit: More importantly, though, as hackbod points out in the comments, your activity will also be restarted when your app is in the background and Android decides to free up some memory by killing it. When the user comes back to your app, Android will attempt to restart the activity in the same way it does if there was some other configuration change. If you can't handle that - the user will not be happy...
In other words, using android:configChanges="keyboardHidden|orientation" is not a solution for your "worries." The right way is to code your activities so that they are happy with any restart Android throws at them. This is a good practice that will help you down the road, so get used to it.
So when should I use it?
As you mentioned there is a distinct advantage. Overwriting the default configuration change for a rotation by handling it yourself will speed things up. However, this speed does come with a price of convenience.
To put it simply, if you use the same layout for both portrait and landscape you're in good shape by doing the overwrite. Instead of a full-blown reload of the activity, the views will simply shift around to fill the remaining space.
However, if for some reason you use a different layout when the device is in landscape, the fact that Android reloads your Activity is good because it will then load up the correct layout. [If you use the override on such an Activity, and want to do some magical re-layout at runtime... well, good luck - it's far from simple]
Quick Summary
By all means, if android:configChanges="keyboardHidden|orientation" is right for you, then use it. But PLEASE be sure to test what happens when something changes, because an orientation change is not the only way a full Activity restart can be triggered.
From my point of view: If the layout is the same in both landscape and portrait mode - you might aswell disable one of the two in your app.
The reason why I state this is that I as a user expect the app to provide me with some benefit, when I change orientation. If it doesn't matter how I hold my phone, then I don't need the choice.
Take for instance an app where you have a ListView, and upon clicking a ListItem you want to be shown a detailed view for that item. In landscape you would od this by dividing the screen in two, having the ListView on the left and the detailed view on the right. In Portrait you would have the list in one screen and then change the screen to the detailed view when a ListItem is selected. In that case orientation change makes sense as well as different layouts.
I don see why.... occasional restarts are ok in my opinion... configChanges handles most cases for me... well maybe in some types of applications this can be problem but it depends really on type of app and how you restore state when app restarts... When one of my app restarts user is logged back and last activity opens by my code and user jus loses some steps to go back where he was but not big deal.. In other some state is always persisted and some state is always restored on restart. When activity restarted it had to be that app have not been used or something... so no problem at all... In game for example this can be problem maybe or in some other type of app I don't know...
I say that when you do it this way applications just works fine under normal circumstances. And code is much more readable without ton of logic needed for saving and restoring where u just can make new bugs and have to maintain it all the time... sure if android gets out of power and kill you application window it lose the context and starts again, but this happen just in special situations and on newer devices I belive this is more and more rare...
So kill me, but I use this across applications quite successfully...
android:configChanges="locale|keyboard|keyboardHidden|orientation|screenLayout|uiMode|screenSize|smallestScreenSize"
But I understand that for some special kind of applications it may be not good way but most of apps can live with this just OK.
Yeah I think pausing will make it quicker than releasing the player. Still have the pause though.
Have now found a solution that won't pause the song.
State in the manifest that you will handle the config change for screen orientation and then use the onConfigurationChanged method to load the layout file. By doing this in logCat I can see onPause, onCreate & onResume aren't called, and therefore the song isn't paused.
update the manifest to handle the orientation.
android:configChanges="orientation|screenSize"
add this code
#Override
public void onConfigurationChanged(Configuration newConfig) {
// TODO Auto-generated method stub
super.onConfigurationChanged(newConfig);
setContentView(R.layout.activity_main);
}
I have a Widget with his android.appwidget.action.APPWIDGET_CONFIGURE Activity with some preferences witch I can set before adding it to the "desktop".
My problem is that the preferences does not get applied because I noticed that as soon as the APPWIDGET_CONFIGURE is called, the widget is created and never refresh after the widget is actually applied to the screen and it actually never reads the updated preferences.
Any thoughts?
Thanks
Oh, I think I found what it seems to be an easy solution but I don't like it much so I like to have a "second opinion". I don't say what it is to not influence the answers.
PS. The configuration activity works fine, the problem is only when the widget is applied for the first time.
The (easy) solution I found is to call an update on the widget after closing the APPWIDGET_CONFIGURE Activity.
The "dirty" thing I don't like is that you actually "draw" the widget one extra time.
When system enters into TouchMode, I'd like to know which widget will lose focus. When system quits TouchMode, I'd also like to know which widget will get focus. Overriding onFocusChange() didn't satisfy me, since it couldn't tell TouchMode change, since it could happen in every mode, touch, trackball, key navigation, etc.
SDK said only one API View.isInTouchMode() there it is. So, is it possible to detect TouchMode change?
Long shot but you probably need to maintain states manually. So you keep a a flag , lets say isTouchMode which you can set every time any of the widgets are touched and unset when something gets focus.
Use ViewTreeObserver.addOnTouchModeChangeListener(). It will tell you when the mode changes.
http://developer.android.com/reference/android/view/ViewTreeObserver.html
I have code in an appwidget that I want to run when the phone's orientation changes on the home screen, ie like when the keyboard flips out. I have an image that I want to change in an imageview in my appwidget. I can't use different layouts linked to the orientation (ie "layout" and "layout-land") because I don't know the name of the image file until runtime, it is created at runtime. Is there anyway to trigger code to run only if the home screen is shown, my appwidget is active and the orientation just changed?
I could listen for a configuration_change broadcast but that will run everytime the phone switches to landscape or portrait and I only want it to happen when the homescreen is shown. I cannot think of any good way in android to do this. Thanks
Ryan
There isn't a good way of doing this for images generated at runtime.
One approach would be to build both versions of the image and have two ImageViews that are visible depending on the layout/layout-land being used. (So the RemoteViews would update both ImageViews, but only the correct one would be visible.)
Jeff, what is the reason for this limitation ? I would love to be able to use images generated at runtime, or construct the RemoteView on the runtime as well, rather than use the precompiled XML - this is so inflexible.
There is more info at http://groups.google.com/group/android-developers/browse_thread/thread/0eb7c016be05e0b9/d31b312e2fa8530d
Basically update the widget from onConfigurationChanged() in an Activity and add android:configChanges="orientation" for that Activity in your manifest. Bad thing is, this doesn't cover all use cases.