In this method, the only modification in terms of coding is to change the enableBookmarking argument to the server. Let's recreate the square-calculation application using saving state to the server:

ui<-function(request){ 
  fluidPage( 
    textInput("inptxt","Enter Number"), 
    verbatimTextOutput("outsquare"), 
    bookmarkButton() 
   )  
  } 
server<- function(input,output,session){ 
  output$outsquare<- renderText({ 
    (as.numeric(input$inptxt)*as.numeric(input$inptxt)) 
  }) 
} 
shinyApp(ui,server,enableBookmarking="server") # saving to the server 

How does it make a difference in processing? Saving state to the server method saves the state of the application on the server instead of embedding the states into a URL. Shiny provides two versions of servers. One is the open source Shiny server, and the other is Shiny server pro. In Shiny server, the state of the application is saved in the /var/lib/shiny-server/bookmarks subdirectory. RStudio Connect also stores the bookmark state in /var/lib/rstudio_connect/bookmarks. We usually experiment with our applications on desktop versions of Rstudio. In such cases, the state is saved in the shiny_bookmarks/ subdirectory.

The advantage of using saving state in the server is that files can also be bookmarked, which is not possible with bookmarking with encoding. Large files are not supported by bookmarking with a URL. To save state on the server, the hosting environment must be supported.

As of now we have discussed bookmarking state for the apps having straightforward flow. But if apps don't have straightforward flows, we need to take some extra measures to deal with such situations. In a similar way, if apps have random-number generation and use that to generate output, then these methodologies won't work.

For such applications with complex state, use of callback functions is needed. Shiny has provided onBookmark(), and onRestore() to achieve callback functions. These callback functions take one argument, named state. We can use state$value to save and retrieve values to be bookmarked.

Let's develop an application that generates a random number and adds it to the inputted number. Here is the UI code for getting the input number using textInput(). It has one actionButton() for triggering the event of the addition, and bookmarkButton() for bookmarking:

ui <- function(request) { 
  fluidPage( 
    sidebarPanel( 
      textInput("txt","Number"), 
      actionButton("add", "Add"), 
      bookmarkButton() 
    ), 
    mainPanel( 
      h4("Sum of Random Number and Inputed Number:", textOutput("result")) 
    ) 
  ) 
} 

In the server code, we can see that the result variable is initiated to zero and a random-number generator, runif(), has been used. onBookmark() is used to save the result value in the state$values object. And onRestore() is using the same state object to restore the bookmarked value:

 server <- function(input, output, session) { 
  vals <- reactiveValues(result = 0) 
   
  # Save  values in state$values for bookmark 
  onBookmark(function(state) { 
    state$values$currentresult <- vals$result 
  }) 
   
  # Read values from state$values when we restore 
  onRestore(function(state) { 
    vals$result <- state$values$currentresult 
  }) 
   
  # Exclude the add button from bookmarking 
  setBookmarkExclude("add") 
   
  observeEvent(input$add, { 
    vals$result <- vals$result + floor(runif(1))+as.numeric(input$txt) 
  }) 
  output$result <- renderText({ 
    vals$result 
  }) 
} 
 
shinyApp(ui, server, enableBookmarking = "url") 

So, we have learned how to bookmark the Shiny app state in a simple, straightforward flow as well as in complex states. We also learned in which conditions encoding with a URL is to be used and when a save on the server can be advantageous.