Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    SmartGWT.mobile vs responsive design

    With a new webapp on the horizon, targeted for mobile, I'm wondering which road to take for development.
    It will have (or it seems, for now, you know) a pretty simple UI.
    I see that SmartGWT.mobile is still in beta and the 'responsive design' in SmartClient 10 is close to release.

    Is Smart.GWT still a product which you'll develop actively? Are you developing a new skin? Any ETA for a release?
    We haven't got experience with SmartGWT, SmartClient only, so a bit more to learn here.

    About Responsive Design in SmartClient: how far would you push it? I mean, could it make SmartGWT.mobile obsolete?
    I'm asking because I see in the samples that you're working not only on layouts, but also at a finer level on widgets usability as spinner controls...

    Sorry for asking, but you're faster in developing new features than us in learning/adopting them, so I'm a bit scared :-) and I don't want to take the wrong way
    Last edited by claudiobosticco; 29 Aug 2014, 03:42.

    #2
    Hi claudiobosticco,

    I wondered about that, too (regarding SmartClient Explorer, correct?). Then I remembered reading this FAQ entry (read also the rest of the SmartGWT.mobile chapter).

    I think the mobile stuff has to be in the SmartClient showcase, because there is no place else for it. With SmartGWT you can use SmartGWT.mobile.

    @Isomorphic: FAQ quote:
    Originally posted by Isomorphic View Post
    In a nutshell, if your application:

    1. primarily targets phones and tablets: use SmartGWT.mobile only

    2. primarily targets desktops and tablets: use Smart GWT only

    3. targets desktops, tablets and phones: consider using both; however, depending on devices and
    requirements you may use just one or the other
    Wouldn't it be a good idea regarding 2. to have the mobile samples from SmartClient also in SmartGWT?

    I'll also have to start an mobile app later this year or next year and would be interested in an approx ETA for SmartGWT.mobile as well. It just feels better to be using p-versions instead of beta or d-versions.

    Best regards,
    Blama

    Comment


      #3
      Hi Blama, thanks for your comments.

      I read that FAQ in the past (but re-reading it doesn't hurt).
      Actually our app will target primarily mobile (smartphones and some tablets), but also desktops.
      So I can't really use SmartGWT.mobile only.
      Actually in the FAQ I'd change 'primarily' with 'exclusively', wouldn't you?

      As I said, we have no experience with SmartGWT (neither GWT) at all. So, using SmartClient could speed up our development.

      But this will be also our first webapp used primarily with 3G connections (instead of Wi-fi). I'm worried that loading a SmartClient webapp on mobile could be much slower than a SmartGWT.mobile webapp, especially considering it will have a pretty simple UI.
      Is it available some benchmark about that matter?

      Comment


        #4
        It's fair to say that after SmartGWT 5.0 is out with all of its mobile adaptation features, it will only make sense to use SmartGWT.mobile for *exclusively* mobile apps, and even then, not always.

        As far as bandwidth/performance, it's important to realize that due to rapid upgrades of phone hardware and cell networks, the worst case scenarios for phones are actually not as bad as the worst case scenarios for desktops. For example, IE8 on a poor office WAN is worse than almost all possible phone access scenarios.

        This means that whether the full SmartGWT framework is appropriate for your mobile app has a lot to do with the usage scenario, just like it does for desktop apps: is your application used once ever by users who might leave if it takes more than 3 seconds to load? Then you might need a lighter technology. But if it's used in any sort of business / corporate setting, and re-used repeatedly, then the one-time-ever download is not an issue at all, and the richer functionality and performance benefits after initial load easily outweigh the small delay for first-ever load.

        Comment

        Working...
        X