Differentiating between a small or a large screen (with similar screen resolution)

Solar2D Android
#21

That’s a bummer :frowning: I will do it but I think it’s a really small effort on Ansca’s side to allow us to have this flexibility in the build dialog and build.settings… Seems wrong to me that I have to backward engineer my own games in this fashion in order to support all devices. That’s exactly the main reason we chose Corona so we won’t have do deal with this kind of stuff…
furthermore I don’t suppose Ansca would recommend or support this but correct me if I’m wrong…

Joshua, is this anywhere on the roadmap? What is the reasoning behind fixing the min sdk version to 8 and not supporting the target sdk version?

I am assuming iOS is more of a priority for ansca and most of the users but I personally believe the android markets will pass it with time and for us it represents 90% of the revenues (android and amazon).

CluelessIdeas, what do you mean by:
“look good in Android tablets”? Does it look any different then in stretched mode? [import]uid: 80469 topic_id: 19817 reply_id: 83976[/import]

#22

@gury.traub It shouldn’t look any different, but it will have the useless menu and compatibility zoom buttons which will make your app look like it isn’t designed for tablets. And on top of that it will appear on Android Market as an app that doesn’t natively support 7"+ screens. [import]uid: 61899 topic_id: 19817 reply_id: 83990[/import]

#23

Targeting the newest version of Android is on our to-do list. It isn’t as trivial as changing the AndroidManifest.xml because it involves updating our Android SDK, build servers, build scripts, and re-testing everything with our 4.0 builds… but we definitely plan on doing it. At which point, we would change the Corona build window to allow you to select a minimum Android version instead of a target version, because we would always be targeting the highest Android version.

And yes, a 2.2 built app will work on an xlarge Android device. The issue we were having on this forum thread is that the app was built for 2.2 and it freaked out over a 2.3 setting that it did not know what to do with. [import]uid: 32256 topic_id: 19817 reply_id: 84050[/import]

#24

Hi Joshua,

I’ve been thinking more about the proposed creation of something like display.xDpi as a solution to the original problem. For this to work, we would also need to be able to find out the native display resolution within the config.lua file. At the moment, trying to access display.contentWidth or display.contentScaleX within config.lua results in the app terminating.

I was wondering what additional info you were planning to make available in config.lua? Also, would you know when this functionality might be available? I’ve been checking the daily builds log but there have been several builds with no comments to them.

Thanks,
Eric [import]uid: 29384 topic_id: 19817 reply_id: 87385[/import]

#25

Accessing the display API from the config.lua crashes because the rendering system hasn’t been initialized yet. The only APIs you have access to are the “system” APIs. So, I’ll probably have to set it up like this…

[lua] local xDpi = system.getInfo(“xDpi”)
local yDpi = system.getInfo(“yDpi”)[/lua]

I may have to do something similar for screen width and height, since as you say, the display API is not available in the config.lua. Perhaps, I can make it even nicer and provide a “screenWidthInInches”. That would make it even easier. :slight_smile: [import]uid: 32256 topic_id: 19817 reply_id: 87390[/import]

#26

Hi Joshua,

Yes, that all sounds good. I’m very keen to try it out, as my app is basically finished now and I’d really like to upload it to the Android market. Please make a post to this thread when it makes it into a daily build!! [import]uid: 29384 topic_id: 19817 reply_id: 88199[/import]

#27

Just to let you know, I don’t see us making this change in the next few weeks. We have other commitments that we have to address first. Namely in-app purchases on Android and general improvements on Kindle Fire and Nook. So, I don’t want this to prevent you from releasing your app unless it’s absolutely necessary. [import]uid: 32256 topic_id: 19817 reply_id: 88204[/import]

#28

You might be interested in this list of android device names and screen sizes I just created:

http://developer.anscamobile.com/code/android-screen-sizes-and-names-list

Contributions are very welcome! [import]uid: 61899 topic_id: 19817 reply_id: 88352[/import]

#29

@Joshua, well I’m of course disappointed to hear that but I do really appreciate you providing an honest view of the situation.

@CluelessIdeas, thanks for contributing this list! The problem will be not only keeping it up to date, but also having to update the apps that use this to keep them up to date… But at least it provides a potential solution in the meantime. [import]uid: 29384 topic_id: 19817 reply_id: 88502[/import]

#30

@HabitatSoftware

Jeff, isn’t it easier to do

  
resolution = { width = display.contentWidth/display.contentScaleX, height = display.contentHeight/display.contentScaley }

?

Looks cleaner then screenshots :wink:
EDIT:
nope… this only gives you resolution of the device, and not the real content height and width on screen. damn :confused:

EDIT2:
I’ve tried the screenshot hack, but it gives me screen resolution anyway :confused:
For now, the only way I see it work is to manually calculate how the letterbox works. [import]uid: 109453 topic_id: 19817 reply_id: 94500[/import]

#31

@Joshua,

Can we us conditionals in the build.settings file so we can handle specific build settings based on some criteria?

For instance, I’d like to do the following:

[lua]local largeOnly = false
if ( system.getInfo(“model”) == “Kindle Fire” ) then
largeOnly = true
end

settings =
{
android =
{
supportsScreens =
{
smallScreens = not largeOnly,
normalScreens = not largeOnly,
largeScreens = largeOnly,
xlargeScreens = largeOnly,
},
},
}[/lua]

Otherwise we have to manually copy different build.settings files, then build for that flavor.

[edit] I did a quick test. Unfortunately the system.getInfo() functions don’t return anything in the build settings, so you cannot programatically do this.

