Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mobile support (android, ios) #547

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

roman-kruglov
Copy link
Contributor

@roman-kruglov roman-kruglov commented May 31, 2022

Description

Made with fyne - a terminal emulator which supports text selection and copying; for mobile platforms. Also respects dark and light themes. If you remove the theming code - the terminal is only 65 lines long. Note: it doesn't need any manifests - fyne enables networking / internet access by default.

Shout-out to @zlaya-sobaka for their repo https://github.com/zlaya-sobaka/db1000n_mobile which was an inspiration.

How to build

go get github.com/fyne-io/fyne-cross
go get fyne.io/fyne/v2/cmd/fyne

then fyne install or go install fyne.io/fyne/v2/cmd/fyne

Then have Java SDK and NDK installed (or just extracted somewhere) and make sure NDK_HOME is properly set. To build for all possible android devices you need an NDK with android16 compilers (at least fyne demanded them from me) - like r19, but I bet there are newer versions which have those too. The newest version of NDK doesn't. But it is also possible to limit cpu architectures and not build all possible variants.

Then just run fyne package -os android -appID com.some.id and you get an .apk file which you just send or upload to any android device and install.

It is also possible to build a release build with fyne release and have it published to PlayStore, but I doubt they will pass it there. Building for IOS is possible too, but I didn't try it yet (described here https://developer.fyne.io/started/mobile).

Type of change

  • New feature (non-breaking change which adds functionality)

TBD

  • Limit the maximum amount of text logs displayed not to overflow memory
  • Maybe not modify terminal's text when some of it is selected

job.NewRunner(runnerConfigOptions, jobsGlobalConfig, reporter).Run(ctx, logger)
runner := job.NewRunner(runnerConfigOptions, jobsGlobalConfig, reporter)

if mobile.IsMobile {
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would suggest to use another main_mobile.go to start a runner. In this case it even simpler to do it in separate repo and use 1000n as a dependency, as @arriven proposed before.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so you would copy all main's content to it as well?.. imo it's not robust. Or how would you use this main's content? Is it possible to run it as a plain function inside another main?

Initially I tried having an all contained file with init() which runs everything without any need to modify main, but unfortunately fyne doesn't allow running its main loop not in the main thread.

Copy link

@ghost ghost Jun 2, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about moving generic part of main to some API-like function, and then call it from other projects like a mobile app? I'm ok with mobile app be a part of main repo, but @arriven said that it is hard to support for him.

Copy link
Contributor Author

@roman-kruglov roman-kruglov Jun 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case you don't need to support anything - no manifests, no stuff - just a bit of code which introduces something where to show the output. And you just build it for androids (and ios, but I didn't test that).

Anyway, even if a separate repo is to be pursued, we would need to make changes similar to turning the whole app into a "lib" and then having main.go just plug and run it. @arriven are you ok with that? would it still be preferable?

P.S. I personally would prefer to just have another build artifact with each release, it would guarantee there will be fresh releases as long as this project is alive. And just imagine the potential wider number of users. Otherwise imo it's pretty likely the "mobile" repo will die as several already made attempts did - like the reference one, https://github.com/zlaya-sobaka/db1000n_mobile.

But it's not up to me, so if this code helps somebody - great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant