 The BIM enthusiast since 2007, so an OG for the BIM. I mean, the BIM is very old, but still very old time enthusiast. And he will be talking about a BIM VM for Android following Luke's talk on BIM on the browser, and the Arian BIM on Embedded, now BIM for Android. So let's give it up for Victor. Thank you. Welcome, everyone. So as it was mentioned in the introduction, I have been a BIM enthusiast since 2007. But today I would like to talk about a project that I started last summer. So it's basically half a year's work or a bit more, which is named the Coffee BIM. Let's look at the questions that I would like to answer today. First, I wanted to know how the BIM file actually works. So that was my main motivation. I was really curious how to get it running. And also I found it a use case that why not run the BIM files on Android in a very, very simple way. So you should imagine a lightweight BIM execution environment. So I wanted to skip all the different stuff which can be issues on Android, like getting the right privileges for running the files or using some scripting layers to provide a base foundation for the BIM and also to just make it work in a simple way. So I thought that this should be possible. Let's see later if this is possible or not. What do you need to make it happen? So what are the building blocks that you can use? How these parts fit together? So I'm talking about the Erlang part, the BIM part, but also the Android part. And last but not least, how can we ensure the communication between the phone and the Erlang VM? Yes, so this seems possible, what I've done, but different, quite a lot of ways. If you are using Erlang to build Android applications, this coffee beam execution environment basically ensures that they are robust. That's quite OK. So it does what you expect from a BIM file. So it understands the basic Erlang mechanism and also being a functional programming language that functions with the same parameters will give the same result. Also, it is concurrent, so processes are supported. You can start as many processes in the VM as you want. Scalable, well, this is not yet implemented, but it may be doable. So for real time, it just depends on the capabilities of your Android device. Let's see a short demo. What I've made, this is basically the tic-tac-toe game built on the coffee beam VM. And in the background, there is a BIM process running the game logic and also managing the computer intelligence. If you're watching online, you should find the link to this video at the topic description. So I'm playing with the X. The computer is within the circle. And as you can see, the BIM intelligence is working on the mobile phone, providing the next steps to the computer. So it seems possible, but what do you need for that? To make it work, first, basically, you need to get Android to understand the BIM file. As the main language for Android is Java, there are also many other ways to do this, like Kotlin or C++ and things like that. I chose Java to understand the BIM file. Also, you need to load the BIM in an Android way, because this is not as simple as a usual file system on your PC. There are special privileges that you need to access files. And also, in this project, you want the BIM files to be presented in the source code integrated into the Android, basically, as a library or as a resource that you can reuse. What I wanted to avoid is to recompile the BIM files in a special way that it will fit Android. So these BIM files basically are runnable on every PC as well. You need to create a VM, for sure, that executes these BIMs. So that should be a logic on executing the parse BIM file. And also, you need to provide a way of communication to interact with the Android. This is a different approach. And what I chose is to use high-level structures in the VM implementation. So I didn't want to manage the low-level memory or optimize for low memory usage, managing the bits and bytes, because in an Android phone, you have plenty of memories. So it's not a bottleneck. The more the bottleneck is the CPU power. So if you are using a lot of CPU, then it will shorten your device's lifetime. How these parts fit together? Basically, you have the VM written in Java and also compiled into a JAR library that you can use. So the green boxes are what you can use for free, what you get for free. You need to add to this library your own custom BIM files that you pre-compiled and insert the whole thing into an Android activity. I will talk about this later. And also, you have to have a BIM client or a customized BIM client, which has the purpose of managing the VM itself and also handling the communication between the VM and your Android application. When everything is ready, you package it into an APK and you have a deployable Android application using Erlang on your phone. The BIM client is partially implemented in the VM itself. So you get a BIM client class, which provides the basic functionality, like starting and stopping the VM, also loading the BIM file and applying custom functions, which are basically translated into Erlang function calls. And what you need to implement yourself is to provide input for which functions and which arguments to apply and provide a way to handle the results of your function calls and also to implement callbacks for your custom function calls from inside the VM to the outside world to the Android. I promise you that this will be the most complex slide for today, for this talk. Let me just show the behavior of this tic-tac-tac game what I implemented. So you first start an Android activity, which is basically a way of creating interactive applications. You can imagine activity as a Java class, which has the functionality to interact with the user, getting the GUI elements together, and also managing the process in an Android way. So it provides GUI processes and other processes as well. So you can imagine the Android activity as a simple application. From this Android activity, you can call the Beam client or the customized Beam client, which you have implemented, to apply a function call to the VM. Basically, you provide strings, like the module name, function name, and the argument list, which is a special type that is implemented in Java in order to understand the Beam structures. The tic-tac-tow game will start. The internal error function call is tic-tac-tow start, which returns the PID. This PID is transformed back as a function call back inside the Android. So you have the game PID, which you can refer to. This game PID is basically a new process that is started inside the VM. You press the New Game button, then it will also apply a function call starts a new game, and the game process actually sends updates, repeatedly, to the Android VM with the custom function call Beam client update. How to handle this update function is basically depends on how you write the Android activity. In this game, this update contains the information about the game, the board, the current state of the board, and what action or event has happened, like the player or the computer has placed a sign on the table or the board has changed, someone has won, someone has lost, or the game will end in a draw, like in the video. Also, when you click a field, it invokes, in the same way, function apply MFA, tic-tac-tow put, then a board update happens, and also they put player events, so the player has put their sign on the board, then the computers turn, this also updates the board, and after many, many iterations, you will end up with updating the board with the event like draw, win, or loss. So this is basically the game communication, and the game logic is fully implemented inside one Erlang module in about 200 lines, this is the game flow and the computer's intelligence, and also there are some special callback handling which are written inside the Android activity in Java to handle this functionality, but the VM is untouched, so the library that is provided by the CafeBeam VM, basically you can use it as is. This is a public project, so this is the GitHub address, where you can check the source code, and also I will encourage you to contribute to this as well because there is a lot of work to be done, like future plans, IO handling, this is not yet implemented, also it is a big question how to handle IO in Android because you usually don't have a mechanism to fetch or view the log files, or you don't have a terminal screen where you can examine the results of function calls, so you need to handle it in a different way. Also, file handling is a bit tricky in Android, so there are a lot of questions in that. Network support, it would be really good to have a cluster of Android phones working together as nodes of one distribution group. This is still a dream, but I hope it will come in the future. Node management, otherwise number handling, of course Java doesn't support the big numbers as a built-in type, so you have to implement the mechanism yourself based on what has been done already in Erlang handling big numbers, and also there are lots of biffs built in functions that are still need to be implemented or to be reviewed. And for the end, some useful reading, so these were the sources, which I used to understand the beam and get more detailed picture on how beam works, and which I used basically in the coffee beam via implementation. So we have a lot of time, so we have more time for questions. Thanks for your attention. Yes? I'm assuming that you went to beam wisdom that you're, did you look at Erlang, which hasn't been updated in a while at all, or was this like a from scratch implementation? Yes, so the question was, if Erlang was an option, or if I have looked in the source, as mentioned in the beam wisdoms, yes, I studied the solution. This is a common question, so I put up this into a slide. I have examined a lot of different options, one of them was Erlang. Why I didn't really use this implementation is that, yep, some parts were really nice and really useful, for example, in handling the different Erlang types. I didn't take the code as is. I had to make some modifications, but of course I wanted to use it in a different way. So using the meaning of the types in understanding beam files, but not in recompilation of the code, so that's why Erlang, as a complete option, was not considered. Any other question? Yes? Specifically, if you're doing Erlang or Android, what separates? Please clarify the question. I have, if I'm not mistaken, Erlang, the beam can be cross-compiled for Android, and so routed devices can do that pretty easily. What makes it more complex for non-routed devices? Yes, so basically beam files are files. The question was that, what makes this beam file handling more complex on Android phones? Although there are some cross-compilation functionalities that you can use. Basically, beam files are files, so you have to handle them as binary input, as accessing file on a file system, which is not always easy on an Android phone. You have to get the resources or get access to the resources into the directory where this file is located, and this is sometimes not so easy. And also, in this solution, you can basically use a pre-compiled beam and put it as a resource inside your custom application without changing the original content of the Erlang source, from which this beam file was compiled. So that was my goal. Yes? Yes, I have a lot of different test cases, basically using the Ant Framework or compiling the Java code, creating the JAR library, but also there is a test module where you input a lot of Erlang expressions and have an expectation on the functional results, and this is how it is tested. This was also creating new processes or checking how the more tricky parts in the VM are handled. So the Ant Framework is basically the answer to what you use as a framework. Sorry. We may need this. Thank you. Thank you.