Question about Enterprise

Solar2D Native builds
#1

Hello,

I am using the free version right now and looking into upgrading to enterprise soon because I need to use some customized controls with it. While I was messaging someone about writing a special plugin for me he said that part of the code would run in the background. I know corona labs does not run in  the background so how can this be? Are you able to write some native code with it that runs in the background? For example, say I wanted to write a gps tracking app and it needed to run in the background for this. Can I code all of the interface screens but also have part of it running in the background? Just trying to understand what he was saying about that.

Thanks,’

Warren

#2

Any Lua code you would write (display.newText(), event listeners, etc.) expects the UI thread to be in the foreground. Background operations can be done in native as long as the native side handles everything. If it tries to send messages to the Lua side, it’s not been tested nor is it supported.

Rob

#3

Thanks Rob! So what you are saying is I can write one part of the app which will be for the interface and all of that code will work only in the foreground which I would expect. Then I can write some other LUA code that will run in the background as long as it does not try to interact with the other code for the interface.

If this is right then I understand. One question through. When my apps run they always start from one scene and then it calls another. How would I have the app start with the one in the background and then still open the interface scene when I need it? Is the code that runs in the background just set to run that way automatically?

And if it is for the gps tracking then I can write code to use a location handler to get the gps location and post it to the server and run this part separate in the background?

Thanks!

#4

Not exactly. The backgrounded code would need to be native (Objective C/Swift for iOS or Java for Android). You can’t have any Lua interactions that’s part of Corona.

All scenes would be done in Lua and only be available in the foreground. You should be able to setup a location handler outside of your Lua code (in native code and have it transmit to a server), if that’s something that iOS and Android allow.  I don’t know what networking facilities you have while backgrounded. You may only be able to save data points locally and then communicate with a server afterwards.

Rob

#5

Any Lua code you would write (display.newText(), event listeners, etc.) expects the UI thread to be in the foreground. Background operations can be done in native as long as the native side handles everything. If it tries to send messages to the Lua side, it’s not been tested nor is it supported.

Rob

#6

Thanks Rob! So what you are saying is I can write one part of the app which will be for the interface and all of that code will work only in the foreground which I would expect. Then I can write some other LUA code that will run in the background as long as it does not try to interact with the other code for the interface.

If this is right then I understand. One question through. When my apps run they always start from one scene and then it calls another. How would I have the app start with the one in the background and then still open the interface scene when I need it? Is the code that runs in the background just set to run that way automatically?

And if it is for the gps tracking then I can write code to use a location handler to get the gps location and post it to the server and run this part separate in the background?

Thanks!

#7

Not exactly. The backgrounded code would need to be native (Objective C/Swift for iOS or Java for Android). You can’t have any Lua interactions that’s part of Corona.

All scenes would be done in Lua and only be available in the foreground. You should be able to setup a location handler outside of your Lua code (in native code and have it transmit to a server), if that’s something that iOS and Android allow.  I don’t know what networking facilities you have while backgrounded. You may only be able to save data points locally and then communicate with a server afterwards.

Rob