Skip to content

Vienna Browser Implementation

Jump to bottom
Tassilo Karge edited this page Nov 12, 2020 · 1 revision

The (New) Vienna Browser

General

Vienna features a built-in browser. The main reason for its existence is that staying in the RSS application for reading articles and following links in them is more convenient than switching between the RSS application and a browser. It is not intended as nor will or can it ever be a fully-fledged browser. On the other hand, the Vienna browser must not be too crippled to be useful in most scenarios.

Requirements

RSS

  • Users may have various tastes when it comes to reading their articles, and different articles might have different formats. Therefore, RSS articles must render in the style of choice of the user.
  • Most RSS articles lead to a backing news story, blog entry, or other kind of content usually displayed in a browser. We will call that content the "full" article. The full articles must render in mostly the same way that they would in a fully-fledged browser.
  • To support the feed-reading style of opening all interesting full articles first, and reading them later, it must support opening more than one page at once.
  • Users may want to follow one or several links but with or without leaving the (full) article page.
  • The open pages must persist across sessions of usage, so users can continue reading at a later point in time or even keep pages they deem interesting open for longer.
  • Since the browser is not fully-fledged, in every situation it shall allow the user to switch to a fully-fledged browser of choice.
  • If a user is browsing and discovers a page offering an interesting RSS feed, he shall be given the opportunity to subscribe to it directly from the browser.

Additional browsing

  • Users may want to navigate to the page where they were before, or follow the link where they backtracked from again (forward-backward navigation).
  • Sometimes, URLs are given as text instead of an actual link, or the user wants to edit the URL he is currently at in order to navigate somewhere else. For that, the browser must allow URL input and display the URL where the user currently is.
  • Lazy and interruption of page loading for low-speed network situations
  • File downloads to the user´s computer

Implementation

Structure

Protocols -> Implementation files (new):

  • Browser -> TabbedBrowserViewController
  • Tab -> BrowserTab and extensions BrowserTabGui and BrowserTabRSS
  • RSSCommunication (RSSSource) -> BrowserTab and TabbedBrowserViewController
  • BrowserContextMenuDelegate -> TabbedBrowserViewController

Browser is the general interface for Vienna to communicate with its browser component. The Swift implementation, TabbedBrowserViewController, also serves as RSSSource for Vienna, as well as caller for a BrowserContextMenuDelegate that Vienna can provide it for context menu customization beyond the customizations performed by TabbedBrowserViewController.

The browser manages at most one primary and multiple browser Tabs via MMTabBar. It also provides the UI delegate for each of the contained webviews.

Tabs are implemented in Swift by the BrowserTab class. Each Tab contains an address bar and a web view. It takes care of loading URLs, showing the webpage status, and dealing with user input within the webpage or the address bar. It also listens to the status of a webpage and whether it has RSS content and customizes the address bar accordingly.

Notes

  • Each tab receives its title from a TitleChangingTabViewItem. The first tab is special, in that it can be any view adhering to the Tab protocol.
  • The first tab is always reserved for the article view (also to be transitioned to WKWebView)
  • Each tab (besides the first) contains its own address bar, back- and forward button, RSS button, reload/cancel buttons and a loading indicator, all customized to the current state of the WKWebView by delegate callbacks, key-value observation or javascript callbacks.
  • Opening a link without leaving the webpage (i.e. in a new page), opening a link in the default browser and potential other context-related actions are implemented via context-menu customization callbacks. The context menu customization callback is triggered by javascript events, transferred to a customized WKWebView, from there to the browser, and may be propagated to a delegate (currently the MainViewController).
  • Custom mechanism to store tabs and load tabs is implemented in TabbedBrowserViewController via NSUserDefaults storing an array of open tab URLs and tab titles (not ideal, since a crash will prevent saving the changes made in a usage session)

TODOs:

  • Button in the address bar to open current page in system default browser
  • Downloads?
  • ...?
Clone this wiki locally