Wednesday FAQs: Miscellaneous Questions

24 April 2013

Wednesday FAQs: Miscellaneous Questions

tom
FAQ

FAQ Icon It’s Wednesday and time for another FAQ session. Here are some frequently asked questions (FAQ).

1. Why doesn’t native.setActivityIndicator work in my code?

native.setActivityIndicator cannot be set and cleared in the same code chunk. All display objects (including native objects) are not rendered on the screen until the code chunk ends.

The following is the wrong way to set the Activity Indicator. The activity indicator is not set until AFTER the function ends, and then it’s cleared. (Note: There is a current bug in Android where the activity indicator does not turn off in this example.)

native.setActivityIndicator( true )
for i = 1, 1000 do
    print( "i = " .. i )
end
native.setActivityIndicator( false )

native.setActivityIndicator( true )

for i = 1, 1000 do

print( "i = " .. i )

end

native.setActivityIndicator( false )

This is the right way to set the Activity Indicator. The indicator is cleared after one second. The problem with this approach is the activity indicator is set after the for loop executes so it’s not displaying the activity indicator during the time the for loop is running.

native.setActivityIndicator( true )
for i = 1, 1000 do
    print( "i = " .. i )
end

-- Turn off the indicator after one second
timer.performWithDelay( 1000, function() native.setActivityIndicator( false ) end )

native.setActivityIndicator( true )

for i = 1, 1000 do

print( "i = " .. i )

end

-- Turn off the indicator after one second

timer.performWithDelay( 1000, function() native.setActivityIndicator( false ) end )

The solution to the above problem would be running the for loop code in a timer function. You start the activity indicator before the timer starts and turn off the activity indicator in the timer function.

native.setActivityIndicator( true )
timer.performWithDelay( 100,
    function()
        for i = 1, 1000 do
            print( "i = " .. i )
        end
        native.setActivityIndicator( false )
    end
)

native.setActivityIndicator( true )

timer.performWithDelay( 100,

function()

for i = 1, 1000 do

print( "i = " .. i )

end

native.setActivityIndicator( false )

end

)

2. I’m using Dynamic Scaling and don’t see native textField and textBox font sizes changing when I test on different devices.

When you specify the target screen size in config.lua, this allows display objects to scale depending on the native screen size of the device. The one exception is fonts used in native text fields. The fonts don’t automatically scale so the font size needs to be adjusted manually. You can determine the correct size by either reading the device type (using system.getInfo( “model” )) or reading the scaling factor of the device (display.contentScaleX and display.contentScaleY). For Android, we recently added some new system.getInfo API calls in our Daily builds that may help: “androidDisplayWidthInInches”, “androidDisplayHeightInInches”, “androidDisplayXDpi”, and “androidDisplayYDpi”.

3. My network.request calls are no longer working starting with build 1076. What happen?

Starting with build 1053 we added a default Content-Type field of “text/plain” for all platforms. This was done to be consistent among the platforms. Before build 1053 we relied on the OS to provide the Content-Type field if it was missing from the network.request. If your network.request contains a parms.bodyType equal to “binary”, or your parms.body contains a table (specifying filename), Content-Type will be set to ” application/octet-stream”. If your network.request specifies a value for Content-Type, it will override the default value. In all other cases it will be set to “text/plain”.

-- Example code to log in with username/password

local function networkListener( event )
    print( "networkListener called", event.response )
end

local user = "myName"
local password = "abc"

local headers = {}
headers["Content-Type"] = "application/x-www-form-urlencoded"

local body = "login="..user.."&password="..password
local params = {}
params.headers = headers
params.body = body
-- go to http://requestb.in/ to set up an test page
network.request("http://requestb.in/", "POST", networkListener, params )

-- Example code to log in with username/password

local function networkListener( event )

print( "networkListener called", event.response )

end

local user = "myName"

local password = "abc"

local headers = {}

headers["Content-Type"] = "application/x-www-form-urlencoded"

local body = "login="..user.."&password="..password

local params = {}

params.headers = headers

params.body = body

-- go to http://requestb.in/ to set up an test page

network.request("http://requestb.in/", "POST", networkListener, params )

4. Display.save now shows a white background in the saved image. The background use to be black.

We had a blending issue with display.save captures and it was fixed by making the background full alpha behind the objects being saved. This changed occurred in build 1079. If you are saving a group, the background will be transparent, which is undefined. Before 1079 we made the background black, which was causing problems for some users. Now the transparent areas may show up as either black or white when saving to a .JPEG file. If you save it to a .PNG file (which display.save now supports), the background will be transparent and take on the existing background when displayed.

Specifying a .PNG file in display.save is one solution to the problem when saving a group. The other is creating a black display.newRect the size of your group and filling it with black and inserting it behind all your other group objects. You do this before calling display.save and remove the newRect object afterwards.

5. I’m using the released version of Corona SDK and seeing bugs in Widgets. What can I do?

The good news is we decided to open-source our Widgets 2.0 library. We have put the library up on GitHub that you can include in your own project. This is the same code we include in our Daily Builds and our plan is to keep both in sync. This means Starters, who don’t have access to our Daily Builds, can still use the latest Widget library. If you do find a Widget bug, please submit a bug report and a small test project demonstrating the bug. In the report please mention the Corona build you’re using and which version of the Widget library you’re reporting. Get more information here

That’s it for today’s questions. I hope you enjoyed them and even learned a few things.

Tags:

corona, CoronaSDK, FAQ, network, Widgets

tom

2 Comments

J. A. Whye
Posted at 17:50h, 25 April

About #2, you say:

“…the font size needs to be adjusted manually. You can determine the correct size by … reading the scaling factor of the device (display.contentScaleX and display.contentScaleY).”

How does that determine the correct size? There’s more to it, I think.

From the forums I grabbed this:

local fontSize = 14 / display.contentScaleY

…but that didn’t work. It gave me big fonts on the iPhone 4S and huge fonts on the iPad Retina. Through trial and error I added this:

if fontSize > 14 then fontSize = fontSize * .66 end

…and that mostly fixed things. Font sizes aren’t exactly the same from device to device, but they’re close. Haven’t tested on Android devices yet, but I sure wish there was a *for sure* way to handle this.

Anyone?

Jay
Ragdog Studios
Posted at 12:51h, 28 April

Guess the best way would be to calculate a specific size depending on the the device model and contentScale on iOS, and the new parameters on android.

if it’s an iPad, and the contentScale fits the retina one, you give a specific size. If it’s a normal iPad, you give another. If it falls in the iPhone’s realm, you give one for iphone3gs and lower and one for iphone4 and higher (always checking the scale).

Ideally you could just set a multiplier depending on the above, and write all the fonts sizes with iPhone 3GS in mind, and then multiply them by the correct value.

Wednesday FAQs: Miscellaneous Questions