Portal Aesthetics

[adyf]

I have the following portal on FM16 on my MacBook, which to all intents and purposes looks fine with regard to field size, alignment including borders etc.

But when I look at the same portal in FMGO, you can see that things don't look quite so neat with regard to the click button and the first two fields.

Everything looks ok in inspector with regard to field sizing and positioning etc.

Just wondering if there's an easy way to square all this up so the appearance is consistent on both platforms. Is it trial and error, I have had some success with other fields in sending them to the back and front etc but I'm struggling with these last three.

[bcooney]

The standard approach is to have a separate set of layouts for the iPad UI. You navigate accordingly to the correct set of layouts "world" in the file's startup script. You can use the Get functions to determine branching logic (borrowed from Matt Petrowski):

$$APP.ISWINDOWS = Abs ( Get(SystemPlatform) ) = 2;
$$APP.ISMOBILE = Get(SystemPlatform) = 3;
$$APP.ISIPAD = Patterncount ( Get (ApplicationVersion) ; "iPad");
$$APP.ISIPHONE = $$APP.ISMOBILE and not $$APP.ISIPAD

The reason? FMGo has different behavior than desktop. The hit zones must be larger, portals scroll bars are too narrow to be very useful. See the FMGo Development Guide

[Steve Martino]

I usually set up the peer to peer network when developing for iPad and iPhone so I can watch the changes in real time, rather than constantly putting the file on the device to check.

Also, most themes have a 'touch' version better suited to IOS devices.

But it is alot of trial and terror for sizing.

[adyf]

21 minutes ago, bcooney said:

The standard approach is to have a separate set of layouts for the iPad UI. You navigate accordingly to the correct set of layouts "world" in the file's startup script. You can use the Get functions to determine branching logic (borrowed from Matt Petrowski):

$$APP.ISWINDOWS = Abs ( Get(SystemPlatform) ) = 2;
$$APP.ISMOBILE = Get(SystemPlatform) = 3;
$$APP.ISIPAD = Patterncount ( Get (ApplicationVersion) ; "iPad");
$$APP.ISIPHONE = $$APP.ISMOBILE and not $$APP.ISIPAD

The reason? FMGo has different behavior than desktop. The hit zones must be larger, portals scroll bars are too narrow to be very useful. See the FMGo Development Guide

Thanks for your reply. That would be a lot of work to build seperate layouts for the iPad UI.

15 minutes ago, Steve Martino said:

I usually set up the peer to peer network when developing for iPad and iPhone so I can watch the changes in real time, rather than constantly putting the file on the device to check.

Also, most themes have a 'touch' version better suited to IOS devices.

But it is alot of trial and terror for sizing.

I have actually have it set peer to peer to see real time changes. I've had some success so far with a few fields, but struggling with the last few. I just didn't know if there was an easy way of doing this. But as bcooney pointed out, with different behaviour across both formats it doesn't appear that there is.

[Ocean West]

 make sure your using a theme designed for FMGo and all elements are saved into the theme,

Although it may seem duplicitous to have layouts for Desktop and FMGO or WD it is really the only way to go there are just some things that won't work the way you'll like on both platforms. 

 

[JerrySalem]

I find that in general layouts designed for GO or WebD always look fine on the desktop (not always true the the other way around!)

My default design paradigm is to always use the Touch themes even for desktop layouts.  This keeps the layout duplication to a minimum.

Keep in mind there are aways exceptions where you will have to have duplicate layouts for Go and Desktop based on other demands (or workflow).