-
Notifications
You must be signed in to change notification settings - Fork 250
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
Add initial gomobile support #1164
Conversation
Codeclimate doesn't like duplication in |
Makefile
Outdated
@@ -171,7 +164,11 @@ xgo: | |||
docker pull $(XGOIMAGE) | |||
go get github.com/karalabe/xgo | |||
|
|||
setup: dep-install lint-install mock-install ##@other Prepare project for first build | |||
gomobile: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gomobile-install
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make sense, thanks!
mobile/response.go
Outdated
@@ -0,0 +1,64 @@ | |||
package status |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can either move it to types.go
or change it to jsonrpc_response.go
.
It's an issue that we have so many response types but this one was introduced for bindings that are meant to replace JSON-RPC calls. In status-react, commands like eth_sendTransaction
are intercepted and a binding is called instead. Thanks to this type of response, the response can be easily returned without further processing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
comments are mostly irrelevant, but what is the thread situation in code generated by gomobile? as I remember we are using a thread pool in objective-c and java, and application seems to depend on it
return makeJSONResponse(err) | ||
} | ||
|
||
api.RunAsync(func() error { return statusBackend.StartNode(config) }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not really related to this PR. but it seems that RunAsync is totally unnecessary, every call is executed in its own thread. so, for example, StartNode can return an actual error, instead of using signals to report that error. and that means - part of the signals are not useful at all. and the other part of signals can be a simple a subscription over RPC.
mobile/status.go
Outdated
var statusBackend = api.NewStatusBackend() | ||
|
||
// All general log messages in this package should be routed through this logger. | ||
var logger = log.New("package", "status-go/lib") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you want to keep the name of logger (lib part)?
) | ||
errString := "" | ||
|
||
defer func() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this defer usage is so confusing. it definitely should be a simple function that accepts error and returns string
@dshulyak answering your comments here in bulk: this PR is "drop-in" replacement, I want to change as little as possible in the original implementation. So I guess the followup PR will be a rethinking the interface between status-go and react with gomobile in mind, and most of your comments will be for sure resolved there. I'm not quite sure I understood the thread pool issue. Can you elaborate on it? |
@divan so both versions of the app are running on a thread pool. but recently there were performance issues on android. after investigation it turned out that pool size was too small. i think it was set to the number of cpu cores (or a double of that). raising number of threads helped. i don't know details of those performance problems, but in current implementation there must be a peer pool in andoid/ios bindings. otherwise app won't work. cc @pombeirp in case he wants to provide more details |
From a quick test, it seems that there are some open questions:
If we collectively decide that it is not absolutely required to be able to cross-compile iOS/MacOS libraries, then I'd definitely get rid of xgo, as otherwise I don't see much advantage in bringing gomobile to the equation. |
Pull Request Checklist
|
Thanks for feedback @pombeirp. So let's breakdown the problems we have:
Is that correct? Regarding the Android NDK: I had an assumption that |
Yeah, that's correct. Although I'm quite sure that XCode doesn't run on anything but a Mac. When you mentioned the PR was ready for testing on the react side (pending being able to build status-react), I thought you had already tested the two types of builds to confirm that the libraries were generated correctly, but if I understand correctly, that still remains to be done, right? |
As future context: I'm currently working on another PR which is meant to provide status-go static library artifacts to Status Desktop builds. I'm running into issues consuming the cross-compiled OSX library, so I'm starting to think that with the move to |
I'm trying to make manual build with
@divan is there any instructions on how to build it? |
This branch is just outdated as some packages in status-go changed. |
I pushed the commit with rebase, please try now. |
Failing:
https://ci.status.im/job/status-go/job/status-go-manual/545/console |
@dmitryn hmm, so Makefile should have |
@divan I've added
|
@dmitryn that's because |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
d7b5267
to
49b3335
Compare
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Signed-off-by: Jakub Sokołowski <jakub@status.im>
android: works |
iOS: works. |
thanks @divan for starting it! |
This PR adds initial "drop-in" gomobile support for status-go.
"Drop-in" means it's supposed to be used as a replacement to the current xgo-based
lib
package. I.e. generated.aar
/.framework
files should be absolutely the same and require no modification fromstatus-react
in order to work.Important changes:
make setup
statusgo-ios
andstatusgo-android
to use gomobile instead of xgoJenkinsfile-manual
Closes #680