SmartGWT.mobile & GWT 2.7.0

[mark1]

I just tested using smartgwt-mobile with gwt 2.7.0 - and get a build error.

Version: smartgwt-mobile-1.0d_2015-01-22

If I try and build the included 'helloworld' sample .. I get the same error as in my project... Is this known about? or am I doing something wrong?

gwtc:
     [java] Compiling module com.mycompany.HelloWorld
     [java]    Ignored 1 unit with compilation errors in first pass.
     [java] Compile with -strict or with -logLevel set to DEBUG or WARN to see all errors.
     [java]    [ERROR] Could not find com.google.gwt.core.client.impl.StackTraceCreator.CollectorChrome in types compiled from source. Is the source glob too strict?
     [java]    [ERROR] Errors in 'com/google/gwt/core/client/impl/StackTraceCreator.java'
     [java]       [ERROR] Line 364: Rebind result 'com.google.gwt.core.client.impl.StackTraceCreator.CollectorChrome' could not be found

... Also I found trying to search to find if this [and other issues in the past] had already come up much trickier because of all the discussions of SmartGWT not-mobile - would it not make sense to have a separate forum for SmartGWT-mobile - particularly as it has quite a different API [and output] to the desktop products?



Thanks,

[Isomorphic]

We'll see if we can reproduce this error, however, note that our recommendations regarding use of SmartGWT-mobile vs full SmartGWT have changed as of 5.0.

Since full SmartGWT now includes a wide variety of automatic adaptations to mobile devices and has very good performance on mainstream smartphones, we only recommend SmartGWT-mobile for certain super-lightweight phone-only (no desktop version) applications.

[Blama]

Hi Isomorphic,

I assumed this after seeing the samples in the normal showcase. The FAQ does not mention it, tough. As I'm going to develop a mobile version of our product soon(ish), I'm very interested in this (and also like it, because it means more reusable code).
I can confirm that the desktop version of my 4.1p application works like a charm from an iPhone 5s (perhaps also 5) regarding performance and same-as-desktop behaviour when just "showing that it works" (no deep testing, yet). Obviously I'll have to re-do the UI.

FYI: The FAQ seems unchanged on this to me.
Could you also elaborate on "By ignoring desktop Internet Explorer we can be a lot lighter" and your plans here?

Best regards,
Blama

[Isomorphic]

We still plan to update the FAQ, however, the nutshell is what we've already stated here.

The statement about IE means just what it says: not needing to support legacy desktop versions of IE meant that SmartGWT-mobile did not need a large amount of workaround code and alternative DOM structures required to deal with IE's many bugs.

[Isomorphic]

Google shuffled some APIs around. The next nightly of SmartGWT.mobile corrects the issue.

[mark1]

Thanks for fixing that - it now builds. :)

[Blama]

The statement about IE means just what it says: not needing to support legacy desktop versions of IE meant that SmartGWT-mobile did not need a large amount of workaround code and alternative DOM structures required to deal with IE's many bugs.

Hi Isomorphic,

I understood that. The question was, that, now that you suggest the use of SmartGWT 5.0p for mobile as well, will you drop support for older IE versions eventually in order not to need the mentioned large amount of workaround code?
It seems that MS itself plans to have two browsers inside IE with Windows 10, new Project Spartan and old Trident.

Best regards,
Blama

[Isomorphic]

In general, we drop support for older editions only when the number of users that need that support becomes trivially small.

However, even when this finally happens, this is not going to lead to a significant size savings for the full version of SmartGWT, which has a *lot* more capabilities than SmartGWT.mobile, and those capabilities are implemented with code that isn't browser-specific at all.

[Blama]

Hi Isomorphic,

that's good to know, thanks.

Regarding the organisational part: How do you know that "the number of users that need that support becomes trivially small"?
Do you consider the forums here, statistics like StatCounter GlobalStats or referrer information?
When was the last time you dropped support for a browser (I can't remember one, but I'm not using many (old) browsers)?

Regarding the technical part:
The little savings you mentioned would only regard js-filesize, because you then can save some "else if version=abc"-parts, correct?
The DOM generated for a browser is always optimal for that browser, so e.g. Firefox would not benefit from dropped support for IE8?

Thank you & Best regards,
Blama

[Isomorphic]

We use all of the different sources of information you mention, and others.

We are constantly dropping Chrome, Firefox, Safari and Opera versions that are too old. IE6 is generally still supported, because of some important WinXP holdouts, but it will hopefully go away soon.

Yes, we are able to use an optimal DOM for the current browser regardless of whether we still have to use a more complicated DOM for older browsers. This is why, for example, we have a CSS3 mode (see Skinning overview) activated in all modern browsers.