Android Applications

Talk about anything
SOTE
Posts: 657
Joined: 15 Jun 2015, 06:21

Re: Android Applications

13 Dec 2018, 21:51

nnnik wrote:
11 Sep 2018, 11:10
So you didn't understand what I wrote.
Java has no built in API to create Hotkeys for the entire system.
We would have to get an API that would provide it or built our own - in C/C++ or some other language that Java can use that can also implement super global hotkeys.
So in the end we would write our Hotkey code and most of the language features in C/C++ for Java to use in. Also we have to write a C library for every different OS.
So in the end we would rewrite AutoHotkeys core in Java and built the entire featureset into a dll/whatever linux uses for libraries which will will be shipped with the distribution !specific! for your OS.
the only thing that would change in comparison from now is the rebuilding of the AutoHotkey core in Java - which is more work than making AHKs current core modular and targeting different OSes.
So switching the language doesn't bring any benefits at all.
In looking at this again, the solution might be to use Pascal. FPC (Free Pascal Compiler) can do cross-compiling into other OSes, including for Android. Interestingly, I have come across a few programs and programmers that seem to be blending AutoHotkey and Pascal.

The other aspect of this though, is to divorce from the thinking that the AutoHotkey language is the same as the AutoHotkey interpreter written in C++. When thought of separately:

1) The feasibility of creating a transpiler (source to source compiler, https://en.wikipedia.org/wiki/Source-to-source_compiler) comes to mind.

Though it might be heresy for some, there have been a number of successful transpiler projects. Arguably, AutoHotkey is such a language to give it a shot. A transpiler seems to be a better way to go, as the AutoHotkey C++ source for the interpreter has become so large.

2) When a script is written in AutoHotkey, every option and command that the AutoHotkey interpreter provides isn't necessary.

This is an area where a transpiler has an advantage. Only the relevant needed code, for a specific script/program, is translated into Pascal.

3) Every aspect and command of AutoHotkey for Windows doesn't necessarily have to be ported over to a different OS, for such a transpiler to be highly useful.

Many of AutoHotkey application building features look "linguistically" transferable to Object Pascal and LCL (Lazarus Component Library). "Linguistically", as in the AutoHotkey language to it's near equivalents in the Object Pascal language, and not direct porting of existing C++ code to Object Pascal code.

There are certain automation features and commands of AutoHotkey that might need workarounds, but the possibility does seem there.
User avatar
nnnik
Posts: 4187
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Android Applications

14 Dec 2018, 03:19

Yeah you would have to give up on Hotkeys, Window features, Send and Control features.
Recommends AHK Studio
SOTE
Posts: 657
Joined: 15 Jun 2015, 06:21

Re: Android Applications

14 Dec 2018, 23:35

nnnik wrote:
14 Dec 2018, 03:19
Yeah you would have to give up on Hotkeys, Window features, Send and Control features.
Pascal programmers have long ago created code for Hotkeys and Sendkeys, and the code is on the Lazarus forums. Sendkeys is part of so many languages, to include VBScript. Other features for Windows and controls are a matter of coding. Object Pascal is nearly as capable as C++ for doing what is needed. What is not already available in the Lazarus IDE or Object Pascal, can be coded as functions or libraries. There are already a number of Pascal projects that provide automation, and provide various features and functions that are in AutoIt and AutoHotkey. And it's not like those programming in Pascal can't port or be inspired by looking at C or C++ code, for making an Object Pascal version. To even include that there are programs that can do source-to-source from C to Pascal.

The mix of application building, automation features, and utility is relative to what people have in mind. That is to say, that the intent may not be to exactly duplicate AutoHotkey for Windows, but might be to provide a significant and useful set of features. A good example of this is AutoKey on Linux, which appears to have been inspired by AutoHotkey. Object Pascal is already great for building applications, across many different platforms. We are not talking about re-inventing the wheel or automation from day 1, but mainly talking adding various automation features to a very strong application building platform, and to what extent

To have an understanding of how much more further along some Object Pascal projects are, in regards to automation, refer to the Simba project. This project is quite old, from more than 8 years ago, yet had/has many AutoHotkey-like features and is cross-platform on both Windows and Linux.

Simba features include Sendkeys, FindColors, IsKeyDown, CreateBitmapString (Bitmap to string), OCR, various Target Window functions and commands, etc... http://docs.villavu.com/simba/referencescript.html In fact, Simba could arguably be feature compared to AutoHotkey and AutoIt, as they are today, despite that it was developed years ago. Simba is also open-source, on GitHub, and still has some activity. https://github.com/MerlijnWajer/Simba/tree/fpc-3.0

