Running background LUA code

Can I run background LUA code using Corona Enterprise? I know that the Corona view is not loaded when in background, but I am curious if I can use LUA to perform some functions that don’t require the view…

I’m not 100% that I understand what you’re asking but if the question is “can I execute Lua code from my own code outside the context of the CoronaView?” then the answer is a qualified “yes”.  

You could just call the Lua C API as described here.  However you wouldn’t have any access to Corona APIs or system values so it would be of limited use.  The CoronaView owns the active Lua instance that contains all the context of the app and that’s the only way to access it.

Sorry, I will try to be more specific: Let’s say I want to create a function that do a network request and store the response in the file.  So that function is using network API and IO  (not using anything related to displaying something to the user).

My doubt is: are these API (network, IO,…) under the Corona instance and therefore they are not available when in background mode?

UPDATE: I understand from your replay is that: "yes, you can. Just do the normal lua bridge. I know that. I am more interesting in knowing if I can simply create a function inside my corona app and make it exposed to the native code when the app is in background mode).

I’m 99% certain the answer is “no” but which device OS are we talking about and what specifically do you mean by “background mode”?

OS would be iOS and Android.

Background mode would be the app is doing stuff even when the app is suspended, like a GPS tracking app (such as Strava).

Because I understand that the Corona View is not there, since it is a OpenGL view and OpenGL are not active when the app is not open. But I theoretically, the Corona APIs (network, …) that are not graphic related could be accessible.

CoronaSDK was not designed to run when the app is suspended so nothing is guaranteed to work. OpenGL and the Corona Lua runtime are shutdown when suspended so things like event listeners may not function. It’s also platform dependent so if you find something that works in iOS, it may not work in Android.

Thanks for the reply Tom.

I’m not 100% that I understand what you’re asking but if the question is “can I execute Lua code from my own code outside the context of the CoronaView?” then the answer is a qualified “yes”.  

You could just call the Lua C API as described here.  However you wouldn’t have any access to Corona APIs or system values so it would be of limited use.  The CoronaView owns the active Lua instance that contains all the context of the app and that’s the only way to access it.

Sorry, I will try to be more specific: Let’s say I want to create a function that do a network request and store the response in the file.  So that function is using network API and IO  (not using anything related to displaying something to the user).

My doubt is: are these API (network, IO,…) under the Corona instance and therefore they are not available when in background mode?

UPDATE: I understand from your replay is that: "yes, you can. Just do the normal lua bridge. I know that. I am more interesting in knowing if I can simply create a function inside my corona app and make it exposed to the native code when the app is in background mode).

I’m 99% certain the answer is “no” but which device OS are we talking about and what specifically do you mean by “background mode”?

OS would be iOS and Android.

Background mode would be the app is doing stuff even when the app is suspended, like a GPS tracking app (such as Strava).

Because I understand that the Corona View is not there, since it is a OpenGL view and OpenGL are not active when the app is not open. But I theoretically, the Corona APIs (network, …) that are not graphic related could be accessible.

CoronaSDK was not designed to run when the app is suspended so nothing is guaranteed to work. OpenGL and the Corona Lua runtime are shutdown when suspended so things like event listeners may not function. It’s also platform dependent so if you find something that works in iOS, it may not work in Android.

Thanks for the reply Tom.