Since we provide a tab bar for top-level navigation, we don’t need that displayed here. We use it to hide many elements that are normally displayed on the mobile web that don’t make sense in the app. The bridge hides the top nav, breadcrumbs, and other elements we want render differently in the appĪbove is one example of the bridge in action. The mobile web is on the left, the app is on the right. Using a WKScriptMessageHandler, we can respond to messages sent from the web view through the bridge.īridge in action.
#Basecamp 3 app code#
This provides native code an API for communicating with the web view without needing to directly query the DOM or do complex JS. The primary code here is a local JavaScript file (written in TypeScript) embedded in the app and injected into the web view using WKUserScript.
This is a umbrella term for all the various parts of the app involved in native→web (or web→native) communication. The last component that makes up the hybrid architecture (though we have a number of other components not related to the hybrid part) is what we call the “Bridge”. Most view controllers are pushed on the current navigation stack, but we also support presenting certain screens (like new/edit views) modally, or replacing the current screen when appropriate. The router hands off a view controller off to the Navigator which handles the presentation. The router may open the url in Safari if it’s for another domain, display a media viewer if it’s an image/video, or in the common case, create a new view controller to display. This router is responsible for figuring out exactly what action to take for a given url. A url can come from a number of sources (web link, push notification, universal link from another app, native action, etc), and they all go through the Router. Most of our navigation in the iOS app is URL-driven. In addition to Turbolinks, we have a number of other components to support it. The framework handles communicating with Turbolinks.js and allowing the use of a single WKWebView, shared across multiple different screens.
#Basecamp 3 app android#
We use Turbolinks on the web, and our companion frameworks for iOS and Android let us use it in our native apps as well. The core library for enabling this hybrid architecture is Turbolinks. We only have a few dependencies, but the ones we do have we manage with Carthage. Under the hoodīasecamp 3 for iOS is written 100% in Swift 3.1 (soon to be 4), using the latest version of Xcode. Within those containers, we have many screens where the content is built using UITableView or UICollectionView, we have even more where that role is filled by a WKWebView. The building blocks of our app are composed of UINavigationController, UITabViewController, UISplitViewController, UIViewController, etc. We’re not using a framework that tries to compile another language to native code, or make a cross-platform app from a single codebase.įor us, it means using Xcode + Swift, and conforming to all the platforms conventions regarding navigation/presentation.
We’re not using a framework that attempts to mimic native controls using HTML/CSS. I explicitly say content there because it is an important distinction. In our use, we’re referring to standard native apps where a significant portion of the content is rendered using web technology. That term is used in so many different contexts, that it’s almost meaningless. Defining Hybridįirst, it helps to be clear about what we mean by “hybrid”. For Basecamp 3, we’ve replaced Objective-C with Swift, UIWebView with WKWebView and added Turbolinks, with even more native code, and a deeper integration between native and web. Next, we did a new universal app for Basecamp 2, written in Xcode + Objective-C, still a using UIWebView, but with a bit more native code thrown in. The first app for Basecamp 2 app was iPhone only, written in RubyMotion as a thin wrapper around UIWebView.
Basecamp 3 represents the latest generation of this architecture, taking everything we’ve learned from previous versions. We’ve written quite a bit in the past about our approach to building hybrid mobile apps.
0 kommentar(er)
