Our application could support landscape mode without any problem, but it is such a pain that we are thinking about forcing portrait mode.
Question: Is it BAD?
The main problem is that changing orientation generates random crashes on many screens. Avoiding those crashes would potentially allow us to spend more time on the core aspects of the app. Will the same crashes happen when users switch apps anyway?
Also, are there landscape-oriented devices where our app will become useless?
There is one area that might be unforgivable.
If a user interacts a lot with your app using a virtual keyboard, you should be vary of one thing:
There are emerging Android phones with a sliding physical keyboard that's meant to be used only in landscape mode. An example of such a device is a HTC G1.
Since such Androids are usually a premium, their users are very proud of having a physical keyboards. And if your app doesn't allow them to use their keyboard when they can use it, they will hate your guts for it and they might even give you negative ratings on Android app. market. Yes, it sounds cruel, but that's life.
Otherwise, having a portrait mode only application that runs well and isn't buggy is more than acceptable.
Moral of the story: try to make as many of your customers happy as possible. You won't always succeed, but you might fail if you piss even a minority of them off.
An unstable app or an app with a poorly thought out, landscape-unfriendly UI is much worse than an app with is limited to portrait.
There are probably some devices where a portrait-only application would be unwieldy, but the majority would handle it ok. Your best bet is to limit the orientation until the Android landscape or your business priorities make it more important to support those devices.
The crashes are probably caused by the activity restarting when changing orientation. With a configuration change you can prevent that without forcing the app to be in portrait mode all the time. Add the config changes line and it will prevent the activity from restarting.
<activity
android:name=".active.help.HelpMenu"
android:label="#string/help_string"
android:configChanges="keyboardHidden|orientation">
Related
We are an OEM working with an external app developer. The app they have written locks to portrait with android:screenOrientation="portrait" in its manifest. It also disallows resizing with android:resizeableActivity="false".
Our device is designed for use in vehicles and as such operates as a vehicle control head. It does not support portrait mode; any apps that request it are resized to allow landscape display. Because of the aforementioned attributes in the manifest, the app always displays in screen compatibility mode, with the UI squashed in the centre of the screen.
We've tried a number of different solutions. We tried setting the orientation programmatically instead of the in the manifest, but this causes an initial rotation on some handset devices that the app already supports, and which was deemed unacceptable by their QA team. They maintain that the attributes in their manifest mentioned above MUST NOT be removed.
Has anyone been in this situation? Are there any fixes on the application side that we've missed? Would they have to revise their decision to statically disallow resizing?
This issue seems to occur on some Android devices, notably the Kindle Fire. I'm currently developping an app that runs in Landscape Right and Landscape Left modes, but it seems on some Android devices it starts up on one side then cannot be rotated afterwards.
I'm using Unity 4.3.4f, and my settings are set to support both landscape modes and is set on Auto-Rotation.
Also, I've made sure the problem isn't about the auto-rotation being locked on my device, so it must be something related to my app settings.
Any reason this works on some devices and not on others ?
Note : This issue doesn't occur on iOS devices.
UPDATE : This issue occurs only sometimes on some devices. Sometimes rotation will work fine, other times it just will stay stuck in one direction. Same build, upon killing the app and restarting it may work. Kinda confused as to why this is happening !
Check if in this devices you dont have the rotation blocked in settings.
I do have a problem and have very little to go on. I'm about to release an App (created with Air for Android As3) on the Samsung App Store and just got a list of issues that have to be resolved after the app has been tested by samsung staff before the app could be released.
I did manage to solve almost all of the issues, but 1 very important one is beyond me. They say the screen turns/stays black, when returning after the device alarm interrupted the app. This issue practivally happend on all their devices, including a group including the phones I own (e.g. Galaxy S3).
I do have "OnDeActivate" and "OnActivate" listeners in place that are there to pause the app, disable sound etc. if it loses focus, gets minimized etc., yet I checked on my devices and I can't reproduce this error. Meaning if the app gets interrupted on my device by the alarm, I can resume it without any problems. no black screens.
So the question is: Is there any way for me to fix that at all? I do have to work within AirForAndroid AS3 so I guess possibilities are limited. Any clues where I can look? Any listeners to set, or is there a way to maybe "force" the app to reinitialize or refresh the display? Or to listen for the system alarm? Help would be much appreciated. Thanks in advance!
I am trying to overcome the same issue, I read somewhere that setting the stage quality to something else on both the activate and deactivate events might solve the issue.
So just set your stage quality to medium or whatever different in the deactivate and set it back to what it needs to be in the activate.
This should make AIR snap out of that black screen for the alarm (I hope)
An app of mine is with this fix is currently undergoing testing on the Samsung App Store.
I hope it fixes it.
Good news, the dirty fix of toggling the stage quality seems to have worked for Samsung, it has not shown up in their latest certification report of my app.
by the way, this is not for a stage3D app, that's different
It's for a GPU app
When the app loses focus on Android (goes into background) it will lose the context, which among other things mean that you lose all the created graphics, cached objects and like.
You didn't specify what kind of app it is. If you're using Stage3D, that means you'll have to recreate all your textures, and if you're on plain old displaylist, you'll have to recreate any bitmaps that were created at runtime, and redraw your screen at least once (so the vector graphics get redrawn too).
Now, if you're using Starling, for example, it can take care of recreating context for you (there's a flag for enabling that), although you'll still have to recreate dynamically created bitmaps.
Here's what I need to do. I want to use an Android tablet for science research, but I will need to programmatically control the screen/backlight. Specifically, there is a mode where my app will need to communicate with other systems via WiFi, play sounds, and have the touchscreen active, but the backlight must be completely off; in this mode, the device cannot emit any light, or it will interfere with the science. Obviously, this cannot be sleep mode! Is this feasible?
I've looked around a bit, and this sounds really promising, but it isn't crystal-clear (to me, anyway!) whether this will work. Can anyone vouch for that?
Finally, does it matter which tablet I choose? Basically, there seem to be three possibilities: the backlight is controlled with a switch (doubt that is done anymore), the CPU can only turn it on or off, or the CPU can adjust it fully. Writing this makes me feel rather silly about being concerned, but a Samsung rep yesterday told me I can't do this on the Galaxy. Anyone care to recommend a tablet?
Thanks!
Specifically, there is a mode where my app will need to communicate with other systems via WiFi, play sounds, and have the touchscreen active, but the backlight must be completely off
Android does not support "have the touchscreen active, but the backlight must be completely off". And, you do not have the ability to turn the backlight "completely off" programmatically.
I've looked around a bit, and this sounds really promising
That sets the backlight to be low. Some devices may elect to turn the backlight off when it is set low. That is up to the device manufacturer.
Finally, does it matter which tablet I choose?
See above.
Since its a science research I'm going to assume you may not need to divulge this application and want it in a controlled environment. If this is the case, a little creative thinking suggests that since the touch screen will still react to even if covered by a thin layer of plastic (like the screen protectors for instance) you may be able to apply some opaque vinyl on top of the screen (easy to remove) for doing the experiments.
This may not be useful but since to me it sounded like it could I thought I'd share my thoughts with you on this one. Once you've covered the screen with the vinyl, the rest is as usual, keep screen on, and do your magic.
:)
I customize the android system, the resolution is 1024x768 The target device must be in the landscape mode, it's fixed. And some apps are only have the portrait mode, can not be used.
So I want to change something that let the portrait app display in the center and the resolution is 640x480 How can I do it? I can do anything, including change the android or linux kernel code.
How can I do it?
For apps that you write yourself, you modify the apps to run successfully in landscape mode.
For apps that your firm intends to license from other developers, have them make a landscape-compatible version of the app as a precondition of your license.
If you intend to allow third-party apps to be installed on this device by the end user, modify the installation process to detect the fact that one or more activities are flagged as running landscape-only and present a warning to the user at install time, so they know that the app they are trying to install will not run well on your device.
Modifying Android in the manner you describe may be possible, but it is the sort of thing that will require lots of time and effort and is well outside the scope of a StackOverflow question.