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.
Related
How to make sure that my App's popup or text appears exactly how I intended it to appear in all screen sizes? I want the aspect ratio of the popup to appear same and all the text that appears at the time of designing the popup to be same in all the devices.
Imagine an image who's size and content will be same across devices. But for some reason I can not use image here, the requirement is to use popup with text and butto. I dont want any screen to cut the popup or make the text of the popup disappear or turn to crap.
I can not do testing with one device at a time as I read on a site that there are over 10,000 android devices :|
Is there anyway or any tool part of Android Studio which can like quickly draw outlines of all the phones screen sizes to help me understand what aspect ratio is right for my popup?
Im a noob so my question may not make sense to you so please bear with me.
Unfortunately it's going to be nearly impossible to get things to appear 100% the same across all devices and browsers – Android runs on all sorts of devices and there are probably hundreds or thousands of different possible screen sizes, in addition to browser and operating system quirks. Start with identifying specific devices and screen sizes you wish to support. See Android's screen compatibility overview for some good information on this topic.
If possible look at user analytics to narrow down the most common devices, operating system versions, and browsers, then test against those.
I am working on a widget. On the typical phone, I would prefer it to be 4x2, filling the width of the home screen. However, on some larger phones (i.e. Samsung Galaxy Mega), the launcher has 5 cells' width. I am trying to find the best way to automatically change my widget provider to be a 5x3, based on the launcher cell dimensions.
Currently, we have two providers: a 4x2 and a 5x3. Since we only want to show one (4x2) on normal-size phones (they don't support 5x3), we do a runtime check when the widget is added to check if the device model matches one of the models with a 5-cell wide launcher. We then disable the other widget provider component. However, this isn't ideal, as the 5x3 will show up temporarily in the app drawer and cause the launcher to force close if the user tries to add it.
Any thoughts on how to work around this? I realize I most likely won't be able to read exactly the cell-width size, as there are tons of launchers, and there isn't an API to check. However, I think we would all agree that there must be something better than keeping a static list of devices that have a 5-cell screen (not to mention people with custom launchers can set a range of widths).
I have thought briefly on using the resource folder qualifiers (sw720dp, etc.) ...but that still doesn't solve the issue of determining what the user's launcher's width in cells is.
Thanks for the help,
Drew
P.S. I also realize that a similar question was asked here: Appwidget Maximum Width that fits all screen sizes with no comments or answers. Any input would be much appreciated.
Any thoughts on how to work around this?
Allow your app widget to be resizeable, so users who want it to fill the home screen width can elect to do so.
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.
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 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.