4c15c79e19
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>
Go support for Mobile devices
The Go mobile repository holds packages and build tools for using Go on mobile platforms.
Package documentation as a starting point:
The Go Mobile project is experimental. Use this at your own risk. While we are working hard to improve it, neither Google nor the Go team can provide end-user support.
This is early work and installing the build system requires Go 1.5. Follow the instructions on golang.org/wiki/Mobile to install the gomobile command, build the basic and the bind example apps.
--
Contributions to Go are appreciated. See https://golang.org/doc/contribute.html.
- Bugs can be filed at the Go issue tracker.
- Feature requests should preliminary be discussed on golang-nuts mailing list.