- It includes an on-device-hosted WebEditor, so you can code also from your computer
- Simplified API
- API that allows to do cool stuff such connect to Arduinos, BT BLE, MQTT, sensors, etc
After some time on hold I picked up dev again and I'm about to release a pretty nice release soon. I invite you to join the Discord channel as I will start posting updates there :)
thanks for the pointer! As ten-thousands before me I just had the epiphany that phones need to be more like Apple-IIs or a web-inspector, where you drop to a development environment / shell to edit and create your own apps
Yes, it's broken. I'll update the website soon with the next release to reflect this. Work&family doesnt leave me much free time for this :)
Not so far ago, Google changed some policies where you had to give good reasons to allow the app to access the location in the background. PHONK was unlisted then because I failed to showcase the reason for using the background location (they wanted a video and the video I provided seemed not clear enough to be understood)
PHONK is a coding environment that gives a lot of power to the user to do pretty much anything with the device. So if you want to make a script that runs in the background to create a Geolocation game, you can do it.
After a few changes like this, I realized that I'm going to distribute PHONK only as an APK, F-droid from the next version, and of course with the source code in Github.
Just to make it clear, PHONK doesn't use analytics or send info anywhere as opposed to most of the apps. I had hoped Google store could see that to give more margin for apps that behave nicely with the user.
I would not be surprised if other constrained interpreter environments could be created like this one. From the descriptions I believe a Hypercard, Logo, python or (forgive me from saying this) Basic scripting could be created.
We could turn lots of older phones into portable toy dev platforms for the next gen of programmers.
There's also termux and it's predecessors, running debian rootfs with or without root. (Most of them based on proot).
Before proot, there were some manually ported GCC and friends.
Some years ago, I had an android 5 phone and hacked up a fakechroot'ed debian rootfs on a terminal emulator without root. Basically unpacking some debian .debs with statically linked busybox binary, then using a chain of LD_PRELOAD hacks to call a shell with a shim.
But proot is better solution (ptrace instead of shim), and termux is very well done.
On the other hand, if you're thinking about scripting without all the hassle of Unix, I saw an app for experimenting with Android APIs using beanshell [1], I made an attempt to create a modern clone for my Android course project this year, but couldn't take it much far due to shortage of time.
>The PilBox App itself (called the "PilBox kernel") is written in Java, the normal Android way. It displays a WebView GUI, and starts a PicoLisp binary compiled for Arm64 CPUs. This binary may now run any PicoLisp program, by setting up a local web server where the WebView component connects to, possibly opening a database, and doing whatever is desired.
x86 is commonly used for emulators which is very useful for compatibility testing.
Although if the goal is to not install the Android SDK for some reason then sure, don't really need to care about x86. Unless you want to run on Chromebooks or Windows 11, though. Then you do again.
It's nice to see new tools and SDKs being built to try and simplify development. However, I'm always against frameworks/SDKs which try to abstract away the native coding experience and move developers away from using the SDKs Apple/Google provide.
These types of solutions will always lag behind the official SDKs, and require ongoing maintenance from the authors as new features are added. This also requires individuals to learn something else in addition to the core SDK (I believe you will ultimately need to learn about the core SDK regardless of what you want to do).
In my opinion, working with the native SDKs is the best solution. You are as close to the SDK as possible and are able to do what you want. For Android in particular, it's important to minimize the layers between your code and drawing the UI.
With that said, kudos on building this as it's no easy feat to accomplish.
This doesn’t pass the sniff test for me. A language interpreter with downloading remote code abilities is basically a new web browser. Maybe doesn’t use HTTP/HTML/JS, but has similar dynamic abilities. That’s what apple doesn’t want on their platform.
AFAIK (maybe someone else will correct me) there are two things that people run into when implementing interpreters:
1. You can't write a JIT because you need to be able to dynamically allocate executable memory, which is typically not allowed
2. The App Store needs to know up front what native methods & behavior your app accesses so that it can allow users to observe and control what your app can access. Accessing new native methods by downloading random code over the internet is not allowed
There are ways to get around (2) by ensuring you request access to everything your app could possibly access up front, but that could also lead to rejections for asking for permission for things your app doesn't actually need. It's a bit of a dice roll.
There was talk that ability to do (1) might be coming in an update a couple years ago, but no official policy change ever came of it.
Apple even locked down the M1 and M2 machines so that user programs cannot normally produce object code and then jump to it. (IOW the compiler is active at runtime.) Lisp programmers who use Lisp compilers just call this behavior 'Lisp' but everybody else calls it 'JIT' because the only time it comes up in other languages is in interpreters that optimize at runtime.
Fortunately Apple carved out an exception for runtime object code on Apple silicon to allow optimizing interpreters to work, and they call it 'JIT.' Because of this loophole it's still possible to run Lisp compilers on MacOS on Apple silicon.
Apple never allowed the JIT loophole on IOS, which is why it's not possible to run a full Lisp compiler on IOS. You can run programs created with Lisp but you can't use any Lisp features that depend on the runtime compiler, so the language feels somewhat crippled.
How would apple know that my app contains my own custom interpreter? It's just a program that takes raw strings (whatever the source may be) and behaves in some arbitrary way according to the string. How can this be detected automatically? Looking for a certain interpreter patterns (e.g. A big switch)? I imagine this would be extremely fragile to false positives and also code can be automatically obfuscated arbitrarily (convert the switch into if-else trees and spread them across subroutines).
As far as I know, they have issues if those apps download external code and then execute (which makes entire classes of applications impossible).
However, I know of at least one application where all the game logic was built with Gambit Scheme. The scheme code was compiled to C and then embedded. One could theoretically open a remote REPL over the network and issue commands, but that feature was disabled before release.
Is that an 'execution environment' or 'interpreter'? The binary contains both.
Being able to code in your phone is fun... although as a native Android developer this won't replace Android Studio for me (yes bloated/resource hungry bla bla bla... I know).
Anyway, let's give it a try:
Typing "$ ls -l" on the REPL input box gave: "-> NIL"
And repeated back press won't close PilBox. Seems like it's intentional (or just a bug?). Will take a look at the source code later...
The differences are:
- It uses a Javascript interpreter
- It includes an on-device-hosted WebEditor, so you can code also from your computer
- Simplified API
- API that allows to do cool stuff such connect to Arduinos, BT BLE, MQTT, sensors, etc
After some time on hold I picked up dev again and I'm about to release a pretty nice release soon. I invite you to join the Discord channel as I will start posting updates there :)
https://discord.com/invite/Rt2mkWp
(EDIT: formatting)