Your current recommendation on SmartGWT vs smartGWT mobile

[Blama]

Hi Isomorphic,

what's your recommendation on SmartGWT.mobile vs SmartGWT if I start mobile development in a month. Of course I have read the FAQ and the Docs.

My current setting is the following:
A desktop application that looks good on screens with 1280+ width and makes heavy use of grouped ListGrids with many columns. It also works on a iPad in landscape mode, but has small hover / drag & drop problems as described in the docs. These are no problem at all, because the application is almost always used from the browser.

Now I want to add a mobile version that will be targeting phones-only (OK if it also works on tablets, but that is not necessary or expected).
Because I want to use the "red dot" and lock screen notifications, I will use either Titanium or PhoneGap.

In the FAQ you say:

As of the automatic mobile adaptation features included in SmartGWT 5.0 and up, we are now only
recommending SmartGWT-mobile for applications that exclusively target phones, will never have a desktop
UI, and place a very high value on first-ever download time while having relatively simple functional
requirements.

You might also consider SmartGWT-mobile if you have multiple mobile interfaces to build for
different types of users, and some users should have a very low functionality interface that has virtually
nothing in common with the desktop & full mobile experience.

To list the points:

• applications that exclusively target phones: true (better: I'm fine with two projects and don't care for tablets)
• will never have a desktop UI: true (better: I'm fine with two projects)
• place a very high value on first-ever download time: false
• while having relatively simple functional requirements: true (1-col ListGrids and DynamicForm, only I assume)

Actually, as the app is going to be packed and installed and not downloaded on start, I don't care for size.


In this case, would you prefer SmartGWT.mobile or Smart GWT?
Also I like IDACall better than RESTHandler, so this also is a plus for the big framework.
If SmartGWT, is the integration with the app packaging more complicated with it compared to Smart Client? Or does it not matter? If possible, I'd like to use SmartGWT as I'm used to.
Which of the packaging tools is better integrated with Smart Client / SmartGWT?

Thank you & Best regards
Blama


PS: I don't know how recent the docs-documents are. My issues:

• They *seem* (not saying they are, but that's the impression you get as a 1st-time reader) out of date because of the mention of iOS 7 in PhonegapIntegration. http://phonegap.com/install/ there is an endless redirect.
• MobileDevelopment also seems to be from iOS 7.1 times.
• MobileDevelopment has many broken javadoc {@link.

[Isomorphic]

We'd recommend SmartGWT and not SmartGWT mobile. Among other issues, SmartGWT.mobile continues to have an iOS6 look and feel and we have no plans to update it.

Even if your current interface layout is totally unsuitable for mobile, by adding a couple of simple conditionals you can rearrange the components for a better mobile experience, and you will avoid having to reimplement all kinds of little bits of logic such as formatters, validators, event handlers, etc.

For the same reason we would continue with SmartGWT rather than build a parallel SmartClient application.

We can't really recommend a winner between Phonegap and Titanium. The choice has a lot to do with what native phone capabilities you may need, which toolset you like better, your budget, etc.

There is an unclosed <code> tag in the Mobile Development JavaDoc which broke several links - we'll get that fixed shortly. Other than that, the material remains accurate: the minimal-ui setting is still necessary to work around Apple's choice to break interactivity at the top/bottom of the Safari browser.

It's surprising that http://phonegap.com/install is not working - we suspect this is a transient issue with their site, but if you have what appears to be a better / more stable link, please let us know.

[Isomorphic]

The issue related to broken javadoc @links has been fixed.

Regards
Isomorphic Software