The AutoHotkey language is just a subset of the total of what Object Pascal can do. And what is even more interesting, is how well the 2 different languages match up in many areas. If you go through the AutoHotkey Alphabetical Command and Function Index, you will find that a substantial portion of such is already available in the Object Pascal language. It's really more a matter of "translation" from one language to the other, thus I suggested going the transpiler route. This potentially opens the door for AHK coders to do source to source translation and then compile useful scripts directly on other OSes. Anyway, the point of posting about it, was to provide some food for thought.
Last edited by SOTE on 15 Dec 2018, 02:39, edited 2 times in total.
User avatar
nnnik
Posts: 4187
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Android Applications

15 Dec 2018, 02:29

This is more an issue with androids system architecture than any language that you suggest using.
Recommends AHK Studio
SOTE
Posts: 657
Joined: 15 Jun 2015, 06:21

Re: Android Applications

15 Dec 2018, 03:20

nnnik wrote:
15 Dec 2018, 02:29
This is more an issue with androids system architecture than any language that you suggest using.
Oh, I see. True that there are various default restrictions to applications interacting with each other on Android, but my understanding is that if you gain root and give root permission to the application, you can work around this. And for IT enthusiasts, many are not settling for being restricted by smartphone makers like Samsung or Apple, and are looking to root their phones. In addition, after gaining root, you can turn your Android phone or tablet into being a more "Linux-like" distribution. Even without gaining root, there appears to be some workarounds that allow you to convert your Android device into a more standard looking Linux distribution. Refer to- https://www.xda-developers.com/guide-in ... id-device/

Enthusiasts are breaking the barriers between Linux and the standard Android installs all the time, in order to allow more Linux applications to run on Android. This could mean that an automation application for Linux, could possibly get up and running on Android as well. Not saying it would be anywhere the equivalent of AutoHotkey on Windows, but it might be useful. Note- People can already bypass Google Play, and download or install applications of their choosing on their Android phones or tablet. Which is a willful bypass of some restrictions.

And, we might want to look outside of automation. All applications don't need automation features nor are trying to interact with other apps or modify any restricted features. The AutoHotkey language is very much capable of building a more standard type of application.
User avatar
nnnik
Posts: 4187
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: Android Applications

15 Dec 2018, 04:02

Indeed - but in order to do this you will have to make quite a few changes.
The current AutoHotkey language is not made for cross platform compiling.
It would make sense to create a language which expresses itself in a way that is not specific to any os.
Recommends AHK Studio
SOTE
Posts: 657
Joined: 15 Jun 2015, 06:21

Re: Android Applications

15 Dec 2018, 13:12

nnnik wrote:
15 Dec 2018, 04:02
Indeed - but in order to do this you will have to make quite a few changes.
The current AutoHotkey language is not made for cross platform compiling.
It would make sense to create a language which expresses itself in a way that is not specific to any os.
Is A New Language Needed?

I don't think that any automation language could be so agnostic, because of the differences between OSes. In order to exploit certain features of an OS to the maximum or greatest extent, inevitably there would be some different language to express specifics. It could be a matter of using existing AutoHotkey language for Windows when applicable, and having a subset of OS specific commands when not. Such was the case for AutoHotkey on WInCE years ago, (https://autohotkey.com/board/topic/2477 ... artphones/).

Case in point, 2 examples that I gave were Autokey and Simba (http://docs.villavu.com/simba/referencescript.html). Simba runs on both Windows and Linux, with few discernible differences. However, Simba is often used for more limited purposes as oppose to automation in general, and it is their use of Pascal that gives it more generalized capabilities over what it appears that it was initially designed for. AutoHotkey looks to be able to cover what Autokey does linguistically (despite it being run on Linux), without needing any new language.

Cross Platform Compiling

In regards to this, it's why I mentioned a transpiler (source to source compiler). It's Object Pascal and the Free Pascal Compiler, which could provide cross platform compiling. The transpiler could translate AutoHotkey script code to corresponding Object Pascal code. Where a 1 to 1 correspondence is not possible (though people might be surprised how much 1 to 1 or near to it syntax that there is), various functions written in Object Pascal may provide the required ability to execute a command from the AutoHotkey language.

This possibility can be readily seen by looking at Simba scripts and comparing them to AutoHotkey scripts. Though the purpose and goals of the 2 scripting languages are quite different, it can be seen how AutoHotkey language might be translated into Object Pascal.

Part of the thinking on this, is to separate what is the AutoHotkey interpreter (written in C++), from the AutoHotkey language and syntax. Where the AutoHotkey language is thought of in a more agnostic way, and can be implemented in other lower level languages. Object Pascal is unusual in this regard, as having both low level and high level language attributes, and the FPC (Free Pascal Compiler) that can do cross platform compiling. To include for both Linux and Android.

Return to “Offtopic”

Who is online

Users browsing this forum: No registered users and 17 guests