In my recent post on react-native vs kivy, I suggested an alternative that bridges some of the concepts of each of the two projects together. Well, I decided to make one. The result is enaml-native.
enaml-native borrows a lot from kivy, including pyjnius, and python-for-android. Much of the bootstrap code was based on kivy's implementation. However, unlike kivy, which includes it's own widget framework, enaml-native uses native widgets. Edit: enaml-native no longer relies on pyjnius. It now uses the JNI directly to improve startup times (or Websockets for remote debugging).
It differs from kivy and BeeWare's rubicon projects in that it uses a bridge, like react-native does. With this design, python is completely decoupled from the native app (thus preventing it from slowing down the UI).
The bridge thread has it's own message handler. The python thread queues and then pushes a bundle of msgpack events which get's sent to the bridge thread for processing. The bridge thread unpacks each event and translates it into a create, update, or delete modification of a Java object. Results and events are packed, batched, and returned back to python by using the jnius NativeInvokationHandler. Edit: It now replies using the JNI directly (or Websockets when remote debugging).
That's about it. A detailed overview of the bridge can be found here.
With this implementation, objects are not converted back and forth, they are passed as references, which greatly reduces overhead. Additionally, even though python is without a doubt slower than Java and Objective C, since the the bridge is async, and python is in a thread, it prevent's python from slowing down the UI keeping animations and transitions smooth.
Finally, a toolkit for enaml was implemented that to declares the UI and handle all events and interaction required (using the bridge behind the scenes). It's extremely easy and extremely powerful.
Displays the hello world.
As soon as I get time. I started working on an iOS implementation but have not yet finished. The main blocker at the moment is compiling all the libraries with kivy-ios. Not yet released, but I've added some features to it already (including pip installed libraries).
Yes, please do. You can pull the repo and test it out, submit new widgets. Share it, whatever! Anything helps!
What is enaml-native?
The goal of enaml-native is to be the python version of react-native. Or to change their tag line:
enaml-native lets you build mobile apps using only python. It uses the same design as enaml, letting you compose a rich mobile UI from declarative components.
How does it differ from Kivy or Rubicon?
enaml-native borrows a lot from kivy, including pyjnius, and python-for-android. Much of the bootstrap code was based on kivy's implementation. However, unlike kivy, which includes it's own widget framework, enaml-native uses native widgets. Edit: enaml-native no longer relies on pyjnius. It now uses the JNI directly to improve startup times (or Websockets for remote debugging).
It differs from kivy and BeeWare's rubicon projects in that it uses a bridge, like react-native does. With this design, python is completely decoupled from the native app (thus preventing it from slowing down the UI).
How does it work?
It's design is based on react-native. There are three threads, the main UI thread, the bridge thread, and the python thread. When the app starts, it kicks off the bridge thread, and the python thread.Bridge thread
The bridge thread has it's own message handler. The python thread queues and then pushes a bundle of msgpack events which get's sent to the bridge thread for processing. The bridge thread unpacks each event and translates it into a create, update, or delete modification of a Java object. Results and events are packed, batched, and returned back to python by using the jnius NativeInvokationHandler. Edit: It now replies using the JNI directly (or Websockets when remote debugging).
That's about it. A detailed overview of the bridge can be found here.
Python thread
Python is run in a thread with it's own event loop (either tornado or twisted) and communicates with the bridge thread using msgpack buffers (currently transported over the JNI).With this implementation, objects are not converted back and forth, they are passed as references, which greatly reduces overhead. Additionally, even though python is without a doubt slower than Java and Objective C, since the the bridge is async, and python is in a thread, it prevent's python from slowing down the UI keeping animations and transitions smooth.
Finally, a toolkit for enaml was implemented that to declares the UI and handle all events and interaction required (using the bridge behind the scenes). It's extremely easy and extremely powerful.
Does it work?
Yes, try the demo app on the play store. I update it periodically. You can view the project on github, and there's a few videos I've been adding on youtube. |
| enaml-native app showing a toolbar, drawer layout and tabs |
What does an enaml-native app look like?
Like enaml, just different widgets. See the examples. For example:
from enamlnative.widgets.api import * enamldef ContentView(LinearLayout): TextView: text = "Hello world!"
When is iOS support coming?
As soon as I get time. I started working on an iOS implementation but have not yet finished. The main blocker at the moment is compiling all the libraries with kivy-ios. Not yet released, but I've added some features to it already (including pip installed libraries).
Awesome. I will take a look on your project. It is look pretty nice.
ReplyDelete