SmartGWT.Mobile with PhoneGap and iOS 9.1 landscape issue

[mark1]

SmartGWT.Mobile Release 2015-10-30
PhoneGap: 5.3.7
Cordova platform version: ios 3.9.2

When rotating the screen to landscape.. apps do not know where the bottom of the screen is and place items that are meant to be at the bottom of the screen like a “TabSet” outside of the visible area.

The app is generating a <meta name="viewport”> tag .. that includes “height=device-height” .. it appears that just like iOS v6 this needs to be removed.

I have attached screenshots of the showcase app showing this. (Though the good version looks slightly out of line because I didn’t include the statusbar plugin).

[Isomorphic]

First, a sanity check: are you aware that we now only recommend SmartGWT.mobile for certain niche situations? If you are starting on a new app, or even updating an existing app, you should revisit whether you want to maintain a separate mobile UI.

If you have a compelling reason to keep maintaining a separate mobile UI, what you can probably do in this case is add a second <meta> tag that overrides the automatic one.

[mark1]

Thank-you for your response, yes unfortunately I am aware. A large application was written well before SmartGWT.mobile use was discouraged, and I think would take a long time to convert.
It also it might be difficult to sell to management / users of the app who like the mobile appearance and controls like TabSets / TableViews / SwitchItems that as far as I know are not available in regular SmartGWT ?

Do you mean I should add another viewport programmatically? I tried just adding a second viewport to the html file, but it appears your code in "com.smartgwt.mobile.client.SmartGwtMobileEntryPoint" removes all viewport meta tags, before adding its own?

        final NodeList<Element> metaElems = Document.get().getElementsByTagName("meta");
        for (int ri = metaElems.getLength(); ri > 0; --ri) {
            final MetaElement metaElem = metaElems.getItem(ri - 1).cast();
            if ("viewport".equals(metaElem.getName())) {
                metaElem.removeFromParent();
            }
        }

[Isomorphic]

Perhaps too obvious to mention, but as you've discovered, you'll need to add your meta tag *after* the EntryPoint has run.

You didn't specify whether you have both a mobile and a desktop version of this application. Again, if there's a separate desktop version, we'd suggest stopping development of your mobile-specific version and focusing on having a single codebase. This will give you a much more capable mobile version of your application, which will be far less effort to maintain.

The controls you're looking for are available:
TabSet is the same as TabSet
TableView is just ListGrid
SwitchItem is just BooleanItem / CheckboxItem, or NativeCheckboxItem if you really really want the "switch" look.

[mark1]

No luck I am afraid. You have an 'OrientationChangeHandler' that keeps overwriting my "viewport".

We do have a desktop application, though because the data required by the mobile "app" is small in comparison to the main database. It is required to work fully offline with its own datastore and background synchronization when "online". So the requirement to maintain a separate portable version isn't going away soon.

 Page.[I]addOrientationChangeHandler[/I]([B]new[/B] OrientationChangeHandler() {
                  @Override
                  [B]public[/B] [B]void[/B] onOrientationChange(OrientationChangeEvent event) {
                      [B]final[/B] String newHeight = Page.[I]getOrientation[/I]() == PageOrientation.[B][I]LANDSCAPE[/I][/B] ? "device-width" : "device-height";
                      Page.[I]_updateViewport[/I](Float.[I]valueOf[/I](1.0f), "device-width", newHeight, Boolean.[B][I]FALSE[/I][/B], "minimal-ui");
                  }
  });

[Isomorphic]

OK, we'll take a look at whether Apple has made changes that require viewport tags to be messed with yet again..

You seem to be dead set on maintaining two UIs, but for completeness (and for others who might read this thread), you still have not pointed out any actual issue that would prevent having a single codebase.

The full version of SmartGWT has robust offline support - more robust in some ways than SmartGWT.mobile - and if you ported your offline capability to your SmartGWT application, you'd have the added benefit that people working on laptops would be able to work offline as well.

As far as having a smaller database - hopefully you didn't build separate data connectors into your mobile app (which is unnecessary even with a separate SmartGWT.mobile UI) and so this is just a matter of choosing to *load* less data up front on mobile, which is obviously something that can be done with a single UI codebase.

[tweediewr]

Hi Guys, we're two weeks on - any news on this issue ?? Thanks, Robin

[Isomorphic]

Hi,
sorry for the delay. We have been trying to find the cause for this behavior but, as far as we can see, there does not appear to be any viewport setting that actually corrects the problem. In fact, we have found a workaround where you do not need to specify viewport details, as default values are good, so you can even not add a viewport in the HTML.
The workaround consists of setting the style position to "FIXED" for the widget included as the child of RootLayoutPanel. For example, in the Showcase sample code, you should add this line:

tabSet.getElement().getStyle().setPosition(Position.FIXED);

So, the onDeviceReady() method should be now:

     @Override
      public void onDeviceReady() {
          RootLayoutPanel.get().add(tabSet);
          tabSet.getElement().getStyle().setPosition(Position.FIXED);
          final Element appLoadingPanelElem = Document.get().getElementById("appLoadingPanel");
          appLoadingPanelElem.getStyle().setOpacity(0.0);
          new Timer() {
              @Override
              public void run() {
                  appLoadingPanelElem.removeFromParent();
              }
          }.schedule(350);
      }

[dorin.ionescu]

First, a sanity check: are you aware that we now only recommend SmartGWT.mobile for certain niche situations?

I would love to have only one application that works both in desktop and mobile but
- you have 2 separate showcases - one super complex and with tons of features for desktop (DSHOW) and one simpler for mobile (MSHOW)
- you can not use a smartphone to work on the DSHOW, it is too complex for small screens and fingers, so how do you want us to have only one app ?
(do you have one detector inside the framework that change from one view model to another - some other frameworks have some forms of templates to do that, but here we have 2 different things - SmartGwt can not serve mobiles, not now, only some of the controls are mobile friendly , but you do not have time to make them full mobile and I abandoned a lot of mobile friendly things on the big projects in order to give the clients a SmartGwt.mobile experience when they are forced to work on smartphones)
- how do you want to go with our huge apps in phoneGap and generate 3 mobile apps (Android, iOS and Windows) ? I do not think that the mobiles will support that memory consuming task at this time, because of hardware limitations

- I think that Windows is preparing something like that, but here, we are far away from this lovely milestone

[Isomorphic]

We're not sure where this criticism is coming from - it's as if you've been looking at a 5 year old version of our software or something.

The full desktop Showcase automatically sets the viewport size so controls are reasonably sized. If you want yet larger, that's a single setting, also shown prominently in the Showcase (the Density dropdown).

The controls shown in the Showcase already automatically adapt to mobile in a very very obvious way (the top-level navigation is totally different when you arrive with a mobile device) and there is a whole folder of samples dedicated to showing this off. If there's some control that you don't think adapts sufficiently to mobile, name that specific control and what you think it does wrong.

With our technology, you can either build a single web application that just adapts automatically for desktop or mobile (as our Showcase does), or you could build native apps for different platforms using Phonegap, or a mix of both. We're not sure why you think it would be harder to generate 3 native mobile apps from SmartGWT than from SmartGWT.mobile - it's equally simple, and again this is only something you do if you choose to. For most enterprise applications, there is no compelling reason to create a native mobile application.

[dorin.ionescu]

Good.
I bought several years ago, for my real estate business, a site from godaddy cloud services, www.exquisiteview.com, that transform itself for desktop or mobile
I still pay monthly fees to them even I am a software developer :-( (3.600 USD in 10 years)
I hope to make a better one with SmrtGwt standard + mobile
Wish me luck !