Android Applications

Post a reply


In an effort to prevent automatic submissions, we require that you complete the following challenge.
Smilies
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :| :mrgreen: :geek: :ugeek: :arrow: :angel: :clap: :crazy: :eh: :lolno: :problem: :shh: :shifty: :sick: :silent: :think: :thumbup: :thumbdown: :salute: :wave: :wtf: :yawn: :facepalm: :bravo: :dance: :beard: :morebeard: :xmas: :HeHe: :trollface: :cookie: :rainbow: :monkeysee: :monkeysay: :happybday: :headwall: :offtopic: :superhappy: :terms: :beer:
View more smilies

BBCode is ON
[img] is OFF
[flash] is OFF
[url] is ON
Smilies are ON

Topic review
   

Expand view Topic review: Android Applications

Re: Android Applications

Post by BoBo » 02 Nov 2021, 11:35

Not sure if of interest anymore but :arrow: AutoMagic4Android offered to automate/script events on/for Android. You can download it at that page and side-load it onto your device. Unfortunately, it hasn't gone open source (for now) *sigh*

https://automagic4android.com/action_script_en.html
https://automagic4android.com/action_http_request_en.html
...

Re: Android Applications

Post by magicinmath » 25 Apr 2020, 16:35

Happy to see this thread was discussed with some interest in the years since I posted the original thoughts I had.

I'm doubling down with respect to cross-platform capabilities, particularly with Linux but also with Android, even if it was merely and translational service at first, this would cement AHKs legitimacy and purpose for time to come. The concept of a desktop computer environment as it is currently defined will likely become unnecessary as we move further into the future. That is the biggest threat I see for AHK, because without this style of the desktop environment, it isn't relevant. If we consider the adaptation and translation into other platforms, it could be thought of as gentrification of sorts and give validity for the future of the language. I love AHK so much it's been a big part of my life for some time, but truth be told, it's the only reason I use Windows, sadly if I was to find something relatively the same for Linux I would probably jet windows all together because the platform, in general, has been giving me the blues more and more as time passes.

I really hope some of the elite community members get something going because I love this language and community.

Re: Android Applications

Post by SOTE » 12 Mar 2020, 03:38

While it's fantastic that B4A went completely free (though B4I- iOS is still payware), they might have done so because of the amount of competition and the many other free options it faces. Even more now, than when the original post was created. Possibly the developer decided that it would be better to make money in providing support/support contracts with various companies than in trying to sell the IDE (the creator of OpenRPA mentioned such thinking). And keep in mind that B4J was always free for making Java apps on Windows, but it's impact was minimum in such a big crowd of languages.

For quite a long time now, Object Pascal (Free Pascal or Delphi flavors) could build Android applications. Delphi has a free Community Edition. The Free Pascal flavor for Android- https://sourceforge.net/projects/laz4android/, with Free Pascal (open-source) having a huge range of cross-compiling options. Also, in the case of Object Pascal, there already being automation libraries (Simba) that works on Linux and Windows, with WinAutoKey (for Windows only). If we are just talking building Android applications, C# can do that with Xamarin- https://dotnet.microsoft.com/apps/xamarin). In addition, there are many JavaScript solutions, to convert web applications to mobile applications. Go (https://en.wikipedia.org/wiki/Go_(programming_language), which has a lot of syntax similarities to AutoHotkey and is in the C family language (like JavaScript and AutoHotkey), can also be used to build Android and iOS apps. There are many ways around programming in pure Java for building apps for Androids these days.

B4A compiles into Java, so people are still going to get all the trials and tribulations that come with that. It's just that it's easier to program in B4X than in pure Java, but that also comes with more limitations and restrictions. B4X as a language, is closer to Visual Basic. Arguably this might be a factor for AutoHotkey people, as JavaScript (debatably easiest jump), Go, C#, or even straight up Java might be easier to jump to (as they are all C Family languages). JavaScript or Go syntax would likely feel more comfortable to AutoHotkey programmers. And there is a lot on the forums on using C# code in AutoHotkey projects.

