and this issue summarises how those points are addressed in the current port.
A more ambitious approach would be to integrate node.js into the Android
Native Application APIs. This would allow node.js apps to run as full
Android applications. As far as I know nobody has done this yet.
Some issues you may run into if you try this:
Android applications only deal with native code in shared libraries.
You'll want to repackage node.js as a shared library.
Combining event loops. Android uses an epoll event loop to handle events,
and so does node.js. You will have to figure out how to combine these two
event loops together.
This isn't done and IMO isn't necessary. A thread is spawned that enters the node.js event loop and blocks there. It does not need to service an other event queue.
Node.js has its own custom make system, and so does Android, and they
aren't the same. You'll have to figure out how to work around this.
This is addressed by having a new set of makefiles based on the Android make system.
Javascript to Java bridge. Many Android APIs can only be accessed from
Java. You'll want to write a V8 to JNI bridge. (JNI is the standard way for
C/C++ code to call Android Java code.)
This isn't done yet, but is definitely on the roadmap.
This is the key reason why node needs to run in-process as a library, and not be spawned as a separate process.
Some Android APIs require subclassing Java classes. You can deal with this
by subclassing the Java APIs with Java classes that forward to Javascript.
This issue needs to be addressed generically with the JS to Java bridge.
Node wants to run on the main thread, but some Android APIs will throw
runtime exceptions if you call them from the main thread. (They do this
because they block.) You'll have to figure out a way around this, perhaps by
having helper Java classes that run on secondary threads.
All Custom modules that need to execute in the Java framework need to spawn threads as necessary to do their work. Then those threads need to be able to post events back into the event loop. Again, this is a generic issue to be addressed in the JS to Java bridge.
The general problem of the JS to Java bridge has been addressed before in other environments - eg the Aplix WebVM plugin (which integrates JS to java in the browser environment). The same approaches used there can be used in this case.
A general question was previously posted here: http://groups.google.com/group/nodejs-dev/msg/1bb0eab3f89ec054
and this issue summarises how those points are addressed in the current port.
This is done - see https://github.com/paddybyers/node/issues/9 - although there are still issues to work through.
This isn't done and IMO isn't necessary. A thread is spawned that enters the node.js event loop and blocks there. It does not need to service an other event queue.
This is addressed by having a new set of makefiles based on the Android make system.
This isn't done yet, but is definitely on the roadmap.
This is the key reason why node needs to run in-process as a library, and not be spawned as a separate process.
This issue needs to be addressed generically with the JS to Java bridge.
All Custom modules that need to execute in the Java framework need to spawn threads as necessary to do their work. Then those threads need to be able to post events back into the event loop. Again, this is a generic issue to be addressed in the JS to Java bridge.
The general problem of the JS to Java bridge has been addressed before in other environments - eg the Aplix WebVM plugin (which integrates JS to java in the browser environment). The same approaches used there can be used in this case.