how to tell physical size of screen / how many columns could be put in layout?

Solar2D General Questions/Discussion
#1

Question: What is the best way to determine whether extra columns could be placed in a layout for a given view?

With the mix of IOS/Android devices, different resolutions, portrait/landscape, does the answer lie in the physical dimensions of the screen (as opposed to number of pixel)?  What Corona API’s or approach could be used to dynamically determine?

For example, for the sake of discussion, if you had an application that you data to be displayed in columns and you had say determined that for readability for a user that (I’m making these up):

* iPhone Portrait - 1 column

* iPhone Landscape - 2 columns

* iPad Portrait - 2 columns

* iPad Landscape - 3 columns

However beyond iPad/iPhone there are all the Android devices, so assuming here one needs a formula/approach to determining at run time how many columns to try to display to the user.  

Not sure if this is significant for the question but re config.lua I have been typically using the approach here: http://coronalabs.com/blog/2013/09/10/modernizing-the-config-lua/ 

#2

For Android we do have values that would give you the pixels per inch for the device using system.getInfo(“androidDisplayHeightInInches”)

There is one for Width too.  Then you could use that to determine if you’re on a tablet or phone.  For iOS you would need to look at the device string and try to determine if you’re on a iPhone or iPad (and look for the specific code for Mini’s if that matters) and then you could change your layout accordingly.

#3

thanks Rob - so for Android I assume you suggesting to dynamically do some thing this:

 local physicalWidthInches = display.contentWidth / system.getInfo(“androidDisplayWidthInInches”)

 local physicalHeightInches = display.contentHeight / system.getInfo(“androidDisplayHeightInInches”)

Then come up with a threshold value for width after which you’d assume it’s big enough to display 2 columns to the user for example?

Also can this approach be used/tested on the simulator itself?  i.e. if you change between simulator types (e.g. view as GalaxyS3 etc)

thanks

#4

Not exactly.   The display.contentWidth will be whatever your content area is defined as in config.lua.   system.getInfo(“androidDisplayWidthInInches”) will give you the physical device inches (for Android).  I have no idea what the simulator returns. 

To do what I think you are wanting to do your config.lua needs to changed based on the device.  You would want to determine if you’re a tablet or phone and then double your content area on tablets, giving you more points to work with on the larger devices. 

#5

Hi Rob - not exactly sure what you meant by using config.lua…I would be just happy to have a variable that indicates whether I should consider the device large enough for 2 columns (versus 1) to be displayed and then handle the rest programmatically myself.

Question - Is there any way with Android (or in general) to get the actual number of pixels wide the screen really is?   (i.e. with the result not be tainted by scale or config.lua settings so to speak)

EDIT: Actually the answer is this correct “display.pixelHeight”.    But I also noted your blog post here http://coronalabs.com/blog/2013/04/30/new-system-info-properties/ .  So the answer for Android is in fact:

 

local widthInches = system.getInfo( “androidDisplayWidthInInches” )

local heightInches = system.getInfo( “androidDisplayHeightInInches” )

Rob, based on this one could just use the physically “widthInches” (for Android) to determine whether or not the user is on a larger device, and as such whether you could fit in an extra column.  After which you could just handle this programmatically re the extra column.  Just wondering if I’m missing something here?  (noting your reference to config.lua)

#6

That is basically what I was saying.  Lets say you’re using the 800 x 1200 variant of the modernized config.lua.  Regardless if you’re on an iPhone 5, which is roughly speaking a 2" x 4" screen or a Kindle Fire HD 8.9" that has more of a 6" x 9" screen, the content area will be 800 x 1280 where as the iPhone 5 will be 800 x 1420 but they are basically the same area.  Yet the Kindle big tablet is much larger.

To accomplish more columns on the physically larger device, you have one of two choices:  1. Adjust the config.lua so that the content area changes to give you a larger content area on the larger devices or 2. adjust your column widths, font sizes, image sizes to make smaller areas.

So in the 800x1200 world and lets focus on landscape for the moment.  You want one column on the phone and two on the tablet.  If both devices have an 800 point wide content area, then on the phone you have to have 1 - 800 point wide column and on the tablet you have 2 - 400 point columns.  You have to do all the math yourself to adjust everything.   Or you change the config.lua to give you 400 point wide screen on the phone and an 800 point side screen on a tablet.  Then in your app you make all columns 400 points wide and have all your assets scaled to work at 400 points.

Does that make sense?  Though any time your app is dealing with different sized content areas, regardless of the method, it increases the complexity of your app because you eventually have to say “Am I a small or large screen” and deal with it.

Rob

#7

thanks Rob - makes sense.  In fact my table (matrix) view I have I’ve been setting column with percentages, so if I stick to this approach I think I should be ok not using config.lua at all.  I’m kind of thinking it may be easier (re code readability) perhaps too than trying to adjust config.lua, but like you say either way the code does get more complex  :)  

actually on a separate but related item (as I work through trying to get dynamic columns and orientation change supported) if you have a moment to comment on orientation change support for the scrollView here that would be appreciated:  http://forums.coronalabs.com/topic/44938-newscrollview-does-it-support-resizing-for-orientation-changes-within-storyboardcomposer/

