The Objective-C bindings was recently changed to support the empty
name prefix and to use that as the default. This CLs changed the Java
generators in the same way, supporting the empty Java package and using
it as the default.
Change-Id: I857affce686c67638a2b6c4e1da5d6a88d7ba560
Reviewed-on: https://go-review.googlesource.com/34778
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Before this CL, the type of the implicit "this" parameter to Java methods
implemented in Go could only be a super class of the generated Java
class. For example, the following GoRunnable type is an implementation of
the Java interface java.lang.Runnable with a toString method:
package somepkg
import "Java/java/lang"
type GoRunnable struct {
lang.Runnable
}
func (r *GoRunnable) ToString(this lang.Runnable) string {
...
}
The "this" parameter is implicit in the sense that the reverse generator
automatically fills it with a reference to the Java instance of
GoRunnable.
Note that "this" has the type Java/java/lang.Runnable, not
Java/go/somepkg.GoRunnable, which renders it impossible to call Java
methods and functions that expect GoRunnable. The most practical example
of this is the Android databinding libraries.
This CL changes the implicit this parameter to always match the exact
type. In the example, the toString implementation becomes:
import gopkg "Java/go/somepkg"
func (r *GoRunnable) ToString(this gopkg.GoRunnable) string {
...
}
One strategy would be to simply treat the generated Java classes
(GoRunnable in our example) as any other Java class and import it
through javap. However, since the Java classes are generated after
importing, this present a chicken-and-egg problem.
Instead, use the newly added support for structs with embedded prefixed types
and synthesize class descriptors for every exported Go struct type.
Change-Id: Ic5ce4a151312bd89f91798ed4088c9959225b448
Reviewed-on: https://go-review.googlesource.com/34776
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Since generated names now have their package names prefixed, the
extra prefix, "Go", is both confusing and counter-productive to
making the generated ObjC code look like any other native code.
Change the default to the empty prefix, while preserving support
for an explicit prefix if needed.
This is a backwards incompatible change; to keep the old behaviour,
specify "-prefix Go" to the gobind or gomobile command.
While we're here, fix the Ivy example for the recent change in
error returns.
Change-Id: I7fef4a92a18ddadee972ccf359652e3b31624f33
Reviewed-on: https://go-review.googlesource.com/34643
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Update outdated documentation and add documentation and references
for the the new reverse binding support.
Add a new example, reverse, that demonstrates how to use Android
API directly from Go and thereby implement an Android app in pure
Go.
Change-Id: Iac054dbc015d00a37c0cc234931f9bd90172848e
Reviewed-on: https://go-review.googlesource.com/31170
Reviewed-by: David Crawshaw <crawshaw@golang.org>
The Java methods names were recently changed to lowercase, but the
examples weren't updated. Fix that.
While we're here, comment out the GOPATH and GO settings from
the Go build.gradle file. They're confusing for the newcomer and only
needed in the rare case where GOPATH is wrong or missing or if go is
not in PATH.
Change-Id: Ib795b440a0127c402e56b70529f6bd71c6f1322b
Reviewed-on: https://go-review.googlesource.com/29594
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Since nothing about this high-level player will stay the same after
the audio work core types are finalized, there is no good point in
keeping the naive implementation around.
Removing also the audio example.
Updates golang/go#9551.
Change-Id: I5a7666c77e043aeacf44356e20e8d90822fd78e7
Reviewed-on: https://go-review.googlesource.com/27671
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Run-TryBot: Jaana Burcu Dogan <jbd@google.com>
Before this CL, generated Java classes or interfaces were inner
classes to the top package class. That is both unnecessary and creates
ugly class names. Instead, move every generated class and interface to its
own package level class.
NOTE: This is a backwards incompatible change and requires every client
of gomobile APIs to be updated to leave out the package class in the
type names. For example, the Go type
package pkg
type S struct {
}
now generates (with the default java package name go) a Java class named
go.pkg.S. The name before this CL was go.pkg.Pkg.S.
Also, change the custom java package to specify the package prefix and
not the full package as before. This is an unfortunate change needed
to avoid name clashes between two bound packages. On the plus side,
the change brings the custom package case closer to the default behaviour,
which is a commen prefix, "go.", and a distinct java package for every
Go package bound.
Change-Id: Iadfaad56e101d1caf7e2a05006f4d384859a20fe
Reviewed-on: https://go-review.googlesource.com/27436
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Additional '=' was added after '&',
but 0 != (a &= b) is still valid in java
Change-Id: I9c7b524941e0553c9fc5095adc5fc7819c4823b0
Reviewed-on: https://go-review.googlesource.com/23950
Reviewed-by: David Crawshaw <crawshaw@golang.org>
For golang/go#15554
Also update app target sdk api to 23.
Change-Id: Id66b17b4388703e9806cc50def554b3c58606e24
Reviewed-on: https://go-review.googlesource.com/23690
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Reviewed-by: Elias Naur <elias.naur@gmail.com>
Also
- include a properties file for org.golang.mobile.bind.canary
which is used to canary before release.
- update example/bind/android gradle config.
Change-Id: I1dd0ff94a772b287a2f9be1a915ea72b1c3b0d52
Reviewed-on: https://go-review.googlesource.com/23678
Reviewed-by: David Crawshaw <crawshaw@golang.org>
That supports GOARCH property.
Also this CL updates examples and upgrades the android gradle plugin
used in examples (from 1.2.3 to 1.5.0)
For golang/go#12819
Change-Id: Ibfed128eaf725775810aa539bd5c0e1ca88f1b85
Reviewed-on: https://go-review.googlesource.com/20331
Reviewed-by: David Crawshaw <crawshaw@golang.org>
from 0.2.2 to 0.2.3
Change-Id: I906200acf9615c8cc100b7d1ad5592e899e383fe
Reviewed-on: https://go-review.googlesource.com/19409
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Andrew's new example/flappy does a better job of demoing off these
packages, and I would like to keep our example count under contorl.
Change-Id: I77f4da78815055ab91510ce0cb97bbd7ac1bac3b
Reviewed-on: https://go-review.googlesource.com/18381
Reviewed-by: Andrew Gerrand <adg@golang.org>
This game was developed for and presented at GoCon Winter 2015 in Tokyo.
Change-Id: I08148e16a54355b79f634dce867b3c3c0a0153cb
Reviewed-on: https://go-review.googlesource.com/18245
Reviewed-by: Nigel Tao <nigeltao@golang.org>
A paint.Event now has an External field. Whenever a paint event is
sent by the x/mobile/app package, it is marked as external so users
with an active paint loop can ignore them.
Implemented on OS X and Android, with examples updated.
Change-Id: Ibee8d65625c8818ff954936be48257ad30daa147
Reviewed-on: https://go-review.googlesource.com/15480
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
The current example 2**(2+3) yields the same result as not using
parenthesis. The "grouped differently" example should use (2**2)+3
so that it yields a different result.
Change-Id: If5f63ec03adba4402c51822d6c13646a26384730
Reviewed-on: https://go-review.googlesource.com/14960
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
The package-level OpenGL calls in golang.org/x/mobile/gl were removed.
This change fixes the example sprite app to use their replacement.
Change-Id: I1884e9292133375194c963e71540acaef0908d66
Reviewed-on: https://go-review.googlesource.com/15051
Reviewed-by: David Crawshaw <crawshaw@golang.org>
All OpenGL functions are now methods on a Context interface. The
gl.Context matches the one loaded into thread-local storage in C.
For mobile apps, the context is owned by an app.App. For now, it is
provided through the events channel on a lifecycle event. Long-term,
it should probably be available by a method on app.App, but this is
inherently racey with our current use of a channel to deliver events.
Shiny-based programs will have a gl.Context associated with a each
shiny.Window. The expectation is each Window will have different
contexts, allowing them to draw separately.
Change-Id: Ie09986fb74e493129f2ea542a151c95c6fa29812
Reviewed-on: https://go-review.googlesource.com/13431
Reviewed-by: Nigel Tao <nigeltao@golang.org>
It is now the user's job to track the lifetime of a glutil.Image
relative to a (currently implicit, soon to be explicit) GL context.
This is an attempt to move glutil.Image closer to the model for
buffers and textures in shiny. Long-term, I would like to adopt that
model, and this is a step in that direction. It also makes the
introduction of *gl.Context possible, so this is a pre-req for
cl/13431.
Change-Id: I8e6855211b3e67c97d5831c5c4e443e857c83d50
Reviewed-on: https://go-review.googlesource.com/14795
Reviewed-by: Nigel Tao <nigeltao@golang.org>
More than a name change, the painting model changes so that the app, not
the library, is responsible for driving painting. If the app is
animating and wants paint events at 60 Hz, it has to ask for that. If
the app is not animating and doesn't need to update its screen, it
shouldn't get any paint events.
Plenty of TODOs, and this CL doesn't get us to a perfect place, but it
is a checkpoint along the way.
The darwin_*.go code changes were minimal. I don't even have a Mac or
iOS device to test that this even builds. Even so, the TODOs about not
sending paint.Events unconditionally are important TODOs. That's the
whole point of switching to this model. I'll leave the actual
implementation to you (crawshaw).
Out of all the example apps, the change to example/network/main.go is
probably the most interesting.
It seems like there ought to be some way to reduce the copy/paste
between all of the example app code, but I'll leave that for future CLs.
Change-Id: I17e11c06174110c68e17f7183b2d8af19b6a170e
Reviewed-on: https://go-review.googlesource.com/14300
Reviewed-by: David Crawshaw <crawshaw@golang.org>
1) Clear button did not shrink the WebView size. It's an old bug in
Android WebView, and fixed recently (android-L, maybe). This CL avoids
the problem by replacing the webview with a freshly allocated new webview
object. It's heavy-weight, but the Clear event should be rare.
2) ScrollToBottom from the java side and the java script side interacted
strangely and prevented long results from displayed properly.
Also,
- now the gomobile bind generates the Java class in the
org.golang.ivy package. (ivy/build.gradle)
- modified the javascript in tape.html so long result texts are not
shortened initially. (tape.html)
Change-Id: I60660f3392cf17719daad4af89e05c2d82788175
Reviewed-on: https://go-review.googlesource.com/14201
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This version is not yet released to Play store.
Compared to the version in the play store
- fixed the reappearing keyboard bug
- allows app install on SD card
- when demo is enabled, the demo mode message is displayed
- when demo is enabled, the submit action button appears next to the
edit text.
- use robpike.io/ivy/mobile instead of the wrapper in my personal repo.
- the demo script read code was moved from go to java.
- use the up-to-date help message retrieved with mobile.Help.
- textview was replaced with webview with javascript.
TODO: the app built from this code doesn't work in old android devices.
Next cl will fix it.
TODO: build instruction - not very different from
golang.org/x/mobile/example/bind/android.
Change-Id: Ifb594b79f31091b6864ec3e0d8dbaff7986a5afc
Reviewed-on: https://go-review.googlesource.com/13870
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Higher-level widget or animation libraries should probably work in
geom.Pt, but pixels instead of (1/72s of) inches seems a better fit for
lower-level event libraries. Needlessly converting from (float32) pixels
to (float32) points and back can be lossy and lead to off-by-one errors.
Change-Id: I68102e36f2574b07b44c6a1b7281f4f27f9174cf
Reviewed-on: https://go-review.googlesource.com/13002
Reviewed-by: David Crawshaw <crawshaw@golang.org>
Regenerating the package from Xcode is not required, demo
should focus on building with a .framework bundle.
Removing the genhello.bash invoking build step to fix the Xcode
builds.
Change-Id: I793b7e1f5373a287432a0a605df0bde54b1daa84
Reviewed-on: https://go-review.googlesource.com/13036
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
windows and other non-mobile os support is not there yet.
Change-Id: Ie9c456b646bfa0b0c489e1b6344b5afca4801c5f
Reviewed-on: https://go-review.googlesource.com/12744
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This change allows the example/network from gomobile to compile
correctly.
Change-Id: Id0f722796e0224ec4a7c06b163a25a4f3a5fbcb3
Reviewed-on: https://go-review.googlesource.com/12471
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
