OK, it sounds like it's more complicated than I thought to expose those screen dimensions to the API.
There are a good (and growing) number of designers like me who code and the gomobile tool is too barebones at the moment to be productive for testing UI across multiple screen size or horizontal vs. vertical orientation. Imagine a 1st person game that can only be played in landscape mode. Or, a game that shows more of the game world on larger screens. Or, a responsive design with a breakpoint between screen sizes. In those scenarios, you will end up resizing the window each time you test the UI. One nice thing about browsers is that they stay the same size you left them, so if you want to test a responsive layout at a particular dimension, you resize once and then can test as many times as you like at that screen resolution. That was the thought process behind giving the gomobile viewport control to the user. But I could see how adding this feature could become a slippery slope to requests for replicating other phone settings. I really like developing in Go and would love to test my business logic in the test suite and quickly test my UI in the viewport. It's much faster to than testing with a full blown emulator. One nice thing about React Native is the ability to startup an emulator once (at a specific screen size) and refresh to see your app update. I think if viewport control comes to gomobile, the testing speed with Go would rival that of React Native, which is a big reason a lot of people use it. I would much rather program my apps in Go than JavaScript, but if the UI testing cycle is cumbersome and involves extra steps, it makes React Native look like a more attractive option, just because of the tooling. Thanks for looking into this. On Tue, Jun 21, 2016 at 1:31 AM Daniel Skinner <dan...@dasa.cc> wrote: > In my experience, designers aren't writing code or demoing experiences in > native code. > > If they were, it wouldn't be that dissimilar to what I already see, either > resizing a window or choosing a specific window size in chrome dev tools. > > Put bluntly, designers just aren't affected here and I think the problem > your having has more to do with how barebones gomobile is at the moment. > > Allowing the window size change via the api is superficial and you would > quickly run into further hurdles. These hurdles are NOT invalid, they need > to be addressed, its just more complicated than the size of a window when > an app starts. > > It's something I know I'm actively investigating. It's something seeing > action in exp/shiny with a flexbox implementation. It's a hot topic to say > the least. And hopefully in the future there will be the tools available to > allow you to look at your app beyond a pixel perfect representation for a > specific mobile device, and as to something more, but for now "responsive > ui" and concessions on a 1:1 aspect ratio being a bit non sensical are > probably as good as it gets. > > Personally I think the solutions to these kinds of issues are purely > numerical and should be easy to adopt in any codebase. Do you already have > some sort of widget/ui library in the public? It might be more helpful to > see how a responsive approach there really blows concerns for different > sizes or a particular startup size away from concern. > > On Fri, Jun 17, 2016, 5:52 PM Andy Brewer <a...@ever.io> wrote: > >> 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.
