FAQ
I'm following up on this GitHub
thread: https://github.com/golang/go/issues/15737

Basically, GoMobile binaries are always rendered in an 800x800 window. The
window can be resized, but only manually, not through code. Apparently,
the 800x800 value is hard coded. Is there a reason for this, or is there an
opportunity for a patch that will allow users to modify the window size so
it can be easily set to common mobile device sizes?

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Daniel Skinner at Jun 8, 2016 at 3:35 am
    Is there a reason for this, or is there an opportunity for a patch that
    will allow users to modify the window size so it can be easily set to
    common mobile device sizes?

    I doubt there's a reason for it, but what would it be changed to?

    As far as user supplied dimensions, I can't really speak up on that. From
    what I've seen, there's a lot of overlap between exp/shiny and gomobile and
    I wouldn't be surprised to see all the windowing stuff in gomobile defer to
    exp/shiny in the future where, if i remember correctly, a user can supply
    window size hints. But, I'm only speculating.
    On Mon, Jun 6, 2016 at 6:51 PM Andy Brewer wrote:

    I'm following up on this GitHub thread:
    https://github.com/golang/go/issues/15737

    Basically, GoMobile binaries are always rendered in an 800x800 window. The
    window can be resized, but only manually, not through code. Apparently,
    the 800x800 value is hard coded. Is there a reason for this, or is there an
    opportunity for a patch that will allow users to modify the window size so
    it can be easily set to common mobile device sizes?

    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at Jun 10, 2016 at 2:45 am

    On Tue, Jun 7, 2016 at 9:38 AM, Andy Brewer wrote:
    Basically, GoMobile binaries are always rendered in an 800x800 window. The
    window can be resized, but only manually, not through code. Apparently, the
    800x800 value is hard coded. Is there a reason for this, or is there an
    opportunity for a patch that will allow users to modify the window size so
    it can be easily set to common mobile device sizes?
    The x/mobile repo is meant for apps that run on mobile devices: phones
    and tablets. Unlike desktop apps, mobile apps (whether written in Go
    or not) generally don't have a say in what their window size will be,
    as they generally run full-screen, and screens have different sizes.
    Even Apple devices have different aspect ratios. Accordingly, a good
    mobile app's UI should be usable in a range of window sizes, so I am
    hesitant to add an API feature that encourages building a
    pixel-perfect UI for one specific window size.

    I'd consider a patch that changed the hard-coded value to a more
    phone-like aspect ratio instead of 1:1. Maybe 4:3 or 5:3 or 3:2 or
    16:9 but as you can see there are multiple bike-shedding options and
    no single one is obviously 'correct'.

    If you must change this for your own workflow, and you're on a Mac,
    you want to change the
    NSRect rect = NSMakeRect(0, 0, 400, 400);
    line in x/mobile/app/darwin_amd64.m. The doubling from 400 to 800 is
    done by the OS, because you're presumably on a Retina display.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andy Brewer at Jun 13, 2016 at 6:53 pm
    I agree that good mobile UI should be responsive. I'm thinking this feature
    would be useful for testing your app on those wide range of mobile screen
    sizes. Right now, it's difficult to test apps made with gomobile because
    the viewport needs to be resized manually to see all the content.

    1. Would it be realistic to pass a flag like: gomobile build -target=ios
    -viewport=1125x2001 golang.org/x/mobile/example/basic
    2. Or, could we enable an API where developers could use /pkg/flag to
    enable flags on the mobile binary itself and adjust the
    viewport programmatically like: ./myNewMobileApp -viewport=1125x2001

    I've heard of several people running into this problem trying to test
    GoMobile apps. If there's another, easier way to run test the UI on
    gomobile apps, then we might need to just educate the community on best
    practices there.


    On Thu, Jun 9, 2016 at 7:45 PM Nigel Tao wrote:
    On Tue, Jun 7, 2016 at 9:38 AM, Andy Brewer wrote:
    Basically, GoMobile binaries are always rendered in an 800x800 window. The
    window can be resized, but only manually, not through code. Apparently, the
    800x800 value is hard coded. Is there a reason for this, or is there an
    opportunity for a patch that will allow users to modify the window size so
    it can be easily set to common mobile device sizes?
    The x/mobile repo is meant for apps that run on mobile devices: phones
    and tablets. Unlike desktop apps, mobile apps (whether written in Go
    or not) generally don't have a say in what their window size will be,
    as they generally run full-screen, and screens have different sizes.
    Even Apple devices have different aspect ratios. Accordingly, a good
    mobile app's UI should be usable in a range of window sizes, so I am
    hesitant to add an API feature that encourages building a
    pixel-perfect UI for one specific window size.

    I'd consider a patch that changed the hard-coded value to a more
    phone-like aspect ratio instead of 1:1. Maybe 4:3 or 5:3 or 3:2 or
    16:9 but as you can see there are multiple bike-shedding options and
    no single one is obviously 'correct'.

    If you must change this for your own workflow, and you're on a Mac,
    you want to change the
    NSRect rect = NSMakeRect(0, 0, 400, 400);
    line in x/mobile/app/darwin_amd64.m. The doubling from 400 to 800 is
    done by the OS, because you're presumably on a Retina display.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at Jun 16, 2016 at 12:40 am

    On Tue, Jun 14, 2016 at 4:53 AM, Andy Brewer wrote:
    I agree that good mobile UI should be responsive. I'm thinking this feature
    would be useful for testing your app on those wide range of mobile screen
    sizes. Right now, it's difficult to test apps made with gomobile because the
    viewport needs to be resized manually to see all the content.
    If the viewport needs to be resized to see all the content, that
    doesn't sound like a responsive UI. Again, that's not something I'd
    like to encourage.

    If you really just need to embiggen the window, it should be
    straightforward to assign a system-level keyboard shortcut to maximize
    or zoom the window.

    1. Would it be realistic to pass a flag like: gomobile build -target=ios
    -viewport=1125x2001 golang.org/x/mobile/example/basic
    I don't understand the suggestion. If you're building for -target=ios
    then iOS isn't an environment where an app can choose its window size.

    2. Or, could we enable an API where developers could use /pkg/flag to enable
    flags on the mobile binary itself and adjust the viewport programmatically
    like: ./myNewMobileApp -viewport=1125x2001
    Flags belong in apps (package main) and not libraries (package
    notmain). If anything, yes, your "package main" code is free to define
    its own flags, and we'd need some API, probably an additional argument
    to app.Main. But I'm not convinced yet that there's a need.

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nigel Tao at Jun 16, 2016 at 3:07 am

    On Fri, Jun 10, 2016 at 12:45 PM, Nigel Tao wrote:
    I'd consider a patch that changed the hard-coded value to a more
    phone-like aspect ratio instead of 1:1. Maybe 4:3 or 5:3 or 3:2 or
    16:9 but as you can see there are multiple bike-shedding options and
    no single one is obviously 'correct'.
    I have sent out https://go-review.googlesource.com/24143

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andy Brewer at Jun 17, 2016 at 5:23 pm
    Thanks. I'm wondering how I can test my UI efficiently with gomobile. So,
    I will create a responsive design as you recommend, but I still want to
    test my app at explicit screen sizes to mimic the actual user experience,
    rather than approximate it.

    The use case is someone who wants to support iPhone 4 and up. Most
    designers would want to test their UI against the actual screen size of the
    iPhone 4, 5, 6 and 6+, even if the UI is built to be fully responsive in
    between those sizes. Right now, to my knowledge there's not an easy way to
    do that.

    Also, Android best practices does recommend as an option creating a unique
    UI/layout for each screen size you want to support (
    https://developer.android.com/guide/practices/screens_support.html#support "How
    To Support Multiple Screens"). If I'm following that option, I'd want to be
    able to easily launch my application at different screen sizes to test my
    screen-specific code.

    Developers might also want to send screenshots to their clients, like:
    http://designbump.com/wp-content/uploads/2013/10/Flat-iPhone-Mock-Up-Display.jpg
    .

    If we could expose the height/width to the API, it would solve these issues.

    Another option would be to simply launch the app inside an emulator, but
    I'm not sure if there's an easy way to do that. Plus, the refresh rate on
    launching emulators is usually pretty bad.

    Andy
    On Wed, Jun 15, 2016 at 8:07 PM Nigel Tao wrote:
    On Fri, Jun 10, 2016 at 12:45 PM, Nigel Tao wrote:
    I'd consider a patch that changed the hard-coded value to a more
    phone-like aspect ratio instead of 1:1. Maybe 4:3 or 5:3 or 3:2 or
    16:9 but as you can see there are multiple bike-shedding options and
    no single one is obviously 'correct'.
    I have sent out https://go-review.googlesource.com/24143
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Daniel Skinner at Jun 17, 2016 at 6:04 pm
    but I still want to test my app at explicit screen sizes
    testing on actual hardware is still going to be the best, but I'd imagine
    there's something out there for OSX that'd let you specify the exact window
    size (of any window open).
    Also, Android best practices does recommend as an option creating a
    unique UI/layout for each screen size you want to support

    I'd say that recommendation is more of a state-of-current-affairs than an
    actual ideal. Simply due to how things have been, it's generally easier to
    maintain multiple xml layout files behind different resource flags. None of
    that will even be available to you so you should be looking at more generic
    best practices. For example, consider
    https://material.google.com/layout/responsive-ui.html
    Developers might also want to send screenshots to their clients [...] Another
    option would be to simply launch the app inside an emulator

    There's nothing prohibiting either. Here's an old screenshot from something
    I put together that was running on an emulator and used the screenshot util
    from android studio to frame it: http://i.imgur.com/M5Jj6hJ.png
    On Fri, Jun 17, 2016 at 12:23 PM Andy Brewer wrote:

    Thanks. I'm wondering how I can test my UI efficiently with gomobile. So,
    I will create a responsive design as you recommend, but I still want to
    test my app at explicit screen sizes to mimic the actual user experience,
    rather than approximate it.

    The use case is someone who wants to support iPhone 4 and up. Most
    designers would want to test their UI against the actual screen size of the
    iPhone 4, 5, 6 and 6+, even if the UI is built to be fully responsive in
    between those sizes. Right now, to my knowledge there's not an easy way to
    do that.

    Also, Android best practices does recommend as an option creating a unique
    UI/layout for each screen size you want to support (
    https://developer.android.com/guide/practices/screens_support.html#support "How
    To Support Multiple Screens"). If I'm following that option, I'd want to be
    able to easily launch my application at different screen sizes to test my
    screen-specific code.

    Developers might also want to send screenshots to their clients, like:
    http://designbump.com/wp-content/uploads/2013/10/Flat-iPhone-Mock-Up-Display.jpg
    .

    If we could expose the height/width to the API, it would solve these
    issues.

    Another option would be to simply launch the app inside an emulator, but
    I'm not sure if there's an easy way to do that. Plus, the refresh rate on
    launching emulators is usually pretty bad.

    Andy
    On Wed, Jun 15, 2016 at 8:07 PM Nigel Tao wrote:
    On Fri, Jun 10, 2016 at 12:45 PM, Nigel Tao wrote:
    I'd consider a patch that changed the hard-coded value to a more
    phone-like aspect ratio instead of 1:1. Maybe 4:3 or 5:3 or 3:2 or
    16:9 but as you can see there are multiple bike-shedding options and
    no single one is obviously 'correct'.
    I have sent out https://go-review.googlesource.com/24143
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andy Brewer at Jun 17, 2016 at 10:52 pm
    OK, so designers will want to quickly test their app at specific screen
    sizes. I think we just need to determine the best option because there
    doesn't seem to be a gomobile best practice.

    It sounds like we have the following options:
    1. Run a script to resize the window (
    http://www.labnol.org/software/resize-mac-windows-to-specific-size/28345/).
    Upside: Works with current codebase. Downside: no cross-platform solution,
    some solutions require extra clicks/typing, might need extra scripts for
    each size.
    2. Run the app inside an emulator. Upside: works with current codebase.
    full emulator control (wifi, settings, etc.). Downside: long testing
    cycles, 10s+ (noted as a problem the gomobile viewport is trying to solve:
    http://www.youtube.com/watch?v=ZLq0Zeoyu6Y&t=3m13s)
    3. Open up the API. Upside: developer control. Downside: Additional API
    complexity.

    In the David Crawshaw talk, it sounds like the purpose of the viewport is
    to not to replicate an emulator, but to improve the speed of the testing
    feedback cycle. As a designer, being able to control the height/width of
    the viewport would help me achieve that goal. We do the same thing with
    responsive web design. We build a responsive layout, and then use a browser
    extension to programmatically resize the browser to common screen
    resolutions.

    I know for me, this is actually a stumbling block that I researched online
    and found others having difficulty with as well. It would help a lot to
    have this feature, but I'm not familiar enough with the codebase or feature
    threshhold to understand the downside of adding it to the API.

    Andy
    On Fri, Jun 17, 2016 at 11:04 AM Daniel Skinner wrote:

    but I still want to test my app at explicit screen sizes
    testing on actual hardware is still going to be the best, but I'd imagine
    there's something out there for OSX that'd let you specify the exact window
    size (of any window open).
    Also, Android best practices does recommend as an option creating a
    unique UI/layout for each screen size you want to support

    I'd say that recommendation is more of a state-of-current-affairs than an
    actual ideal. Simply due to how things have been, it's generally easier to
    maintain multiple xml layout files behind different resource flags. None of
    that will even be available to you so you should be looking at more generic
    best practices. For example, consider
    https://material.google.com/layout/responsive-ui.html
    Developers might also want to send screenshots to their clients [...] Another
    option would be to simply launch the app inside an emulator

    There's nothing prohibiting either. Here's an old screenshot from
    something I put together that was running on an emulator and used the
    screenshot util from android studio to frame it:
    http://i.imgur.com/M5Jj6hJ.png
    On Fri, Jun 17, 2016 at 12:23 PM Andy Brewer wrote:

    Thanks. I'm wondering how I can test my UI efficiently with gomobile. So,
    I will create a responsive design as you recommend, but I still want to
    test my app at explicit screen sizes to mimic the actual user experience,
    rather than approximate it.

    The use case is someone who wants to support iPhone 4 and up. Most
    designers would want to test their UI against the actual screen size of the
    iPhone 4, 5, 6 and 6+, even if the UI is built to be fully responsive in
    between those sizes. Right now, to my knowledge there's not an easy way to
    do that.

    Also, Android best practices does recommend as an option creating a
    unique UI/layout for each screen size you want to support (
    https://developer.android.com/guide/practices/screens_support.html#support "How
    To Support Multiple Screens"). If I'm following that option, I'd want to be
    able to easily launch my application at different screen sizes to test my
    screen-specific code.

    Developers might also want to send screenshots to their clients, like:
    http://designbump.com/wp-content/uploads/2013/10/Flat-iPhone-Mock-Up-Display.jpg
    .

    If we could expose the height/width to the API, it would solve these
    issues.

    Another option would be to simply launch the app inside an emulator, but
    I'm not sure if there's an easy way to do that. Plus, the refresh rate on
    launching emulators is usually pretty bad.

    Andy
    On Wed, Jun 15, 2016 at 8:07 PM Nigel Tao wrote:
    On Fri, Jun 10, 2016 at 12:45 PM, Nigel Tao wrote:
    I'd consider a patch that changed the hard-coded value to a more
    phone-like aspect ratio instead of 1:1. Maybe 4:3 or 5:3 or 3:2 or
    16:9 but as you can see there are multiple bike-shedding options and
    no single one is obviously 'correct'.
    I have sent out https://go-review.googlesource.com/24143
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJun 6, '16 at 11:51p
activeJun 17, '16 at 10:52p
posts9
users3
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase