SmartGWT.Mobile Status

[mattcecile]

Hi, I've been evaluating the potential use of SmartGWT.Mobile for a mobile variant of our SmartGWT application.

Before commiting to this project, I'd like to know the current status of the product. It appears to have been in beta for 16 months or so and doesn't have much activity lately. Questions seem to go unanswered on the forums and the product seems to have some pretty big gaps at this point (only supporting an IOS skin, not many widget types supported, etc). Not trying to be critical here but I want to have an accurate picture of the current product state.

If you can provide any information that would help us, that would be much appreciated. I can provide some more detailed questions if you like but thought I'd open with a query on the current product state and plans.

Thanks!

Matt

[Isomorphic]

The product is evolving rapidly and support is available for it, under the same terms as development builds (see SmartClient.com/builds).

We don't see a lot of unanswered questions other than those with obvious problems.

What functionality are you looking for that you don't see?

[mattcecile]

OK, to be more specific:

1) The ongoing 18 month+ Beta is a concern. Is there a release date planned? I can't really plan to go into production with a beta version.

2) There is currently only an IOS skin. When can we expect to see skins for other platforms include IOS7, BB10, Android & WM8. Is there any documentation on how to produce our own skin?

3) I'd really need to have the ImgButton control available. Is this planned/possible?

4) On the Button control, the setWidth & setHeight APIs seem to be ignored but the documentation does not reflect that.

5) On the Button control, the setIconAlign using BOTTOM or TOP does not do anything.

6) Are items 4) and 5) indicative of a design decision that means that look and feel are implemented in CSS and can't be changed via the APIs?

I haven't gotten too far in my implementation as yet but these items raised some warning flags for me to stop and ask some questions.

Thanks for your time in answering them,

Matt

[Isomorphic]

OK, to be more specific:

1) The ongoing 18 month+ Beta is a concern. Is there a release date planned? I can't really plan to go into production with a beta version.

Not much to say here except that this is kind of the "new normal". It allows projects to get the APIs right by getting a lot of user feedback before deprecation and other post-1.0 processes are necessary. As we've mentioned, your support contract already applies to this product.

2) There is currently only an IOS skin. When can we expect to see skins for other platforms include IOS7, BB10, Android & WM8. Is there any documentation on how to produce our own skin?
...
6) Are items 4) and 5) indicative of a design decision that means that look and feel are implemented in CSS and can't be changed via the APIs?

From what we've seen, the enterprise trend is actually to have a relatively uniform appearance across these different platforms rather than try to appear native (which is costly, and ultimately does not reduce training costs, but can rather expand them).

That said, SmartGWT.mobile is skinned entirely via CSS. But it is, by necessity, very advanced CSS.

3) I'd really need to have the ImgButton control available. Is this planned/possible?

Just use Img and add a click handler. We'll make a (trivial) ImgButton subclass so this is more obvious.

4) On the Button control, the setWidth & setHeight APIs seem to be ignored but the documentation does not reflect that.

5) On the Button control, the setIconAlign using BOTTOM or TOP does not do anything.

These are somewhat odd requests which suggest that you are building an interface more like a desktop UI than a mobile device. On 4) generally buttons should autosize and be a uniform height, which is what they do. On 5) you may be trying to replicate the look of iOS tabs, but TabSet already does that.

[mattcecile]

Thanks for the response.

A couple points to clarify:

From what we've seen, the enterprise trend is actually to have a relatively uniform appearance across these different platforms rather than try to appear native (which is costly, and ultimately does not reduce training costs, but can rather expand them).

Currently, SmartGWT.Mobile uses an IOS skin and IOS UI elements (Popover, Tabs, Toolbars, etc). It looks like an IOS app. If the current IOS style were used to deliver to Android or WM8 devices for example, it would go against the whole point of doing this. If you are saying this will change to be a more generic mobile style, that would be fine with me.

That said, SmartGWT.mobile is skinned entirely via CSS. But it is, by necessity, very advanced CSS.

So, are you saying that you do not intend to document the CSS and that the CSS will override some of the API calls? Will you remove the non-functional API calls? This would be prefered to trying things and then discovering that they are not supported.

Thanks again for your responses!

Matt

[Isomorphic]

Currently, SmartGWT.Mobile uses an IOS skin and IOS UI elements (Popover, Tabs, Toolbars, etc). It looks like an IOS app. If the current IOS style were used to deliver to Android or WM8 devices for example, it would go against the whole point of doing this. If you are saying this will change to be a more generic mobile style, that would be fine with me.

It does closely mimic iOS (mostly to prove that this is possible), but a few background color and gradient changes are all that's required to depart noticeably from that look. Rather than trying to create a SmartGWT.mobile distinctive look and feel, what we'll likely do is show some sample CSS that would tint elements, rearrange gradients, etc to create a different look for a couple of components, and let designers take it from there.

So, are you saying that you do not intend to document the CSS and that the CSS will override some of the API calls? Will you remove the non-functional API calls? This would be prefered to trying things and then discovering that they are not supported.

A capable designer can do skinning now; like most frameworks the CSS style in use are obvious from the DOM.

We'll be adding JavaDocs that actually list out the styles used for each component formally, but in reality designers don't look at JavaDoc, and we've (almost entirely) removed the need to do parts of skinning via API calls or JSON config as in SmartClient, which is actually usually perceived in a negative way even if it's simpler and more consistent than CSS.

For things like Button.setWidth() not working, we'll check on that report, but if true then yes, we'll doc that that API is inapplicable since auto-sizing takes place.

[Isomorphic]

Just confirming: setWidth() and setHeight() are not generally supported on all components; most components set size via CSS, and/or auto-size to content. To clarify this, we'll be removing setWidth()/Height() APIs from Canvas and only showing them on components where it makes sense to programmatically supply a size (eg Img).