Implementing a Mobile-Friendly Layout for a GWT Application Using UiBinder

[divyanshu kumar]

I’m working on a GWT application that was originally designed for desktop screens, but I now need to create a mobile-friendly layout that retains the existing functionality. As I’m relatively new to GWT and UiBinder, I’m looking for guidance on the best practices for adapting my UI for mobile devices.

My specific questions are:

• Responsive Design: What strategies or design patterns can I use within GWT to implement a responsive or adaptive layout?
• UiBinder Tips: Are there any particular tips or resources for effectively using UiBinder when designing for mobile?
• Code Reusability: How can I maintain the same functionality across both desktop and mobile versions without duplicating too much code?

Any sample code recommended libraries or links to useful tutorials would be greatly appreciated. Thanks in advance for your help!

[Jens]

For responsive design you should use CSS media queries in CSS for the most part. However there are cases in which you want to use a totally different component and in that case you can use JavaScript to listen for media query events (see https://developer.mozilla.org/en-US/docs/Web/API/Window/matchMedia) and modify the UI via code instead of CSS. To use it you would need to use elemental2 library which makes Browser APIs accessible via Java API.

Then your desktop application probably only uses ClickEvents. You have to keep in mind that mobile browsers have a 300ms delay between touching the device and firing a click event. The reason is that the device needs to wait if the user might want to do a zoom, swipe, whatever gesture. So if your mobile application should feel snappy and responsive you would need to tell the browser via a HTML meta tag that zooming the page is not allowed. Alternatively add click event handlers and touch event handlers in your code or switch to pointer events (not provided by GWT out of the box but you can define your own event classes for pointer events).

In the past (maybe even today) some might have used an advanced GWT technique and provide a dedicated GWT permutation for mobile. In that case you need to define a new configuration property, some code to detect mobile via JS and write a desktop/mobile value into that property and then GWT will compile an additional set of permutations and in your code it is like having a second entrypoint which only starts for mobile. But I think that solution is only useful if the mobile application is very different than the desktop application and you want a clear separation in code.

Code reusability highly depends on the concrete situation. If you can use media queries and CSS adjustment then you do not duplicate anything, things are just rearranged in the UI. If CSS adjustments are not enough and you need a dedicated mobile component then it might be possible to let it implement the same interface as the desktop component and you can share logic in a common presenter/controller class.

-- J.

[divyanshu kumar]

Thank you so much for your guidance! I now have a much clearer idea of what I need to do to accomplish this task.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/adcdeb1c-1be3-44c0-8452-014908c0b4c7n%40googlegroups.com.

[Craig Mitchell]

Don't try to put things like CSS media queries in the <ui:style> in the ui.xml files.  In my experience, GWT doesn't understand this, and it doesn't work.  Instead, have them in a normal CSS file that you include, and that you reference via the normal "class" attribute in your ui.xml files.

[divyanshu kumar]

i got it. Thanks for your guidance. 

[divyanshu kumar]

Does any GWT developer have time to do a Google Meet? I want to talk regarding the above issue and approaches. cause an existing project has a lot of code, I don't want to share the whole code here. and I am gonna show the project as well.
here is my email: kumardiv...@gmail.com
Thank you so much in advanced

[Colin Alworth]

As another alternative to sharing your whole project, consider joining https://matrix.to/#/#gwtproject_gwt:gitter.im for live discussion, so you can work through some ideas "out loud". Likewise, you might find it helpful to make a quick/small example project which you can easily share, and build some structures/ideas to share with others. These typically make sense to be simple runnable projects on some public git host, showing what you want to get and what you tried so far so others can take a look at how you got there and make suggestions.

With those options mentioned, our company offers commercial support for GWT and its ecosystem, and have worked with more than a few teams who just want to do a screensharing call to discuss their project once a month or so. To that end we're happy to do a 30 minute call or so and discuss the project you're working on, and see where things go from there. Reach out off-list if you're interested.

[divyanshu kumar]

Hi everyone,
I am a 2nd-year undergraduate student. As I mentioned at the very beginning what I have to accomplish. I am discussing with my mentor the best possible way to accomplish this task, but the result is still not clear.
if anyone could give me a detailed guide on me from basics how I am gonna proceed, it would be very helpful:

Below are two my approaches I’ve been contemplating:

Approach 1: New Module (MobileUiResponsive)
Idea: Create a new module, "MobileUiResponsive," similar to how Neo extends Classic. This would involve reusing code and adjusting the CSS (for example, modifying Ya.css) to suit mobile requirements.

This method would keep the desktop and mobile code separate, which could be beneficial for the UiBinder framework.

Approach 2: Responsive Design in One File
Idea: Modify the existing file (e.g., DesignToolbar.ui.xml) and incorporate CSS media queries to handle both desktop and mobile layouts.

-------- My mentor's opinion on my approach:

My personal preference if for the use of CSS media queries, but that may not be viable in all circumstances. In particular, we'll want to think about how we show/hide the palette and property editors in the designer. Another thing that we should take into account is how the content will be displayed in both portrait and landscape modes. For example, Scratch Jr and OctoStudio put the block palette along the bottom in portrait mode since otherwise it obscures too much of the screen.

My primary concern with approach 1 is that it involves an additional step if switching between devices (which is something I often do). Media queries solve that problem at the browser level. However, it certainly will give us more flexibility in terms of how we structure the final UI in case we need a substantial departure from our existing UI layouts.

---------------------then I gave him another approach, which is the hybrid approach:

My Recommendation: A Hybrid Approach

After analyzing everything—I suggest a hybrid approach that balances both methods. Here’s why and how:

Why Hybrid?

• Media queries make it automatic, which users will love.
• Separate code is cleaner for big changes (e.g., hamburger menu).
• Practicality: we can use one file for simple adjustments and Java logic for complex mobile behaviors.

How It Works

1. Base UI in One File: Keep the existing UiBinder XML (e.g., DesignToolbar.ui.xml) as the main file.
2. CSS Media Queries: Use them for simple layout changes (e.g., stacking buttons, shrinking sizes).
3. Java Logic: Add code to handle mobile-specific features (e.g., toggle panels, hamburger menu).
4. No New Module: Avoid a separate “MobileUiResponsive” module unless the UI changes are massive.

----------my mentor's opinion this :

The UI changes are going to be massive, aren't they?

I'm not sure I understand the value of handling the mobile layout as part of the Classic layout. {i am totally agree with this point}

------then I discuss with my another way:

created a new module like "MobileUiResponsive"

Why a New Module: You’re absolutely right—the UI changes are massive. A separate class (like DesignToolbarMobile) and UiBinder file (DesignToolbarMobile.ui.xml) let us redesign the layout

To tackle worry about switching devices, we’ll select the UI at runtime based on screen width.
This runs when the app loads or resizes, so the UI adapts instantly—no manual steps needed. It’s as seamless as media queries but gives us the flexibility for structural changes.
We’ll use css for fine-tuning, like positioning the palette.
This complements the new module and ensures a polished look across orientations.

-----my mentor's opinion on this:

That's not quite true. At the moment switching the UI layout requires refreshing the page, which includes multiple round trips to the server, so will be more expensive than the browser simply applying CSS media queries. And given they are on mobile devices it may involve a metered data connection as well.
-----

That's not quite true. At the moment switching the UI layout requires refreshing the page, which includes multiple round trips to the server, so will be more expensive than the browser simply applying CSS media queries. And given they are on mobile devices it may involve a metered data connection as well.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This would be a one-time use of resources since the setting is remembered after it's selected. We also reload the page when we change languages.
--------

as I am a beginner in GWT, you have to guide me in that way so I can understand that and will do research and accomplish this task.

Thank you so much for your valuable time.
GitHub: https://github.com/d1vyanshu-kumar

On Thursday, 20 March 2025 at 15:08:21 UTC+5:30 divyanshu kumar wrote:

[divyanshu kumar]

This is the  final two approach I ended with :

 The First approach:

1. Identify Components for Adaptation:
Key components include like toolbar, palette, property editor, and blocks workspace. For mobile, consider touch-friendly designs, like collapsible panels or bottom sheets for palettes
2. Design Mobile Layouts:
Plan how each component looks on mobile. For instance, the toolbar might use a hamburger menu on mobile, while desktop shows all buttons horizontally. Consider examples like Scratch Jr, which places the block palette at the bottom in portrait mode to avoid obscuring the screen
3. Implement Using UiBinder:

```
<g:HTMLPanel>
  <ai:Toolbar ui:field="desktopToolbar" visible="true">
    <!-- Desktop toolbar items, e.g., horizontal buttons -->
  </ai:Toolbar>
  <my:MobileToolbar ui:field="mobileToolbar" visible="false">
    <!-- Mobile toolbar, e.g., hamburger menu -->
  </my:MobileToolbar>
</g:HTMLPanel>
```

using a single UiBinder file (DesignToolbar.ui.xml) with separate panels for desktop and mobile, toggling their visibility.
4. Use Java for Dynamic Switching:
The Java logic toggles visibility based on a 768px threshold (a common breakpoint for tablets vs. phones), using Window.getClientWidth(). The ResizeHandler ensures the UI adapts dynamically when the screen size changes (e.g., device rotation), all without page refreshes.
5. Apply CSS Media Queries:

 2nd approach:

1. Create a New Module:
Create .ui.xml and respective java file for e.g: DesignToolbarMobile.java, DesignToolbarMobile.ui.xml and then change the respective css file for this.
2. Add Runtime UI Selection:
Swaps only the toolbar, not the whole page. Faster and smoother!
e.g:

```
private Widget currentUI;
private final FlowPanel container = new FlowPanel();

@Override
public void onModuleLoad() {
  RootPanel.get().add(container);
  loadUI();
  Window.addResizeHandler(event -> loadUI());
}

private void loadUI() {
  int width = Window.getClientWidth();
  Widget newUI = (width < 600) ? new DesignToolbarMobile() : new DesignToolbarNeo();

  if (currentUI != newUI.getClass()) { // Only switch if different
    container.clear();
    container.add(newUI);
    currentUI = newUI;
  }
}
```

Thank you so much for your guidance.

[Neil Aggarwal]

This may be a big change, but why not make it a browser-based app?  Then desktop, mobile, etc. are all able to use it without needing to download and install anything.

[divyanshu kumar]

I only want the best approach on how can we implement this feature...

Currently the issue is when user change the interface from mobile layout to desktop it will took multiple visit to sever which will be expensive...

--

You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-tool...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/76a45ad6-48e2-4a88-8966-c5d0ba985ac2n%40googlegroups.com.

[divyanshu kumar]

This is the problem I faced for a GWT application. I need the best approach to solve this:

The challenge is that the current design approach requires a complete page refresh when switching between UI layouts (for example, from a desktop view to a mobile view). This process means multiple server trips, which can be slow and use extra data—especially on mobile devices.

[Colin Alworth]

I think the ideas you are describing make sense, but the problem doesn't, at least to me. How will the user, having loaded the application on their desktop, now view the app on their mobile device, without also loading it there?

Is the use case that the user is actually a developer, and is resizing their desktop browser to be sized like a mobile app, and expecting it to behave as such?

Or somehow is the user "fooling" the app into thinking they are on one platform, and suddenly after page load it turns out they are on another?

That is, where is "step zero: detect what format the user is using to load the app" - perhaps, is this unreliable, and that could instead be the focus?

Also:what are the actual costs here to "reload" - why are multiple trips to the server required when a user, on the same device, needs to change from being on a mobile view to a desktop? If all users are subject to this ability to switch back and forth between views without changing devices (which obviously would require loading from the server), would it make more sense to include the layout differences in their initial load? How big are those differences expected to be, relative to the total cost of downloading the app? 

I can see how an application could split to have a mobile vs desktop permutation, and have the desktop version potentially be 20%+ larger than the desktop version, but there will be a substantial amount of overlap between these - so rather than loading X bytes then X*1.2 bytes, could the application just be a single permutation for both, and only be slightly larger than the desktop build was to begin with? Almost certainly there must be significant overlap with business logic and likely also there is some overlap in view code too. Note that this is the roughly the same "question" as "either separate uibinder views or media query CSS" - I suggest that this is a totally separate discussion, after the initial problem and tradeoffs are better understood.

Once the initial JS is loaded, what are the other round trip calls to the server that are required? I presume this might include loading data from the server that cannot be cached? Avoiding extra round trips is the purpose of caching, and if avoiding latency and data usage is one of your key design goals, some special care should be taken to make caching as effective as possible.

[Neil Aggarwal]

> Currently the issue is when user change the interface from mobile layout to desktop

> it will took multiple visit to sever which will be expensive...

 

I am not sure I understand your issue, but the browser should cache the UI files.

And if you design your application with intelligent caching for the data, it will only
go back to the server when something new is needed.

 

Thank you,

 Neil

 

--

Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com

We offer 30 year loans on single family houses!

[Jens]

From my experience the most drastic changes when reducing the screen size happen at the top level of the application which defines the general layout. For example imagine you have a desktop application and its basic layout (I like to call it shell) contains a header, two left side bars, one right sidebar, a footer, a content area and then a main menu with three levels of hierarchy and a secondary menu. This structure will change heavily when moving to mobile. Here you likely need Java code and separate views/logic to produce a new mobile friendly shell of that application. You can use the Orientation API to read and get notified about screen orientation, you can use the Media Query API to get notified about screen size changes and you can use both to execute Java code reacting to these changes and to modify the shell of the application. For example your primary and secondary menu are merged in a tree like menu and is hidden behind a burger icon. Or your side panels are now hidden by default and can be revealed using a touch swipe gesture from left to right or right to left.

Once that is done the actual content of each section of the app will usually change less dramatically. CSS media queries are usually enough (there might be some exceptions here and there, e.g. if you have to split a complex screen into multiple steps of screens).

It helps tremendously if you first do sketches on paper how the mobile app should look like and how interaction with that mobile app should look like. This gives you a better picture about the things you can reuse and adapt using media queries and which things require more work. 

Lastly you have to decide what better fits your needs:

- Do you switch from desktop to mobile to desktop within a single browser? Then media queries + events are better because you do not have to reload the page. However the app will be larger in general because it contains both the desktop and mobile code. Using GWT code splitting feature can help here. At the end the code will be cached once downloaded until you update the app to a new release.

- Do you have separate mobile and desktop devices and each should have its own fixed view and will never switch to the other layout? Then two applications (+ a shared library) might make more sense because each application is a bit smaller as it only contains the code required for that screen size. However code in the shared library will likely contain CSS media queries so it will never be a 100% separation, at least within CSS.

-- J.