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 <dan...@dasa.cc> 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 <a...@ever.io> 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 <nigel...@golang.org> wrote: >> >>> On Fri, Jun 10, 2016 at 12:45 PM, Nigel Tao <nigel...@golang.org> 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
