Announcement

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

    SmartGWT on iPhone? --> Need information for evaluation

    Hello,

    We are looking into evaluating SmartClientGWT for use in a mobile application development project.

    In order to be able to evaluate the mobile support, we would like to get a couple of questions answered:

    1. I looked at the Smart GWT Showcase. When I run this on Safari desktop browser, it works fine. If I change the user agent to "iPhone" or use an iPhone emulator, the UI controls don't work properly - for example, the scrollbar thumbs are not operable. Is this as expected?

    2. Some announcements stated that mobile support is now in Smart GWT. Where can one find the details of what this means? for example -

    Were the widgets modified for mobile support, to look like native mobile widgets?

    Were any new widgets created to emulate mobile widgets - like iPhone Miller lists, bottom tab bars, etc.?

    "The standard Smart GWT event model (including click, double click, drag and drop behavior) is supported." Does this mean that touch gesture events like tap, tap/hold, swipe, pinch, etc., are not implemented?

    Has the charting package been modified to work on touch screens? (For example, given that there is no "mouseOver" event.)

    Is offline storage via HTML 5 supported? How?

    What specific API is available for mobile support?

    What changes/additions were made for mobile support? Something beyond Page.getOrientation() and Page.updateViewport()?


    Please provide this information ASAP, so that we can begin to evaluate the product.

    Thanks,
    Don P.
    CA, Inc.

    #2
    Mobile support is present in recent nightlies - the existing Showcase doesn't have it. Download nightlies here.

    There are two separate offerings:

    1. SmartGWT mobile

    Not yet released but in use by some customers, this is a pure-GWT (all Java) implementation of an "ultralight" widget kit similar to the widgets found in the native iPhone SDK, including bottom-side tabs, iPad Miller lists, switches, sliders and many others widgets.

    It is intended principally for handset-sized applications, with the ability to scale down to lower-end phones and operate with minimal bandwidth.

    These widgets currently implement a pixel-perfect match for iPhone native look and feel and implement native behaviors and animations (slide, flip, etc) that make them look just like a native app.

    Via advanced use of CSS3 these widgets require almost no images and degrade gracefully on less capable phones.

    These widget consume the same DataSources as normal Smart GWT, so if you have created a desktop application with Smart GWT, zero additional work is necessary to connect components to data, and no mobile-specific data services need to be created.

    2. normal SmartGWT plus mobile support

    This product uses the existing SmartClient / SmartGWT runtime and adds mobile support. It's intended for larger applications that run on high-end smartphones and tablets (eg iPad), especially offline web applications that are installed by bookmarking them from a mobile browser so that they can be launched like normal applications.

    Mobile support in SmartGWT also means that even if you have a handset-specific interface, users can get to and use the full interface if they need to.

    Most applications built in SmartGWT do not need retrofitting to run on mobile, because touch events are translated to mouse events automatically. Specifically:
    - touch events are received as normal mouse events (mouseDown/mouseUp/click)
    - a touch and drag is received as the standard SmartGWT event series for a drag (mouseDown, dragStart, dragMove(s), dragStop) and all built-in drags just work
    - a touch-and-hold triggers context menus

    Obviously, there is no analogue of mouseOver, so applications that depend heavily on mouseOver may need some rework. We will likely add some flags that trigger eg hovers via an alternate event when this is unambiguous (for example, if the element does not have a click handler, touching it may as well trigger hover).

    There are then touch-specific settings (like defining a different drag operation for two-finger vs one-finger drags) and direct access to touch-specific events (eg detect number of fingers down) for applications that want to implement touch-specific behaviors. There are also a few other mobile- or touch-specific API like detecting orientation change and controlling the viewport - see this overview.

    There is also a "Mobile" skin for normal SmartGWT that uses CSS3 to minimize images, and uses native look and feel for components that also exist in typical touch widget sets (eg Button, Slider) and harmonious appearance for widgets that don't (eg SectionStack).

    Other questions:
    1. Charting - yes it works on mobile.

    http://blog.isomorphic.com/?p=213
    http://blog.isomorphic.com/?p=197

    2. Offline - yes it's supported, it's very powerful (a single property on a DataSource just enables automatic use), and will be announced on the blog very soon - this week or next.

    Note that:
    1. as mentioned, SmartGWT Mobile isn't public yet. Contact us directly to view confidential demos or for a POC.

    2. in SmartGWT, the new Charting functionality is available only via the chartData() API on ListGrid. Direct creation of charts is documented and available for SmartClient, but not SmartGWT yet

    3. the ability to get to touch-event specific information (like number of fingers down) is likewise not exposed in SmartGWT yet

    Comment


      #3
      Hello Isomorphic,

      Thanks for the quick reply. This sounds promising.

      A few follow-up questions -

      1. What is the situation with Android OS support? And native-looking widgets on that platform?

      2. With SmartGWT Mobile, is the same offline storage supported as normal SmartGWT + mobile?

      3. Does normal SmartGWT + mobile have the same degree of native look as SmartGWT Mobile?

      4. For either mobile library, is there anything that would prevent, or advise against, using them in a desktop web browser? This question is coming from the fact that we need to deploy this new application to iOS, Android, and desktop - so we'd prefer to leverage as much as possible of the mobile app on the desktop.

      5. For the charting package, does this render using <canvas> on mobile WebKit browsers?

      6. How exactly is detection done of devices - desktop, iPhone, iPad, Android? Is there an API to access the detected device type?

      We would be very interested in arranging a POC, for both products, to validate some specific concerns we have. Can you send me contact information for the person most appropriate to arrange this with? You can send this to my account email.

      Thanks,
      Don P.
      CA, Inc.

      Comment


        #4
        1. What is the situation with Android OS support? And native-looking widgets on that platform?
        Because of attempts by handset manufacturers to differentiate devices, actual Android devices in the field have no single native appearance. However, our second-priority mobile skin is something that looks like the Android emulator (Google's default look and feel, effectively), with possible improvements.

        Note also, there are multiple color schemes even within Apple-provided software pre-installed on iOS devices (Calendar vs Notes vs Mail for example) and also within Apple-provided add-on software (iWork). Making an application "feel native" is more about following certain UI idioms like Miller column navigation than appearance per se.

        2. With SmartGWT Mobile, is the same offline storage supported as normal SmartGWT + mobile?
        Yes - under the covers it is the same code in fact.

        3. Does normal SmartGWT + mobile have the same degree of native look as SmartGWT Mobile?
        Currently it does for buttons, sliders and certain other controls. It will offer native appearance for all widgets where there is a native equivalent, in addition to some options of whether to switch to native appearance when it's radically different (not all TabSets work equally well as iPod-like bottom bars).

        4. For either mobile library, is there anything that would prevent, or advise against, using them in a desktop web browser? This question is coming from the fact that we need to deploy this new application to iOS, Android, and desktop - so we'd prefer to leverage as much as possible of the mobile app on the desktop.
        Nothing in the library itself. However from a UI design perspective you will want to use screen space differently, for example, you may want side-by-side list and details views on tablet and desktop, and a slide transition from list to detail on a handset (think iPad vs iPhone Mail app). So, you may have a single codebase with some handset-specific conditional.

        We plan to provide some layout components that do this switching automatically, specifically, one would be a SplitPanel that automatically implements this exact switching behavior on handset vs desktop.

        5. For the charting package, does this render using <canvas> on mobile WebKit browsers?
        Yes, plus some tricks. On desktop browsers it can use VML (IE), SVG or <canvas>, from the same APIs. In some use cases, SVG is a better choice for performance.

        Code:
        6. How exactly is detection done of devices - desktop, iPhone, iPad, Android? Is there an API to access the detect device type?
        Yes, however the range of devices changes so fast that we plan to allow you to override the built-in detection, and we will have a forum thread you can subscribe to that shows the code used to detect browsers, which we will update as new devices come out.

        Comment


          #5
          Hi,

          We have 48 hours to evaluate the mobile aspects of this.

          I've downloaded a nightly build of SmartGWT Eval, and have run into a few issues:

          * Since I would like to evaluate the UI aspects of mobile support, I'm obviously more interested in teh UI/widget samples than the server-side samples of things like Data Sources, Web Services, etc. However, in the build, the samples don't include the UI Showcase, only the server-side showcase. From the installed showcase, clicking on the "SmartGWT showcase" launches this from www.smartclient.com, not my locally installed build. How do we get the UI Showcase code?

          * In one of the replies above, it says:
          "There is also a "Mobile" skin for normal SmartGWT that uses CSS3 to minimize images, and uses native look and feel for components that also exist in typical touch widget sets (eg Button, Slider) and harmonious appearance for widgets that don't (eg SectionStack)."
          However, in the nightly build, the only skins I see are Enterprise, Simplicity, and Graphite. Do I have the mobile support files in this build?

          * I am able to import the ShowcaseEE project into Eclipse and build it using the GWT Eclipse plugin. However, when I change the theme and recompile, I see no differences. It looks to me like the pre-packaged samples are not referencing the compiled JavaScript area, and are running in some other way. Is there something I need to change to make this work?


          * One of the attractions to SmartGWT would be the integrated charting package. I only now just read your last comment, that the charting is not fully integrated into SmartGWT. What is the timeline for doing this, and will it be integrated into both SmartGWT and aSmartGWT Mobile?


          We could really use some help expediting getting a modifiable sample application running, so that we can validate if this is worth continuing to evaluate. Is there someone that can provide us with some assistance?

          Thanks,
          Don P.

          . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
          Don Peterkofsky
          Principal Software Engineer
          CA, Inc.

          Comment


            #6
            If what you want is a modifiable sample project, start with the built-in-ds project, not the Showcase. You can copy and paste code from any Showcase example (in either Showcase) into that project to work with that sample as a modifiable sample.

            As the QuickStart covers, working with the Showcase as a modifiable project doesn't make sense because it's written in a very specialized way to be an example browser.

            Your problems with the online LGPL Showcase are strange - we've got Apple's iPhone/iPad Simulator (part of XCode), a physical iPad device and a physical iPhone device - they all work and scrollbar thumbs can be dragged, columns reordered and resizes, data edited and saved. There were refinements after this release but basic functionality should work - sounds like the "emulator" you're using may not be faithful to the actual device behavior? What emulator exactly are you using?

            Comment


              #7
              Thanks for the reply.

              Regarding the scrollbars, the emulator I was using is an admittedly cheesy one - it's a Flex app that embeds a WebKit borwser and sets the user-agent to iPhone or iPad. Apparently, it doesn't do anything to translate mouse events to touch events, and that must have been the issue.

              I'll try the BuiltInDS example, but the point was that we want to see the various UI widgets in the Mobile skin.

              Do you have an answer for my questions/points 1, 2, and 4 of the last post?

              Thanks,
              Don P.

              Comment


                #8
                Wow. OK that emulator is completely useless, we would recommend the free emulator from Apple that's part of XCode, which has been faithful to actual device behavior in all but some very obscure ways.

                Since the online Showcase already supports mobile (once you use either an actual device or a functional emulator) that's a good approach to evaluate a range of samples. You can also download the LGPL package and run an "ant" script to build a showcase.war that you can then deploy, but there's little point to this and you have limited time.

                On charting: there isn't a committed ETA, but if you engage us for a POC, we can do it as part of that.

                On skins: 4 skins are included (Enterprise, Enterprise Blue, Graphite, Simplicity) but not Mobile because it's not complete. Let's take this to email so we can provide confidential demo links under NDA.

                Comment


                  #9
                  Hi Again,

                  Here is what we need to do:

                  Evaluate the potential use of SmartGWT for building a web app targeted at mobile devices, with native Look & Feel.

                  So far, I have not been able to start doing this.

                  In reading the initial reply, I got the impression that both versions of SmartGWT support native-looking mobile widgets, since the descripton of normal SmartGWT said: 'There is also a "Mobile" skin for normal SmartGWT that uses CSS3 to minimize images, and uses native look and feel for components that also exist in typical touch widget sets (eg Button, Slider) and harmonious appearance for widgets that don't (eg SectionStack).'

                  I have not seen this "Mobile" theme, and I have also not found any natvie widgets, like Miller column lists, etc. Maybe I misunderstood, and maybe we need the Mobile version of SmartGWT for what we're trying to accomplish.

                  Can you please clarify, and if it seems that what I'm looking for is the Mobile version, please advise on how to acquire it ASAP.

                  Yes, email would be a good idea. Do you have my email (would prefer not to post it)?

                  Thanks,
                  Don P.

                  Comment


                    #10
                    We've already gone to email, but just to cap this discussion:

                    Evaluate the potential use of SmartGWT for building a web app targeted at mobile devices, with native Look & Feel.
                    You've got this, you lack only the (unreleased) Mobile skin, which we're demoing privately (in incomplete form). In general, any developer can build mobile applications with SmartGWT now, and just switch their GWT imports to the Mobile skin when it's released.

                    Comment


                      #11
                      Hi,

                      I am a software developer in Skura Corporation. Our company is developing web based versions of most of our applications, currently targeting primarily the iPad and we intend to use GWT as our core UI technology.
                      I am evaluating the features and widget sets available in SmartGWT 2.3. All the touch functionalities seems good, except Flick-Scrolling behavior on iPad for datagrid and panels. When I flick inside datagrid or panel it scrolls, but the scrolling is not smooth at all and the behavior is not at all like iPhone or iPad. Could you please let me know whether smartgwt is working on improving the scrolling behavior in next release as soon as possible? This information is very important as it is now the deciding factor for whether to use smartgwt or move to some other technology.

                      Thanks,
                      Debashis Roy

                      Software Developer
                      Skura Corporation

                      Comment


                        #12
                        I have version 2.4 of SmartGWT, and I have an web app which works very well, if even loads on Safari for iPad, and iPhone. Only problem is that on mobile browsers, the app is very slow and response time for widgets is very poor. Is this something that will be addressed in upcoming versions or is there a configuration that I'm missing in the current version. I'm only asking because, I've read that the current version is supported on mobile browsers.

                        Thanks.

                        Comment


                          #13
                          Make sure you are using Simplicity or Mobile skin, which are lighter weight.

                          Make sure you aren't rendering or creating controls before they are shown to the user. This is always a best practice, but you can get by without doing it most of the time for a desktop-only application.

                          Show less columns in grids and less controls for smaller screens. This is better design and also enhances performance.

                          Finally, if you've reduced down to a test case that you think you perform better, post that test case.

                          Comment


                            #14
                            Thanks for the prompt reply.
                            I've checked out the Mobile skin, and it looks good. I've been using Simplicity, but I was still having the slow load times and Controls not being responsive on touch interfaces, so it might be due to design issues. Thank you also for your UI design tips. One question I have about that. You said:

                            "Make sure you aren't rendering or creating controls before they are shown to the user"

                            How do I do that? I'm still relatively new to smartGWT, so I'm not exactly sure what that means.

                            Comment


                              #15
                              Defer calling "new" until the control is about to be shown and used. For example, for a TabSet, don't create the controls for tabs that will not be initially shown. Instead create them and show them when the TabSelected event happens.

                              Comment

                              Working...
                              X