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: <https://community.appinventor.mit.edu/t/ui-design-feedback-request-responsive-mobile-phone-layout/142482/15#why-hybrid-2>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. <https://community.appinventor.mit.edu/t/ui-design-feedback-request-responsive-mobile-phone-layout/142482/15#how-it-works-3>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: > 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! > -- 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-toolkit+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/cc7789ea-c357-4900-804d-a7a2846d8ff6n%40googlegroups.com.