#8

I don’t believe our scrollView supports orientation change.  I can see where being able to change the height/width  is an important feature and if there isn’t a bug report for that, I would recommend filing it.  The other option is to take the open source version of the widgets (it’s just Lua code) and write your own.

The other option is to destory and re-create  the scrollView when you detect the orientation change.   Or maybe easier have two scrollViews, one hidden, one visible, and on orientation, you move your display objects from one to the other and flip which one is visible. 

#9

For Android we do have values that would give you the pixels per inch for the device using system.getInfo(“androidDisplayHeightInInches”)

There is one for Width too.  Then you could use that to determine if you’re on a tablet or phone.  For iOS you would need to look at the device string and try to determine if you’re on a iPhone or iPad (and look for the specific code for Mini’s if that matters) and then you could change your layout accordingly.

#10

thanks Rob - so for Android I assume you suggesting to dynamically do some thing this:

 local physicalWidthInches = display.contentWidth / system.getInfo(“androidDisplayWidthInInches”)

 local physicalHeightInches = display.contentHeight / system.getInfo(“androidDisplayHeightInInches”)

Then come up with a threshold value for width after which you’d assume it’s big enough to display 2 columns to the user for example?

Also can this approach be used/tested on the simulator itself?  i.e. if you change between simulator types (e.g. view as GalaxyS3 etc)

thanks

#11

Not exactly.   The display.contentWidth will be whatever your content area is defined as in config.lua.   system.getInfo(“androidDisplayWidthInInches”) will give you the physical device inches (for Android).  I have no idea what the simulator returns. 

To do what I think you are wanting to do your config.lua needs to changed based on the device.  You would want to determine if you’re a tablet or phone and then double your content area on tablets, giving you more points to work with on the larger devices. 

#12

Hi Rob - not exactly sure what you meant by using config.lua…I would be just happy to have a variable that indicates whether I should consider the device large enough for 2 columns (versus 1) to be displayed and then handle the rest programmatically myself.

Question - Is there any way with Android (or in general) to get the actual number of pixels wide the screen really is?   (i.e. with the result not be tainted by scale or config.lua settings so to speak)

EDIT: Actually the answer is this correct “display.pixelHeight”.    But I also noted your blog post here http://coronalabs.com/blog/2013/04/30/new-system-info-properties/ .  So the answer for Android is in fact:

 

local widthInches = system.getInfo( “androidDisplayWidthInInches” )

local heightInches = system.getInfo( “androidDisplayHeightInInches” )

Rob, based on this one could just use the physically “widthInches” (for Android) to determine whether or not the user is on a larger device, and as such whether you could fit in an extra column.  After which you could just handle this programmatically re the extra column.  Just wondering if I’m missing something here?  (noting your reference to config.lua)

#13

That is basically what I was saying.  Lets say you’re using the 800 x 1200 variant of the modernized config.lua.  Regardless if you’re on an iPhone 5, which is roughly speaking a 2" x 4" screen or a Kindle Fire HD 8.9" that has more of a 6" x 9" screen, the content area will be 800 x 1280 where as the iPhone 5 will be 800 x 1420 but they are basically the same area.  Yet the Kindle big tablet is much larger.

To accomplish more columns on the physically larger device, you have one of two choices:  1. Adjust the config.lua so that the content area changes to give you a larger content area on the larger devices or 2. adjust your column widths, font sizes, image sizes to make smaller areas.

So in the 800x1200 world and lets focus on landscape for the moment.  You want one column on the phone and two on the tablet.  If both devices have an 800 point wide content area, then on the phone you have to have 1 - 800 point wide column and on the tablet you have 2 - 400 point columns.  You have to do all the math yourself to adjust everything.   Or you change the config.lua to give you 400 point wide screen on the phone and an 800 point side screen on a tablet.  Then in your app you make all columns 400 points wide and have all your assets scaled to work at 400 points.

Does that make sense?  Though any time your app is dealing with different sized content areas, regardless of the method, it increases the complexity of your app because you eventually have to say “Am I a small or large screen” and deal with it.

Rob

#14

thanks Rob - makes sense.  In fact my table (matrix) view I have I’ve been setting column with percentages, so if I stick to this approach I think I should be ok not using config.lua at all.  I’m kind of thinking it may be easier (re code readability) perhaps too than trying to adjust config.lua, but like you say either way the code does get more complex  :)  

actually on a separate but related item (as I work through trying to get dynamic columns and orientation change supported) if you have a moment to comment on orientation change support for the scrollView here that would be appreciated:  http://forums.coronalabs.com/topic/44938-newscrollview-does-it-support-resizing-for-orientation-changes-within-storyboardcomposer/

#15

I don’t believe our scrollView supports orientation change.  I can see where being able to change the height/width  is an important feature and if there isn’t a bug report for that, I would recommend filing it.  The other option is to take the open source version of the widgets (it’s just Lua code) and write your own.

The other option is to destory and re-create  the scrollView when you detect the orientation change.   Or maybe easier have two scrollViews, one hidden, one visible, and on orientation, you move your display objects from one to the other and flip which one is visible.