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 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/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.

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.

Re: Android Applications

Post by SOTE » 09 Sep 2018, 02:33

The additional point that I would like to add is that other programming and scripting languages have been able to make the jump to being cross-platform solutions. Python, .NET/C#, JavaScript, etc... It's more a matter of being a useful tool with common functionality and familiarity. The list of commands and functions don't necessarily have to be identical for each OS. It appears that IronAHK would have been able to be adapted to do various tasks on different OSes, which at the end of the day, that is all you can ask of a programming tool. It's the concept of having the scripting language being able to take more convenient shortcuts to getting something done, where it would take longer or be more difficult in the traditional programing language.

Afterall, we did have "Autohotkey for Pocket PCs / WinCE / Smartphones" at one time. (https://autohotkey.com/board/topic/2477 ... artphones/). I'm mentioning, in reference to people adapting Authhotkey for other platforms besides desktops.

The fact that we have Android and iOS smartphones, that Linux and the macOS exist, is not going anywhere. Particularly that Android is or is on the brink of being the number 1 OS in market share (https://mashable.com/2017/03/07/android ... Se8iEFWmqJ), and Google can leverage their mobile position and money to gain more market share on desktops. Tablets, Phablets, and mini PCs are hybrid solutions that can blur the lines between desktop and mobile. There could have been/or be an AutoHotkey solution to making tasks easier on other OSes, and which doesn't have to be an exact clone of what is done in Windows. Just saying, maybe there is nothing wrong with thinking outside of the box or keeping an open-mind about it. If not, it seems a bit sad and limiting.

Re: Android Applications

Post by Ahk_fan » 08 Sep 2018, 15:06

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

Re: Android Applications

Post by lexikos » 07 Sep 2018, 16:31

As far as I am aware, IronAHK was never targeted at Android. As for automation and hotkeys, I do not believe that Android shares any framework in common with Windows, Linux or OSX. I think the methods of automation it supports are totally different, because both the way the platform is designed and the way it is used are very different than the other OSes. I would be surprised to find that it even supports the concept of a global hotkey or a hook that can be used to create one.

Above all, I have no interest in developing anything for Android or using anything like AutoHotkey on Android.

Re: Android Applications

Post by nnnik » 07 Sep 2018, 10:05

Apologies on disagreeing, but from what I've read it appears things are changing or have changed. Definitively not saying there is anything wrong with Java, just that it appears not the only way to go. Companies are using JavaScript (not to be confused with Java) and C# to build applications for use on multiple OSes. For JavaScript there is Electron, Proton Native, Titanium, PhoneGap, Ionic, etc... "Write in JavaScript, run native everywhere". And C#, with Xamarin, has the weight and muscle of Microsoft behind it. Microsoft is making a hard and consistent push of their .NET framework on Android, iOS, Linux, and macOS.
Yeah I know but in the end it will get translated to Java or in the case of javascript use the built in javascript engine. You do not go against my point.
The point of IronAHK seems to have been: 1) expand the user base. Users not just on Windows, but on other OSes. "AHK Forever!" OK, maybe I got a little bit carried away, but you get my point. 2) To be able to put the AutoHotkey language and automation abilities to where it's needed. How many of us have Android phones and iPhones? In fact, if Google plays it's cards right, it might be able to eat up Microsoft market share on desktops too. Android tablets, laptops, and desktops are very viable options, which is probably why Microsoft has put MS Office on the Android and is giving away Visual Studio (Community version) and Xamarin to get more .NET developers. 3) Making a more useful tool. If the problem is solved with AutoHotkey, then it's as good as any other language that can be used. AutoHotkey has it's lane where it can be advantageous by it being strong in automation, macros, and shortcuts.
I told you why these specific languages are not the way to go for AHK - yet you reply with a response of their general advantages. Once again you do not disarm my point which weighs more than any argument you have made.

Top