Run As Process / Service for Mobile

[SteveTX]

I would like a native way to run my application as a process or service for android / iOS. Currently even a simple app like an alarm clock cannot be functionally executed in livecode because the application gets suspended when closed (and the only method to reopen is by user activity ie notification or app start). This means apps that you can't have your app live or do anything in the background either, like check for updates, scan files, look for states, etc. This is really essential functionality.

[William Jamieson]

Much agreed. This is very critical functionality that should be taken into account to make Livecode functional. The only thing I know that Livecode will do while the app is not open is push messages, which is a great start! But lets hope that either someone can develop an open source API or RunRev plans to put it in the future versions of Livecode.

[FourthWorld]

Background tasks are very tricky with mobile, where battery life is a high priority. Historically, LiveCode's focus as been on GUI apps, while mobile services, at least on Android, are more akin to daemons in desktop OSes, usually written in lower-level languages to be as efficient as possible, a critical goal for an always-on process.

That said, I certainly wouldn't mind if LiveCode were extended along these lines.

I realize it was just an offhand example, but an alarm clock may not be an ideal one: wouldn't it be more efficient to use the host OS' notification mechanism for that, resuming the app when the user responds to the notification? Background polling is expensive, esp. for tasks the OS already provides a mechanism to tap into.

What more specialized services would you be interested in having your app provide to the system, or background tasks your app could do that would be worth the battery burn?

iOS seems to take a relatively strict view of background tasks, exposing only a subset of APIs to apps not in focus. But I like the idea, and even within iOS' limits there are probably many useful things that could be done.

[SteveTX]

How about just being able to start a service / binary specified via the build process? A GUI is a front end to a backend. Livecode not being able to support any backend for mobile, like services/processes, makes it *extremely* limited. This means no software that monitors or reacts to any state changes, ie utilities, communications, security, networking, managers, etc. You know, the entire universe of applications that aren't games?

And since when is battery life a justification? LiveCode is primarily focusing itself on being the 2nd 3rd banana programming language for iOS GAMES, which use more battery life than anything else. And limited API subset? You're limited by LiveCode, not your imagination, it should be the other way around. And finally, 15 - 25% of mobile devices are jailbroken / rooted, meaning those supposed limitations in functionality go right out the window.

LiveCode needs to support processes, and should never have been released for mobile without it.

[bn]

Hi Steve,

have a look at:
http://mergext.com/

mergBgTask is an iOS external that adds commands to start and stop background tasks on iOS. Background tasks allow your app to continue executing code while in the backgound.

mergNotify is an iOS external that adds a command to request a notification callback whenever the iOS Notification Center receives the event notification

and how to keep the app from exiting on closing
http://www.youtube.com/watch?v=8qrnVGJ7lFA

there are limitations but depending on what you want it might get you somewhere.
Runrev is currently very active to get the Android externals working and Monte said he will develop similare externals for Android once the external kit is working.
http://forums.runrev.com/phpBB2/viewtop ... 66&t=15882

Kind regards
Bernd

[FourthWorld]

And since when is battery life a justification?

Since iOS SDK 1.0 - even their current version includes such caveats:

For iOS apps, it is crucial to know whether your app is running in the foreground or the background. Because system resources are more limited on iOS devices, an app must behave differently in the background than in the foreground. The operating system also limits what your app can do in the background in order to improve battery life and to improve the user’s experience with the foreground app.

https://developer.apple.com/library/ios ... sFlow.html

Like I wrote earlier, I certainly wouldn't mind if LiveCode were extended along these lines. MergeXT may help extend LC far enough for what you need, but without knowing the specifics you're aiming for it's difficult to tell.

[SparkOut]

Is there any more on the roadmap for externals or natively being able to keep an app alive in the background?
One thing in particular I want to be able to do is track via GPS on a regular interval, which currently I understand to be impossible if the handset goes to sleep or switches to another app, or the user makes/receives a call.

[simon.schvartzman]

This is a very old post but I wasn't able to find anything newer regarding the same subject so here I go.

I would like to have an App sending the GPS location to a server every one minute or so even if it is on the background. I understand this is not a LC functionality, correct?

I have seen this solution

http://www.youtube.com/watch?v=8qrnVGJ7lFA

suggested by @bn but is would work for iOS only and in my case it should work for Android as well.

Any other options?

Thanks and regards

[sphere]

That is something i would like too. Sending GPS coordinates even in background for an app idea i have started with. As for start on Android and later iOs.

Also then you have to take into account the rules set by Google (maybe apple too) about Battery Drainage and such. Google rejects app with webbrowser widget if you have a youtube movie playing which does not stop audio when hitting the Power button, and thus is not applying to the API. (but this seems to work when used on Android 8 and higher only)

[Mikey]

Did you look at mergBGTask?

[SparkOut]

Is mergBGtask available for Android?

[Mikey]

Not that I know of, but one of the things that Mark mentioned was subprocesses in Android, which gives me hope that maybe there is some other mechanism.

[SparkOut]

But still no roadmap for an Android solution

[Mikey]

I don't know. Check with Mark and Monte.