How to switch between two UIs based on device?

[mmuurr]

Hi, I love the shinyMobile package and am eager to migrate a few apps I've written to mobile-friendly versions. The problem is that I'm also quite happy with the current desktop version of these apps. So I'd like to switch between keeping the existing (Boostrap-based) UI and the Framework7 UI based on device detection/clues.

One way to do this would be to create a generic page that has a single uiOutput element and let the server decide, and the f7page has the predefined input$deviceInfo data which could help ... but the f7page has already been set up, and really I'd want to potentially use a Boostrap fluidPage (depending on the device).

I could also implement a basic redirect page as a 'gateway' of sorts to /mobile or /desktop versions of an app, but that'd (without some other back-end gymnastics) mean running two apps instead of one with just two different client views.

Have you run into this situation before, where you'd like to use two completely different UI frameworks based on the device? And if so, how've you handled it?

Thanks for any advice!

[Seyphaton]

I tried some of your workarounds and I'm not really a fan of those solutions. If you figure out an elegant way to solve it please let us know.

[DivadNojnarg]

I would look into {tidymodules}. It allows you to support multiple UI's/server for a given project/app, through R6 classes: https://opensource.nibr.com/tidymodules/articles/tidymodules.html.

[cofrca]

Hi, I'm working on something similar and after reading this thread I've been learning more about {tidymodules}. Turning the existing apps into tinymodules has gone smoothly, but I'm running into trouble with the actual swapping of UIs. Most examples I've found define the app.R ui with some variation on:

ui = fluidRow(
    module1(ns1)$ui(),
    module2(ns2)$ui()
  )

I've tried a couple of things but I haven't been able to get the app.R ui = module1(ns1)$ui() OR module2(ns2)$ui() and not just display both inside a fluidPage. I might be missing something obvious for the swapping mechanism and will keep trying to figure this out, but has anyone gotten this to work already?

Thanks :)

[dmenne]

I had also looked at tidymodules, and decided not to take it into account because it has not seen any changes since 10 months. With a well-documented project, this typically is an indicator that it first was sponsored (here by Novartis), then the sponsor stopped supporting it, and the developer would have to keep it updated it on his own. Being in a similar situation, I know what an effort goes into maintenance of packages on CRAN (even if tidymodules is not on CRAN).

There should be some incentive for Novartis and Co to keep projects updated. shinyMobile was also initiated by Novartis. (Edit: see correction below)

[cofrca]

Thank you for your quick response. That makes sense - without direct interest and sponsorship (from Novartis in this case) the project relies solely on the developer's free time just to keep maintained and updated.

Understanding the situation a bit better, I am thankful for all of the time devoted to maintain and update {shinyMobile}.

[DivadNojnarg]

To clarify, {shinyMobile} has never been initiated by Novartis, nor sponsored. The development was started about 3 years ago by myself, 1 year before I joined Novartis.

Long term package maintenance is a common bottleneck in open source. Either you work for an open source company, and you are sure you can rely on the long term support, or you work as an isolated developer and it mostly depends on what happens in your real life.

The issue "Switch between 2 UI's based on device" has a broader scope than {shinyMobile}. It is actually a problem that should be solved upstream by {shiny}/{htmltools}. Interestingly, there is some movement in that direction: https://github.com/rstudio/htmltools/commit/056f634285481561162f2f1d8a405e4b5eed169d but I am waiting for more examples.

The solution I see could be that one: https://github.com/RinteRface/shinyMobile/issues/136 which leverage {brochure} by @ColinFay. Ideally, you would detect the user platform on the client and redirect to the specific page with a given UI. However, this POC was written long time ago and does not work with the new {brochure} and {shinyMobile} APIs. This would also add a substantial complexity layer.