<p>I have written an App in Golang. It has 3 components the cli containing the actual logic, the server querying/manipulating the data through calling the cli and then applying templates and the actual frontend. The cli and server are both in ~99% go, while the frontend is like 95% html. The server app runs the local server and executes an instance of Electron pointing to that server. Everything works wonderfully and this has allowed me to avoid JavaScript nearly completely.</p>
<p>Now if I want to publish the same app for Android what would I have to do? Is there any way to actually use the Golang backends in the project or do you have to rewrite the code into JS? I have seen gomobile in action but gomobile as far as I remember does not impelement packages like net/http or templates etc.</p>
<p>Cordova would only work (assuming I am using the normal go builds) if I host the backend apps on my server and let the user call them through URLs. That would work but this is a (pretty obviously) terrible way of solving the issue albeit a very fast one. Also it would heavily harm security having to store user data on an unrelated server.</p>
<hr/>**评论：**<br/><br/>mixedCase_: <pre><p>I see two probably viable options:</p>
<p>1) Use gomobile and write an native Android-specific UI (in a JVM language, although I believe using pure Go is possible). I have not heard of gomobile lacking the functionality you mentioned, but in that case you can supply it by writing SDK glue hidden behind a build tag.</p>
<p>2) Same as before, but your UI is a hybrid app. In other words, a simple WebView or similar rendering your HTML.</p></pre>fawa123: <pre><p>I would love to use option 2 since I already have written the HTML UI that is used by Electron. But I cannot think of a way to glue together sth like Cordova and the output produced by Gomobile. Also I assume I would have to write both the cli and server into one app right? So a rewrite (sort of) would still be needed.</p>
<blockquote>
<p>but in that case you can supply it by writing SDK glue hidden behind a build tag.</p>
</blockquote>
<p>Can you elaborate on this?</p></pre>mixedCase_: <pre><blockquote>
<p>Can you elaborate on this?</p>
</blockquote>
<p>Go build tags allow you to easily write code for only one platform (Android, in this case). If there's some desktop only functionality you can't use on mobile, but is provided in some way by the Android SDK or Java code, you can call it with the magic gomobile imports and hide it under a build tag; this way on the desktop your regular code runs there, but when compiling for Android, that code is ignored and the Java glue is compiled instead.</p></pre>mixedCase_: <pre><blockquote>
<p>But I cannot think of a way to glue together sth like Cordova and the output produced by Gomobile.</p>
</blockquote>
<p>You don't have to use Cordova. Cordova is at its core a native app with an embedded browser and a JavaScript API that exposes native APIs. You only need the first part, which you can easily write yourself in any Android-supported JVM language. From there you just hand it off to the Go part of the application (using the Java bindings generated by gomobile) to dictate what's going to be run in that embedded browser.</p>
<blockquote>
<p>Also I assume I would have to write both the cli and server into one app right? So a rewrite (sort of) would still be needed.</p>
</blockquote>
<p>You would need to decouple the CLI from your actual application. I believe one should always avoid coupling the external interface to the core logic for any non-trivial app, since this kind of stuff happens too often.</p></pre>fawa123: <pre><blockquote>
<p>I believe one should always avoid coupling the external interface to the core logic for any non-trivial app, since this kind of stuff happens too often. </p>
</blockquote>
<p>Yes that is what I am doing currently (for desktop) but I want to publish one app only (let's call it Test) and not force the user to first install "Test" and then tell them to go ahead install "Test-CLI" and "Test-Server" in addition just to be able to use "Test". </p>
<blockquote>
<p>You don't have to use Cordova.</p>
</blockquote>
<p>So if I got it right I shall create a native Java Android app that just has a Webbrowser component. That app runs the Golang functions in Java exported by Gomobile meaning I have to take the logic of the CLI and the Webserver and create a single library through gomobile containing both implementing the rest through Java. </p>
<p>One thing that bothers me is still left though. The like 5% JavaScript code I have is literally 100% Node code (executing/writing/reading files and changing the current URL). Any idea how I should work around this?</p>
<p>Sorry for my extensive questioning but I am new to Mobile devoplement and would really like to get this task done properly without having to waste lots and lots of money (/time) and then in the end failing.</p></pre>mixedCase_: <pre><blockquote>
<p>Yes that is what I am doing currently (for desktop) but I want to publish one app only (let's call it Test) and not force the user to first install "Test" and then tell them to go ahead install "Test-CLI" and "Test-Server" in addition just to be able to use "Test". </p>
</blockquote>
<p>Decouple the logic from the interface, but I didn't mean into two different applications. Or in other words, turn your application logic into a library. Example:</p>
<p>Imagine you're writing an e-mail client. When you hit "Send" a function is fired that gathers the account's secrets, the e-mail subject, recipient and body and starts talking SMTP to GMail (or whatever) servers, and if it succeeds/fails, displays a dialog box. Now you want to add a CLI interface, but that function reads the data it needs straight from a GUI, so you <em>decouple it</em>.</p>
<p>Now the function instead of gathering the necessary data by itself it receives it via parameters and returns an error (or nil) if it fails (or succeeds). Then you write a new function for each interface that gathers the correct data (like, GUI would take it from a text input, CLI would parse it from the command's arguments), calls the now decoupled function and does the relevant error handling (GUI uses the old dialog code, CLI uses stdout/stderr).</p>
<p>By doing this decoupling, you can have two binaries running different interfaces (desktop, mobile) but sharing the application logic.</p>
<blockquote>
<p>So if I got it right [...]</p>
</blockquote>
<p>If you go the pure native UI way, you can simply create gomobile bindings to you decoupled application logic and you call those functions from a JVM language.</p>
<p>If you go with embedded browser inside a native application, you'll have to bind the Go web server locally and point the WebView to the bound address so they can talk together.</p>
<blockquote>
<p>One thing that bothers me is still left though. The like 5% JavaScript code I have is literally 100% Node code (executing/writing/reading files and changing the current URL). Any idea how I should work around this?</p>
</blockquote>
<p>Don't do file management in your UI, do it in the Go code. As for changing the current URL... I guess you're doing it in things like native menus or right clicks, in which case you have to decide wether to do it on the website code or in the JVM side depending on what kind of interface trigger you're looking for.</p></pre>cjbprime: <pre><p>Search for the gomobile project, it lets you run Go code inside your Android app. Networking works.. but I would just rewrite that part in JS. You shouldn't be expecting pure golang mobile apps.</p></pre>fawa123: <pre><p>If I use gomobile to produce native Go apps then I may have a running and working server but no Webview. If I use Cordova I may have the Webview but not the Golang Logic. The question in this case is how I would be able to glue all this mess together. Also yes I did not knew that net/http and templates etc are implemented for gomobile.</p></pre>still_unregistered: <pre><p>You could use react native for the UI, it's mostly HTML (with a few changes) on the back, you have go and a bit of Java for gluing it together (a bit of JS is needed too).
I think there's a "webview" component for react native too (not sure though), so maybe you didn't have to re-do your UI at all.</p></pre>afghanPower: <pre><p>Would advise against a webview solution. Lag and stutter often makes it obvious that you're not running a native app.</p></pre>