The B4X language might arguably be more suitable for AutoIt people, as it's also somewhat Visual Basic like. And since the AutoIt source code is closed, they wouldn't usually be exposed to the C++ source code from which it came (unlike AutoHotkey_H users or the more curious that check out AutoHotkey source code on GitHub), thus might be more thoroughly immersed in the Basic programming world. Which include many flavors of Basic. Some, like KBasic/Basic for Qt and PureBasic, are already cross-platform (in their case works on Linux and Macs (https://www.kbasic.org/|https://www.purebasic.com/). RCBasic and SpiderBasic (similar syntax to PureBasic) can also build apps for Android. However, AutoIt users are planning to make a cross-platform version of their own.

https://www.autoitscript.com/forum/topic/198464-a-cross-platform-implementation-of-the-autoit-language/ (A cross-platform implementation of the AutoIt language). This appears to be mainly an effort to get AutoIt on Linux. Keep in mind that Android is built on top of Linux as well, and with some configuration changes and downloads, can run many Linux applications. They have also mentioned AutoHotkey in these discussions. It appears they are not trying to make a 1 for 1 implementation of the AutoIt language, but a subset that is AutoIt-like, that can do some things on Linux.

Re: Android Applications

Post by Ahk_fan » 11 Mar 2020, 09:20

Hello guys,

B4A (Basic4Android), one of best and powerfull programming software for Android is now free, also B4J is free.

more information here: https://www.b4x.com/android/forum/threads/b4a-is-now-free.113678/#content

Re: Android Applications

Post by SOTE » 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.

Re: Android Applications

Post by nnnik » 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.

Re: Android Applications

Post by SOTE » 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.

Re: Android Applications

Post by nnnik » 15 Dec 2018, 02:29

This is more an issue with androids system architecture than any language that you suggest using.

Re: Android Applications

Post by SOTE » 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/releases(Simba releases on GitHub)

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.

Re: Android Applications

Post by nnnik » 14 Dec 2018, 03:19

Yeah you would have to give up on Hotkeys, Window features, Send and Control features.

Re: Android Applications

Post by SOTE » 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.

Re: Android Applications

Post by nnnik » 16 Sep 2018, 06:46

I dont see pyautogui working on android.
Also if you check the github repository you will see that this project for automation in the python language has more people working on it than the entire Autohotkey language.
It's just the automation part thats being handled there and not even an entire language.

Re: Android Applications

Post by SOTE » 16 Sep 2018, 04:36

nnnik wrote: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.
No way was I arguing against your high level of programming knowledge, but debating the point about being open-minded about cross platform solutions and development. Other languages had people making the jump. PyAutoGUI (in Python) for example, https://pyautogui.readthedocs.io/en/lat ... ction.html.

If someone were to come along and want to develop for Android, .NET, macOS, etc... Maybe they should be embraced and supported, even if the end result will be somewhat different to AutoHotkey for Windows.

Re: Android Applications

Post by nnnik » 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.

Re: Android Applications

Post by SOTE » 11 Sep 2018, 04:02

nnnik wrote:No the part about needing to use C++ or C anyways.
It's incredibly different to target multiple desktop and window managers. We just barely manage to target the windows window manager.
Doing that requires access to low level instructions and low level interaction with the OS - specific too the OS.
C# and Java are both made to create code that runs on the system by only scratching the surface and never going deep into the OS.
The only way to circumvent that is using specific libraries written in C that this language would wrap around.
However when you have a langauge that already wraps around this library in a good way - why even use AutoHotkey anymore when you can use the language it is written in?
Regardless languages like Java and C# are a dead end for AutoHotkey and you might as well just develop in C/C++ rather than developing only parts in C/C++ and create multiple releases for multiple OSes.
Was not trying to get into it with you, but simply responding to AHK_fan's post about B4X, as was reading up on it.

In regards to C++/C VS Java, C#, etc... This can depend on what a person views AutoHotkey to be and the goals of a particular scripting language. That people see this differently is understandable. A person or group might be specifically interested in Android or .NET, and want to focus in that direction, versus a cross platform solution for many OSes. I'm not saying it's wrong if a person wanted AutoHotkey for the macOS, just being open about the possibility of it.

A user might be seeking a way to automate applications on his Android, such as have a particular app start at a certain time and send an e-mail or give an alert if a certain e-mail arrives. The level of scripting they want or require doesn't have to go that deep into the OS. Duplicating the full spectrum of AutoHotkey on Windows might not be what is wanted, so how they go about doing what is desired could be very different. It could be a matter of borrowing AutoHotkey syntax and commands to describe and do things that existing scripting languages on the platform does not or isn't focused on. Maybe there is a way to do the same thing with Python, JavaScript, etc... But maybe that person rather use AutoHotkey or the language syntax instead.

That a ported version of AutoHotkey understand various scripts, or uses some of the syntax or commands used by the Windows version, doesn't mean it has to be 100% compatible or use C++/C. I mentioned this, because that is what I interpret that Polyethene was showing with IronAHK and C#, in reading the old forum posts (https://autohotkey.com/board/topic/3148 ... mac/page-3). Things like "A cross platform abstract class with support for X (written by Tobias92) will be included after the syntax engine is complete." (https://autohotkey.com/board/topic/3148 ... mac/page-4). However, in his case, he was seeking as much compatibility as possible with the official AutoHotkey version, where I'm saying that doesn't have to be the goal or point of different developers. What Polyethene did with C#, could be what someone does with Java. I'm not trying to rain on anyone's parade. Even if it "must be done" with C++/C and doesn't have all the options of the Windows version, it could still be usable to various people.

If a person feels that AutoHotkey can only be C++/C and on Windows, not trying to change their mind. Just stating that others can believe differently or see AutoHotkey more in terms of the language and syntax used as opposed to the programming language the source code was made in. I'm sure there are many other AutoHotkey users like magicinmath, that hope AutoHotkey was on other OSes. How to do get it on other OSes or no desire to see it on anything but Windows, could be a matter of opinion or preference. Both views are fine by me.

Re: Android Applications

Post by nnnik » 11 Sep 2018, 02:31

No the part about needing to use C++ or C anyways.

Re: Android Applications

Post by SOTE » 11 Sep 2018, 02:22

nnnik wrote:SOTE did you understand what i wrote the last time?
Was responding to the AHK_fan post, about B4X. Didn't mention or comment about your post.

It's understood that developers are needed.

Re: Android Applications

Post by nnnik » 11 Sep 2018, 01:26

SOTE did you understand what i wrote the last time?

Re: Android Applications

Post by SOTE » 11 Sep 2018, 00:49

Ahk_fan wrote:hello,
if you want program an android without java eg, use Basic4android (b4a). Its very simple, cheap and powerfull with a great community. You can also download a trial version and test. I'm using it since 2011 ans i'm very happy.

regards
AHK_fan
AHK_fan, looking at B4a and it's related versions, B4i (iOS) and B4j (for desktop applications, is in the area of what I was referring to. However, this method does appear to be using Java (via Java JDK). But even if B4X is using Java behind the scenes, the way AutoHotkey uses C++ or IronAHK was using C#, the point is about the same. Using the alternative language as a way to make things easier, faster, or use shortcuts to get the job done.

Note- Lazarus appears to be an open source alternative to B4X, but they use the Pascal programming language. It too can compile programs for multiple OSes, to include Android.

Debatably, C++ doesn't have to be the language that AutoHotkey commands and syntax are built on top of. That is what IronAHK has at least showed. It could be that the AutoHotkey "language" is on top of .NET or Java. C++ could possibly be used for both Android and iOS, but it seems not as a well supported or as a popular path, though that might not be such a hindrance to some.

Re: Android Applications

Post by nnnik » 09 Sep 2018, 06:30

We would need more developers for this.

Top