Does anybody know how to cope the problem?
Using the android.app.Activity#setRequestedOrientation(SCREEN_ORIENTATION_LANDSCAPE) method almost always causes the showing a black screen for a split second during the rotation.
But if I rotate the smartphone itself, then the black screen never appears.
How to get rid of the black screen? Is it the Android issue of the setRequestedOrientation() method, or I do something wrong?
EDIT: AFAIK the black screen with setRequestedOrientation() call could happen if we have quite heavy layout, when it takes some more time to initialize it in the UI thread. If you try to call setRequestedOrientation() for instance in a "Hello World!" app with a light layout, you won't see the black screen. So, the loading on the UI thread can be the cause of the black screen when you rotate with setRequestedOrientation(). But, in other hand why it never appears when I rotate the screen changing the phone orientation?
The only solution I've found.
Consider I want to turn screen to landscape and what do I do:
I remove the root Fragment with heavy stuff from the Activity I want to rotate.
Inside the Activity I want to rotate I open an empty white Activity for a moment to cover the black screen. The Activity is calling setRequestedOrientation(SCREEN_ORIENTATION_LANDSCAPE) in its onCreate callback and closes itself after the timeout = 500 ms. I open/close the Activity with fade-in/fade-out animation.
Inside the Activity I want to rotate I call setRequestedOrientation(SCREEN_ORIENTATION_LANDSCAPE) post delayed with 100 ms. This starts the rotation.
After the rotation complete, in the onCreate I add the removed Fragment back.
That's it. Rotation to landscape is finished and the black screen was completely covered.
Edited:
I had the same problem. In older versions of android, if the content of the layout is heavy (if it contains high resolution image, etc.), the running activity is trying to re-create the layout to change the orientation but can't achieve this.
As a solution, we can create 2 different layout resources as portrait and landscape, specifying which one we will use and making it easier for the android.
Related
I'm trying to make a UI which when the device is rotated, the icons get rotated.
Normally, when a device is rotated the onXXX lifecycle methods get called, and I'd like to avoid this when the screen orientation changes and would like to rotate the icons on the main UI instead. How can I go about achieving this?
I have WebView that is added on top of the running activity. I like this WebView to always show in portrait, so I rotate it if the application is in landscape, but calling setRotation() causes the WebView to go blank, i.e. setting the rotation to any value that isn't 0 causes the page to show up blank.
I'm not really sure what's happening (I used to think the page just shows up off screen, but it's blank for the smallest of values too), but is there a way to get around this?
My friend found the answer. You have to turn off hardware acceleration.
webViewInfo.setLayerType(View.LAYER_TYPE_SOFTWARE, null);
My application is bitmap intensive, with pixel-exact layout (it's a sort of game, actually, and it's pretty hard to avoid this pixel-based coordinates).
What I wanted to do is to perform some layout calculations and bitmap pre-scaling in my onCrete - I use well known API - getWindowManager().getDefaultDisplay().getSize() - to retrieve the screen size and do my calculations.
However, I've just hit an unexpected problem. My activity is configured as landscape only, but if I start my application on emulator and onCreate() is called while the emulator is locked, the screen size returned by getSize() indicates portrait orientation. Once I unlock the screen, onCreate() is called again, this time correctly in line with expected landscape mode dimensions.
I'm not sure how to handle this situation. I see the following options:
for each onCreate() call perform full layout calculation and resource scaling again. This is the logically correct solution, but I don't want to the same work twice, just to throw away the first result.
if onCreate() is called for portrait mode, just do nothing, and set black background (I can see there's a silly rotate animation when I unlock the screen, so this would become pretty much a fade-in animation)
Actually I'd prefer second option, but I'm slightly afraid of any side-effects. Anyone faced this problem?
Update (2012-07-08):
I've probably assigned a slightly misleading title to this question (sorry!), as the problem is not in retrieving the dimensions itself, nor calculating the layout. It's more about the activity being first created in portrait mode, and then recreated in landscape mode again, despite being declared as landscape-only. I initially expected (reasonably, huh?) the activity to be created in landscape orientation only.
I eventually decided to fill the activity with black color when it's created in portrait mode, no side effects observed. On Android 4.0 I can see actual rotation animation when I unlock the screen - a bit strange, but well, I guess it is supposed to inform the user that she should rotate the phone. Given that in portrait mode I just fill the screen with black color, this animation looks sort of like a fade-in and rotation combined - perfectly acceptable.
Use that
DisplayMetrics dm=new DisplayMetrics();
this.getWindowManager().getDefaultDisplay().getMetrics(dm);
Using this(Look code at down) only gives you screen size and if your views has static size they will be seen in different size on every different screen.
Display screen=getWindowManager().getDefaultDisplay().getSize();
How to use:
every screen has diffrent density. So use:
float density=dm.density;
with this density, you can set your views size like that:
(YOUR_ITEM_SIZE)*density;
also look here for additional information:
http://developer.android.com/reference/android/util/DisplayMetrics.html
if the emulator is locked , can't you assume that the user can't run anything anyway , so the app doesn't need to handle this end case ?
anyway , as bmavus wrote , use getMetrics for getting the screen size . also , if you need to change the screen orientation of the app , you can do so either in the manifest or in code.
for games , i would advice using opengl solutions , and if you don't have much time digging for it , you can use third party engines that can help you , such as andengine and libgdx.
I have a video that plays in portrait mode. At the end of the video, I need to display some views over it. This works fine so far.
I am however, having a problem where views that are over the last frame of a video don't redraw properly when coming back to the activity after turning the screen off, then on again, then unlocking the screen.
What i'm observing is that when the screen comes back on and I unlock. My video and images are first rendered outside of fullscreen mode (with the status bar still showing) then the screen will go into fullscreen mode shifting all of the views up and causing artifacting.
It seems like the views are being shifted out of their view bounds by the transition to fullscreen after they are rendered.
I'm really stumped as to how to prevent this from happening.
Here is the sandbox project on github to avoid making this a post full of code.
The basic setup for the project is this:
Fragment activity has a video view and a button view on it's layout.
It then adds a fragment into a contentView container. The contentView fades in 1 second prior to the end of video playback.
Everything works smoothly and the problem is with returning back to the app after powering the screen on and off.
Also, sometimes the video will just drop out entirely, leaving the views sitting atop a black background.
Thanks in advance for any help you can provide.
Here's the artifacting that happens when you turn the screen off, back on, and unlock.
Note that I had to take a picture of it. On DDMS the screenshot tool sees the images properly.
rather than prevent the screen from turning off, you can opt in to receive an event when the user unlocks the keyguard after waking the phone.
At this point, it might be a good idea to call View.invalidate on both of your views, this should cause a redraw. The draw chain is very flaky while the lock screen is up, because your app is technically visible, just under the lock screen.
registerReceiver(new BroadcastReceiver() {
#Override
public void onReceive(Context ctx, Intent intent) {
if(intent.getAction().equals(Intent.ACTION_USER_PRESENT))
}
}, new IntentFilter(Intent.ACTION_USER_PRESENT));
It looks like the overlay layout was shifted by controller bar.
Don't you think it was affected by controller (play/pause/ff/rew + progress) area?
there may be a way to prevent the screen going off in 1st place as this would be good resolving your re draw issues, hope this helps.
I encountered weird problem when changing screen orientation rather fast, or when something heavy goes on background. When I call setContentView(R.layout.main);on onConfigurationChanged (I handle orientation changes myself),after screen is rotated android for a brief moment sets layout for opposite to orientation. For example - when you change orientation layout changes like this Portrait>Landscape, but sometimes, in my case, it goes like this Portrait>Portrait(when phone is already in in landscape position)>Landscape.
Sometimes you dont even notice this, and sometimes screen shrinks to about 1/3 for a second.
Well, It's not really a big deal, but in my activity I have Coverflow widget (based on Gallery) and to make it look good on most of the screens I set image sizes based on parent container size (in onSizeChanged of widget), and when orientation changes goes as described above coverflow widget picks up a wrong size.
The only way I see now is to either call onCreate on orientation change (Which I cant do, because of heavy UI populated online), or set a delay on initializing UI (which is ugly).
So I wonder, is there any callback of setContentView() or anything else, so I could know when layout is actually ready, so I can init UI.
Or maybe there is another way around?
PS: For some reason this glitch mostly occurs on Desire HD.
AndroidManifest.xml
android:configChanges="orientation"
Is it what you expect?