I’ve put in a request before to have a “BUILD” type variable that is available as early as possible; like in the build settings. Even if it isn’t possible to have this set that early, it would still simplify all of the store front code that I have in main.lua. In order to point the user to the correct store link I have to manually edit main, make a build, then edit again for the next build flavor, etc.

If there was a getInfo(“build”) function I could do it all programatically and never accidently forget to change a value before making a build. [import]uid: 16734 topic_id: 19817 reply_id: 101986[/import]

#32

Ken,

The “build.settings” file is only used during the Corona build process to tell it how to configure the outputted app. That file is not included within the built app itself. So all of the Corona functions are not available within that file.

Unfortunately, there is no way to have an app target only the Kindle Fire on the Amazon store. That’s not a Corona limitation. Amazon would have to support such as thing.

I think the best solution in the end would be for Corona to supply APIs that allow you to retrieve the DPI or the screen size in inches, like said in earlier in this thread. [import]uid: 32256 topic_id: 19817 reply_id: 102157[/import]

#33

@Joshua,

I shouldn’t have said “Kindle Fire”. I should have just said “Amazon”.

What I was saying is knowing what we are BUILDING for would be extremely helpful, even if it is not available in the build.settings.

For instance I currently have this in main.lua:

[lua]AMAZON_MARKET = “Amazon”
ANDROID_MARKET = “Android”
APPLE_MARKET = “Apple”
BN_MARKET = “BN”

– local sMarket = AMAZON_MARKET
– local sMarket = ANDROID_MARKET
local sMarket = APPLE_MARKET
– local zMarket = BN_MARKET

if ( sMarket == AMAZON_MARKET ) then
sStoreLink = “http://www.amazon.com/mystorelink1”
elseif ( sMarket == ANDROID_MARKET ) then
sStoreLink = “http://www.google.com/mystorelink2”
elseif ( sMarket == APPLE_MARKET ) then
sStoreLink = “http://www.itunes.com/mystorelink3”
elseif ( sMarket == BN_MARKET ) then
sStoreLink = “http://www.barnesandnoble.com/mystorelink4”
end[/lua]

I would love it if we could use a system info value to do this instead:

[lua]AMAZON_MARKET = “Amazon”
ANDROID_MARKET = “Android”
APPLE_MARKET = “Apple”
BN_MARKET = “BN”

local sMarket = system.getInfo( “build_type” ) – Wish this existed

if ( sMarket == AMAZON_MARKET ) then
sStoreLink = “http://www.amazon.com/mystorelink1”
elseif ( sMarket == ANDROID_MARKET ) then
sStoreLink = “http://www.google.com/mystorelink2”
elseif ( sMarket == APPLE_MARKET ) then
sStoreLink = “http://www.itunes.com/mystorelink3”
elseif ( sMarket == BN_MARKET ) then
sStoreLink = “http://www.barnesandnoble.com/mystorelink4”
end[/lua]

The difference is I don’t have to do ANYTHING other than make a build to get the correct build type. There’s never ANY chance I would submit a build with the wrong link. Sure, this is just a way to help the developer reduce their chance for mistakes, but that is a good goal for any engine. [import]uid: 16734 topic_id: 19817 reply_id: 102163[/import]

#34

On our end, we’ve been talking about creating an API for fetching which store or app installed the Corona app. We thought this would come in handy on Android for identifying which store the Android app came from. Especially when selecting which in-app purchase system to select. We only support Google’s in-app purchase solution, but Amazon’s will be next… and we’ll likely have to add support for others as well. Regarding in-app purchase, we’ll try to make it select the correct store automatically when the time comes, but there will be case where there is no way Corona will know. I don’t want to talk about this one now (it gets complicated), but this is just an example.

We also have a feature request written up for providing an API to rate your app via the marketplace your app was brought from. Your URL solution will work for the Google and Amazon app stores, but not with Barnes&Noble. Just another thing we need to do. [import]uid: 32256 topic_id: 19817 reply_id: 102188[/import]

#35

Just used build number 797 which has support for Android 4.0. Setting the xLargeScreens option in the build.settings still results in an invalid build that does not work and can’t even be installed on devices. Omitting this option the app works and installs fine and I can see that it’s no longer in compatibility mode, however it would still not appear as a tablet app on Google Play due to the missing xLargeScreens support. [import]uid: 61899 topic_id: 19817 reply_id: 104397[/import]

#36

I’m not sure why the “xlargeScreens” option still won’t work. It’s supposed to be supported since API level 9 (Android 2.3). Perhaps it fails because we set the minSdkVersion to API level 8. I’m not really sure. I’ll have to write this up to be investigated later. [import]uid: 32256 topic_id: 19817 reply_id: 104500[/import]

#37

Oh wait…

You said the “xLargeScreens” option failed on you… with a capital ‘L’. Was that a typo? Because this setting is case sensitive and needs to be spelt like this “xlargeScreens”. [import]uid: 32256 topic_id: 19817 reply_id: 104501[/import]

#38

It was a typo. Tried with both xlargeScreens and xLargeScreens and the resulting apk can’t be installed. I’ll take a look at the AndroidManifest.xml and report back. [import]uid: 61899 topic_id: 19817 reply_id: 104637[/import]

#39

Everyone,

We fixed “xlargeScreens” support as of build 817. It turned out that our build server cluster did not get updated to use the newest Android SDK, which is required to use the newer AndroiManifest.xml feature settings. Sorry about the inconvenience and thanks for bringing this issue to our attention.

Please go ahead and re-add the “xlargeScreens” setting as I’ve mentioned in the following link…
http://developer.anscamobile.com/forum/2012/01/01/differentiating-between-small-or-large-screen-similar-screen-resolution#comment-77139
[import]uid: 32256 topic_id: 19817 reply_id: 109404[/import]