[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: How can I write an android web application using orbit?
- From: matthew@...
- Date: Thu, 03 Dec 2015 13:35:10 +0000
At LogicNets, we have a fairly large Lua application which we have
ported to run on both iOS and Android in a fashion similar to what you
1. For details on getting Lua to run on iOS, take a look at my iLua
project (https://github.com/profburke/ilua). It's a little bit of a
work in progress, but it should get you pointed in the right direction.
2. For Android, doing it from scratch isn't too bad, but you'll almost
certainly instead want to use something like LuaJava
(https://github.com/mkottman/AndroLua), or LuaJ
(http://www.luaj.org/luaj.html). For our application, we used LuaJava
(although we had to do some customization---for reasons not worth
discussing here, we are still using Lua 4). Note that we did the
Android port almost a year ago when Eclipse was still more or less the
preferred IDE for doing Android work.
These days you should consider Android Studio instead. However,
although in theory it supports the native development kit (NDK---the
ability to compile C code, which you will need), my initial (limited)
attempt at getting it to work was unsuccessful.
I'll just throw out that there are a few alternatives for doing
cross-platform Lua. For example, Corona (https://coronalabs.com/)
which you might also want to look at.
3. An important note about application architecture: for both
platforms (Android and iOS), we have a native app that works as follows:
1. Does some initial setup and configuration
2. Starts a background thread has a Lua VM. This VM runs a simple web
server we've written in Lua.
3. On the main thread presents a webview component (WKWebView on iOS,
android.webkit.WebView on Android). This webview is told to load a URL
On Android it is possible to do something like what you suggest: run
your application in the background and have the user use a browser to
interact with it.
When your app launches it could create and run a service
(android.app.Service) and not present any sort of UI.
I don't think you want to go that route. I think it's too awkward and
confusing for the user. If you instead use an approach like we took,
you will present the user a more unified experience which she has
better control of.
On iOS you can't take the approach you described. You have to do
something like we did because you can't have long-running background
apps. Yes, I know all about foreground and background apps on iOS. But
none of the mechanisms you can use for doing background processing
will allow you to run a web server that doesn't get terminated pretty
quickly. Note that running an app in the background is not the same as
having a background thread running in your foreground app (I'm tired
and not explaining this well).
Anyway, let me know if you have more questions.
Matthew M. Burke