I'm looking to change the screen orientation based on device type. The case is that our development platform is hooked via HMDI to an LCD (and is fixed), and then tested on an actual handset or tablet. I want the development platform to always appear in landscape, and everything else in portrait.
I wrote a little static method that accepts an Activity object and calls it's setScreenOrientation if the device is a certain type. I place the call to this method in the Activitys onCreate, passing itself as the parameter. Alternately, I placed it in the onStart as well. The issue is that it's leading to unpredictable behavior. I suspect the Activity is being restarted by the call to setRequestedOrientation. The API does state that "it is possible for the Activity to be restarted" by calling this method. Sometimes it will change orientation a few times before settling out, sometime it won't, and it always seems to crash the application.
I guess the question becomes: How do I set the orientation for an Activity that hasn't been started yet without using the Manifest?
Any help is appreciated.
Thanks,
Brian
You can't set the orientation dynamically before you actually run.
If you want your orientation to vary, you should use one of the orientation modes: the default one allowing it to vary based on the device preference and how the user rotates the screen, "nosensor" to use the device's preferred orientation without allowing it to changed based on the user rotating the screen, etc.
Related
First of all, here are things I've done so far: (1) I handle screen rotation, orientation changes and Multi-Window related config changes inside my application. (2) I forbid all kinds of configChanges:
android:configChanges="orientation|screenSize|smallestScreenSize|screenLayout
Everything works just as intended, well until I enable screen-rotation from Android settings in Multi-Window mode.. When I do so, my app starts rotating inside its split-screen portion as if I enabled orientation, which I did not enable, hence my configChanges parameter above states.
Don't get me wrong, I don't mind the second app (in the side window) to rotate, yet I want to handle my own app rotation in my own portion of the split-screen..
I recon this problem might seem a bit strange, but I'm open for any suggestions. Maybe, you've got an idea or had a similar issue before.. any and all help is appreciated.
I have a game activity which was previously declared as "landscape" in AndroidManifest.xml.
I experimented with using "sensorLandscape" in order to support the reverse landscape mode, and I expected the activity to be recreated each time I rotate it - like the switch from portrait to landscape.
To my surprise, the activity just rotated without recreation (tested on Nexus 4, stock Android ROM).
The question is - can I count on this behavior? Or am I supposed to add code to handle configuration changes just because I support reverse landscape? It looks like I don't need to do anything, but who knows what devices I might encounter... Writing the state saving code might be really time consuming in my project, that's why I'm concerned whether it's even needed.
Interesting question. Here's what I found here:
Note: When you declare one of the landscape or portrait values, it is considered a hard requirement for the orientation in which the activity runs. As such, the value you declare enables filtering by services such as Google Play so your application is available only to devices that support the orientation required by your activities. For example, if you declare either "landscape", "reverseLandscape", or "sensorLandscape", then your application will be available only to devices that support landscape orientation. However, you should also explicitly declare that your application requires either portrait or landscape orientation with the element. For example, . This is purely a filtering behavior provided by Google Play (and other services that support it) and the platform itself does not control whether your app can be installed when a device supports only certain orientations.
In general - the sensorLandscape is not re-creating the Activity.
On say a Samsung Galaxy S3, it's possible via an application's manifest, to allow it to run in multi-screen mode. Thus when it is running, a second application can be dragged onto the screen and each application then has half (or may be different amounts) of the screen.
When an application is running full screen, how can it tell if another application has been dragged onto the screen, and thus it now only has half of the screen real estate?
The activity is not restarted, and the onConfigurationChange method is not invoked.
Section "3-8-9. Handling Layout Changes" in this document http://developer.samsung.com/s-pen-sdk/technical-docs-09 gives the answer.
Note, you don't need the Samsung SDK to detect the change.
I'm writing a game for Android and am laying out the playing screen myself, handling both vertical and horizontal orientations, and haven't done anything if the width and height are the same.
Does anybody know of at least one Android device that has a perfectly square screen resolution?
The MotoACTV is 220x176 (not square but close), the WIMM One is 160x160 (square).
The MotoACTV has been rooted, but the default device runs a customized Android. It's a pretty cool device, though. The WIMM is slick and runs a more-standard Android.
None the I'm aware of. Every device I'm familiar with has a distinctive "portrait" vs "landscape" mode.
It would probably be wise to make sure your code can always gracefully handle portrait vs landscape - even if you ever happen to run across a square device.
Conversely, if you want a square - just "crop" the image appropriately. The cropping, of course, will become "zero" if you ever encounter this hypothetical "square screen". :)
This is a rather late answer to this question, but things have changed somewhat since then, and although there are still no mainstream Android devices with square screens, there are 3 square BlackBerry devices (Q10, Q5, and Passport) that can run Android apps, and so would fall under that criteria. Interestingly, when an app is run on a square BlackBerry Passport, and the device is rotated to its side, the app also rotates, however none of the onPause(), onStop(), or onDestroy() events are called, and so the activity is not destroyed and re-created, but the current activity layout is re-used. So, in that respect, nothing happens, and you don't have to worry about saving/loading resources and such.
This behaviour is actually built-in in Android -- it will only destroy and re-create an activity, if the screen dimensions change. The API docs don't talk about this edge case, as there are no square Android devices, but you can see that the reason for destroying and re-creating the activity during orientation change is to load alternative resources specific for the new orientation. Since rotating a square device doesn't change the screen dimensions, there is no need to load alternative resources, and therefore, there's no need to destory and re-create an activity. I hope that helps.
I believe the WIMM ONE is the only square screen Android device out there. It has capacitive touch display at 160x160.
Yes, the Motorola Flipout is one.
I developed a pretty simple game that uses a custom view for drawing to the screen. On my phone (Android 2.2), I can press the home button on the device and do other tasks. When returning to the game, it is restored to the exact state that it was before. The thing is, I didn't have to override any methods or really do anything for this behavior to occur. However, on Honeycomb, it resets everything like I would expect.
It's very puzzling... I was wondering if there was a way to make Honeycomb behave like 2.2 in this regard. I'm not too familiar with saving view states, but since I have a LOT of variables (hundreds, depending on how custom objects are saved), I imagine it being unpleasant to manually do.
I was able to solve it. Kind of.
Basically, the problem was caused by the way that Android handles the screen being fixed to portrait mode in my activity. In 2.2, Android would open the activity in portrait mode and not restart the activity. However, in Android 3.0, it opens the activity, and THEN rotates the screen, causing it to restart the activity (since that happens when a rotate happens).
To fix this, I added the following to my activity in the manifest:
android:configChanges="keyboardHidden|orientation"
This tells Android that you will handle config changes yourself. In my case, I do nothing, since my application is locked in portrait mode.
The reason the state isn't cleared when the application is paused is because onCreate() doesn't get called. I am aware that Android can kill the application though, which would call onCreate(), so I will still have to handle that situation by saving the Activity variables and recreating the View with them.