# Flipboard The official Flipboard engineering blog This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Serving VAST Video Ads Across Flipboard Platforms DevFeed: [Serving VAST Video Ads Across Flipboard Platforms]() Original publisher: [Read original article]() Author: https://www.linkedin.com/in/guangle-fan-13496731/ (Guangle Fan) Published: 2017-05-30T00:00:00Z Content type: article Language: en Sources: [Flipboard]() Topics: [XML](), [Back end](), [Website](), [Android](), [iOS](), [samsung]() Tags: [android](), [backend](), [ios](), [samsung](), [video](), [web](), [xml]() ### AI overview This article explains VAST, an IAB-published XML schema for serving and tracking video advertisements, and describes Flipboard's backend-centric approach for handling VAST ads across multiple platforms. ### Source excerpt Videos are more ubiquitous than ever before: there are virtually no boundaries on how, when and where people can interact with video content. Flipboard as a curation platform brings multi-format content to peoples around their personal interests and passions. There has been tremendous opportunity for video ads to perform efficiently on our platform. At Flipboard, we have been building video inventory since 2013 in the form of transcoding, storing, and serving proprietary format video ads on an in-house platform. As we see high-quality beautiful video ads satisfy advertisers, we also face the challenge of scaling the platform to meet the increasing demands of our video ad inventory. To bring Flipboard's video ad inventory to a larger group of advertisers, we need a programmatic selling channel that supports standard video ad formats, provides easy performance measurement and flexible video behavior control. This is where VAST can help. What is VAST ? VAST is the Video Ad Serving Template published by IAB. It is a universal XML schema that gives video players information about which ad to play, how the ad should show up, how long it should last, and whether peoples are able to skip it. It's important because it lets video players and ad servers speak the same language. Before VAST, advertisers had very little information about the publisher's player implementation. It also allows ad platforms to easily exchange ads with each other. For example, a physical video media file can be hosted at Service A, and passed through a chain of Services B, C, D, and served to consumers on publisher platform E. Each service will be able to wrap the ad with its own event trackers for performance measurement. VAST has been the most adopted video ad standard by advertisers and publishers, and the prevailing version is VAST 2.0. How do we serve VAST ads ? At Flipboard, we have ad inventory across our iOS, Android, Samsung Briefing, and Web products. The way some publishers implement a VAS ## Detecting Trustworthy Domains DevFeed: [Detecting Trustworthy Domains]() Original publisher: [Read original article]() Author: https://www.linkedin.com/in/mikecora/ (Mike Vlad Cora) Published: 2017-04-12T00:00:00Z Content type: article Language: en Sources: [Flipboard]() Topics: [Machine Learning & Artificial Intelligence](), [Python](), [scikit-learn](), [AI Development]() Tags: [article](), [blog-post](), [data-pipeline](), [engineering](), [machine-learning](), [ml](), [python](), [quality]() ### AI overview Flipboard describes its Domain Ranker, a machine learning system that predicts how its editorial team would label domains. The article focuses on the engineering work behind the system, including live data pipelines, feature engineering, and classifier experiments using scikit-learn in Python. ### Source excerpt High quality, truthful, diverse and informative content is Flipboard's #1 priority. Hand-picking trusted sources guarantees quality, but is very time consuming, and can potentially miss out on the multitude of excellent but smaller publishers. To address this problem, we've developed a machine learning (ML) system called the Domain Ranker. Its goal is to automatically distinguish authoritative domains from plagiarists, spammers and other low quality sources. It learns to predict how our editorial team would label a domain by analyzing the content and the signals generated by our users. The Domain Ranker scales our editorial thinking to a much larger amount of content than we could handle manually, ensuring high quality across all topics. Overview Flipboard has indexed hundreds of millions of articles in the last year alone. In addition to the constant stream of articles from our trusted partners, any user can add any web article into their personal magazines, further expanding Flipboard's pool to non-partner publishers. Our community support and editorial teams are constantly battling the endless churn of spam sites. Through their efforts, we have identified thousands of labeled spam domains, alongside thousands of partner and whitelisted publishers. The Domain Ranker is a machine learning system that uses this labeled data to learn and generalize our editorial thinking to unlabeled sources. In this blog post I do not delve into the theory behind any of the machine learning classifiers used. They are all well known, off-the-shelf implementations in the scikit-learn Python library. Instead I will focus on the engineering journey: managing the live data pipeline, exploring and engineering reasonable features, and experimenting with a multitude of classifiers to maximize accuracy. I compare an ML project to an open-ended "Choose Your Own Adventure" book: every path leads to an almost unlimited number of forks, fraught with perils and rewards. There are many paths that ## Clustering Similar Stories Using LDA DevFeed: [Clustering Similar Stories Using LDA]() Original publisher: [Read original article]() Author: https://www.linkedin.com/in/arnab-bhadury-a6304768 (Arnab Bhadury) Published: 2017-02-08T00:00:00Z Content type: tutorial Language: en Sources: [Flipboard]() Topics: [Algorithms, Complexity](), [Algorithms](), [data]() Tags: [algorithm](), [algorithms](), [clustering](), [trimming]() ### AI overview This article explains how Flipboard uses a clustering algorithm and Latent Dirichlet Allocation (LDA) to group related stories into multi-source story roundups. It discusses challenges including high-dimensional text representations, differing word usage, unknown cluster counts, and the need for fast updates. ### Source excerpt There is more to a story than meets the eye, and some stories deserve to be presented from more than just one perspective. With Flipboard 4.0, we have released story roundups, a new feature that adds coverage from multiple sources to a story and provides you with a fuller picture of an event. Here's how it looks: With our scale of millions of articles and constant stream of documents, it's impossible to generate these roundups manually. So, we have developed a clustering algorithm that's both fast and scalable, and in this blog post, I will explain how we create these roundups on Flipboard. Why is this difficult? Although there are many sophisticated automatic clustering algorithms, such as K-means or Agglomerative clustering, story clustering is a non-trivial problem. Because each text document can contain any word from our vocabulary, most text document representations are extremely high-dimensional. In high-dimensional spaces, even basic clustering or similarity measures fail or are very slow. Additionally, two very similar documents often have very different word usages. For example, one article may use the term kitten and another may use feline, but both articles could be referring to the same cat. Furthermore, we don't know the number of roundups that we expect to see beforehand. This makes it difficult for us to directly use parameteric algorithms such as K-means. Our clustering algorithm also needs to be fast and easy to update, because there is a constant stream of documents coming into our system. Overview Since even the most basic distance measures fail in high dimensions, the first thing we do is lower the problem's dimensionality. We represent each of our text documents as a bag-of-words, and remove stop-words and rare words from our vocabulary. Even after an aggressive trimming, the documents are still very high-dimensional. We then we use Latent Dirichlet Allocation (LDA) to further lower the documents' dimensionality. We use LDA because this algorith ## iOS Meetup DevFeed: [iOS Meetup]() Original publisher: [Read original article]() Author: https://twitter.com/timonus (Tim Johnsen) Published: 2015-09-09T00:00:00Z Content type: article Language: en Sources: [Flipboard]() Topics: [watchOS](), [iOS](), [App]() Tags: [apple](), [apple-watch](), [apps](), [community](), [developers](), [event](), [hiring](), [ios](), [video](), [watchos]() ### AI overview Flipboard hosted a Palo Alto iOS Developers meetup focused on developing apps for watchOS 2. The event included a talk by Ben Morrow, a presentation about Flipboard's WatchKit app, and a complete video recording. ### Source excerpt Flipboard was honored to host a meetup of the Palo Alto iOS Developers group about developing apps for watchOS 2 at our office in Palo Alto last week. Ben Morrow, writer of the Happy Watch blog and host of several Apple Watch hackathons, gave a talk deep diving into various aspects of watchOS 2. We also gave a short talk sharing a bit of the story about how we built our WatchKit app and what we've got in store for watchOS 2. A photo posted by Flipboard (@flipboard) on Sep 3, 2015 at 11:29am PDT We'd like to thank Mike Suprovici and the community for giving us the oppourtunity to host this event. Here's a complete video of the meetup P.S. We're hiring! ## Introducing PSync DevFeed: [Introducing PSync]() Original publisher: [Read original article]() Author: https://github.com/hzsweers (Zac Sweers) Published: 2015-09-08T00:00:00Z Content type: article Language: en Sources: [Flipboard]() Topics: [Android](), [gradle-plugin](), [Gradle](), [Java](), [XML](), [Code]() Tags: [android](), [code](), [gradle](), [gradle-plugin](), [java](), [open-source](), [xml]() ### AI overview Flipboard introduces PSync, an Android-specific Gradle plugin that generates Java representations of XML preferences. The plugin reduces the boilerplate required to mirror preference values in code and supports both library and application projects. ### Source excerpt Here on the Android team at Flipboard, we have a lot of settings for users to adjust their experience. If you throw in internal settings, we have about 100 total preferences to manage. This is a lot of boilerplate to maintain, because preferences in Android have no built-in synchronization (unlike Resources). Our 1 PreferenceFragment class has a couple hundred lines of boilerplate fields at the top where we keep in-code mirrors to these preference values. This design is tedious, brittle, and requires a lot of overhead to keep in sync with XML. We developed a Gradle plugin called PSync to solve this problem. PSync is an Android-specific Gradle plugin that generates Java representations of XML preferences. These Java classes can then be used directly in your code. The generated code is very much inspired by how 1 R.java works for resources, and should feel familiar to developers. It's easy to use, has some simple configurations for fine-tuning your generated code, and is ready to drop into both library and application projects. A full overview can be found on the GitHub README, but here's a quick preview: Say you have a preference: 1 2 3 4 You can reference it like this: 1 2 3 4 5 6 7 8 9 String theKey = P.showImages.key; boolean current = P.showImages.get(); P.showImages.put(false).apply(); // If you use Rx-Preferences P.showImages.rx().asObservable().omgDoRxStuff! // If you need it boolean theDefault = P.showImages.defaultValue(); The generated Java code looks like so: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 public final class P { public static final class showImages { public static final String key = "show_images"; public static final boolean defaultValue() { return true; } public static final boolean get() { return PREFERENCES.getBoolean(key, defaultValue()); } public static final SharedPreferences.Editor put(final boolean val) { return PREFERENCES.edit().putBoolean(key, val ## Presenting BottomSheet DevFeed: [Presenting BottomSheet]() Original publisher: [Read original article]() Author: https://github.com/emilsjolander (Emil Sjölander) Published: 2015-06-04T00:00:00Z Content type: article Language: en Sources: [Flipboard]() Topics: [Android](), [ui](), [Material Design](), [Open Source](), [GitHub]() Tags: [android](), [components](), [filter](), [github](), [interaction](), [material-design](), [open-source](), [sorting]() ### AI overview Flipboard introduces BottomSheet, an open-source Android UI component for presenting views from the bottom of the screen with interactive dismissal and animations. It also releases IntentPickerSheetView, which provides filtering and sorting for activities handling an intent. ### Source excerpt We are happy to introduce BottomSheet a new Open Source Android UI Component! At Flipboard, we love building visually stunning and highly interactive UIs. When building these UIs, we tend to build them as fairly stand alone components. This makes it very easy for our developers to implement a similar interaction model and aesthetic across the whole product while working in parallel. BottomSheet is a UI component we developed to facilitate a new interaction model for saving an article to one of your magazines (otherwise known as "The Flip UI"). The result of our efforts is a design you can now see in the current version of Flipboard. BottomSheet fits perfectly with Google's Material Design aesthetic as well, matching their Bottom Sheet specification. We think this component is great for displaying many types of views, from a simple intent picker to something as complex as the example shown from Flipboard. In its simplest form, BottomSheet can be used to show any view in a sort of modal UI that's presented from the bottom of the screen can be interactively dismissed. At Flipboard, we think it's very important that things feel responsive, and having interactive animations is an important part of this. Apart from providing a component for presenting views in a BottomSheet, we have also have a module for common views developers might like to present in a BottomSheet. The first such component we're releasing is the 1 IntentPickerSheetView. This sheet view is initialized with an intent and will show a grid of activities that can handle the intent. It works very similarly to Android's built in IntentChooser, and looks very similar to the picker used in Lollipop and above. There are a couple of ways in which our implementation improves upon the system intent chooser: It can be interactively dismissed, making it feel much more responsive. It adds an easy-to-use API for filtering and sorting the activities shown. Ever wanted to filter out the Bluetooth activity when adding sha ## Image Scaling using Deep Convolutional Neural Networks DevFeed: [Image Scaling using Deep Convolutional Neural Networks]() Original publisher: [Read original article]() Author: https://twitter.com/normantasfi (Norman Tasfi) Published: 2015-05-06T00:00:00Z Content type: article Language: en Sources: [Flipboard]() Topics: [Deep neural networks](), [Machine Learning & Artificial Intelligence](), [Image](), [Algorithms](), [Web](), [Mobile]() Tags: [algorithms](), [architectures](), [deep](), [image](), [machine-learning](), [mobile](), [neural-networks](), [pixel](), [presentation](), [web]() ### AI overview This engineering article examines image upscaling for Flipboard and introduces convolutional neural networks alongside traditional interpolation methods. It explains how enlarging low-resolution images can produce pixelation, smoothing, noise, haloing, and other artifacts, and outlines the model discussion, preliminary results, design decisions, and possible product applications. ### Source excerpt This past summer I interned at Flipboard in Palo Alto, California. I worked on machine learning based problems, one of which was Image Upscaling. This post will show some preliminary results, discuss our model and its possible applications to Flipboard's products. High quality and a print-like finish play a key role in Flipboard's design language. We want users to enjoy a consistent and beautiful experience throughout all of Flipboard's content, as if they had a custom print magazine in hand. Providing this experience consistently is difficult. Different factors, such as image quality, deeply affect the overall quality of the presented content. Image quality varies greatly depending on the image's source. This varying image quality is especially apparent in magazines that display images across the whole page in a full bleed format. When we display images on either the web or mobile devices they must be above a certain threshold to display well. If we receive a large image on our web product we can create breathtaking full bleed sections. Full bleed High Quality Image Lower resolution images introduce pixelation, over smoothing and artifacts when scaled above 100%. This is especially apparent in a full bleed presentation as seen below. This severely reduces the quality of presentation in our products. Full bleed Low Quality Image What is the cause of this? In general, when we need an image of size X that is required to be of size Y it must be run through a scaling algorithm. This algorithm performs a mathematical operation to scale the image pixels to the desired size Y. Some of the possible algorithms are bicubic, bilinear, and nearest-neighbor interpolation. Many of the algorithms listed above perform an interpolation between pixel values to create a transition. These algorithms use the surrounding pixels to guess what the missing values should be in the new image. The problem in the case of scaling the image to a larger size is when there are too many 'new' values ## NSUserDefaults Performance Boost DevFeed: [NSUserDefaults Performance Boost]() Original publisher: [Read original article]() Author: https://twitter.com/timonus (Tim Johnsen) Published: 2015-03-16T00:00:00Z Content type: tutorial Language: en Sources: [Flipboard]() Topics: [iOS](), [Caching](), [Open Source](), [Extension](), [GitHub]() Tags: [apple](), [cache](), [extensions](), [github](), [ios](), [open-source](), [performance]() ### AI overview This article explains that iOS 8 simulator performance problems were linked to synchronous disk I/O while emulating cfprefsd. It describes an in-memory write-through cache for NSUserDefaults that reduced the reported time spent in CFPreferences from 80% to 1%, with possible side effects when debugging extensions. ### Source excerpt Since iOS 8 was released we've noticed some sluggishness when using Flipboard in the simulator. When taking a trace with Instruments in normal use we noticed a significant amount of time was being spent in 1 CFPreferences. On Twitter, an Apple engineer acknowledged that there were some changes in iOS 8 that added something called 1 cfprefsd, and that emulating that in the simulator required synchronous reads from disk. This seemed to be the bottleneck we were encountering. @timonus unfortunately cfprefsd doesn't currently exist in the simulator, and emulating its behavior requires synchronize disk IO -- David Smith (@Catfish_Man) January 21, 2015 @timonus it's on my list to fix, but it's a large effort and device took priority -- David Smith (@Catfish_Man) January 21, 2015 About a month ago we were talking as a team about how slow we felt our app had become to debug in the simulator, so we decided to try to do something to speed it up. Our approach was to introduce a man-in-the-middle write-through cache to 1 NSUserDefaults in memory. We do so by swizzling out all of 1 NSUserDefaults' setters and getters and adding a per-instance 1 NSMutableDictionary to cache values. We avoid compiling this for device builds using 1 TARGET_IPHONE_SIMULATOR because there aren't such performance issues on device. The increase in performance is dramatic, where we were once spending 80% of our time in 1 CFPreferences we're now spending 1%. If you're seeing performance issues related to 1 NSUserDefaults in the simulator I recommend trying this out, it's open source and available for download on GitHub. To get started using it all you need to do is include it in your project. Please note that use of this category may cause side effects when debugging extensions. This is documented in the GitHub project. ## Introducing GoldenGate DevFeed: [Introducing GoldenGate]() Original publisher: [Read original article]() Author: https://twitter.com/emilsjolander (Emil Sjölander) Published: 2015-02-24T00:00:00Z Content type: release Language: en Sources: [Flipboard]() Topics: [WebView](), [Java](), [JavaScript](), [Library](), [LineageOS]() Tags: [android](), [java](), [javascript](), [library](), [type-safety](), [webview]() ### AI overview Flipboard introduces GoldenGate, an annotation-processing library for Android that generates Java wrappers around JavaScript code used in WebViews. The library provides compile-time type checking for calls across the native-JavaScript bridge. ### Source excerpt You might not know it, but both Flipboard for iOS and Flipboard for Android make heavy use of web views. We use web views so we can ensure consistent designs for our partners' articles across all platforms. Communication between native code and the JavaScript code running in a web view is something that is both tedious to implement as well as very bug prone as it's mostly just string concatenation. Today we are releasing a library to make this task easier when developing Android applications which use web views. GoldenGate is a annotation processing library which generates java wrappers around your JavaScript code. An annotation processing library is a piece of code which runs when you compile your code and has the ability to generate new java classes. This means that GoldenGate can ensure at compile time that you are sending the correct types into the JavaScript functions you define in your bridge. If you're interested in knowing more about how to write your own, this blog post is a good intro. Let's get into a quick example to really show the power of the library! First of all a quick example of how to currently call a JavaScript function in a WebView. 1 webview.loadUrl("javascript:alert(" + myString + ");"); You should clearly see that a lot can go wrong here which the compiler won't catch. For example you could misspell 1 alert or maybe 1 myString isn't a string at all. GoldenGate allows for the compiler to have your back. The same code as above written with GoldenGate looks like this. 1 2 3 4 5 6 7 @Bridge class JavaScript { void alert(String message); } JavaScriptBridge bridge = new JavaScript(webview); bridge.alert(myString); We started by defining an interface which describes the JavaScript methods we want to call from java. This interface is annotated with 1 @Bridge which is where the magic happens. This will generate a class named 1 JavaScriptBridge in this case which implements all the methods defined by the interface. There are a couple more options for ## 60fps on the mobile web DevFeed: [60fps on the mobile web]() Original publisher: [Read original article]() Author: https://twitter.com/bapjuseyo (Michael Johnston) Published: 2015-02-10T00:00:00Z Content type: article Language: en Sources: [Flipboard]() Topics: [Mobile](), [Web](), [Canvas](), [CSS](), [Document Object Model (DOM)](), [ui](), [HTML5]() Tags: [canvas](), [css](), [html5](), [jank](), [mobile](), [performance](), [smartphone](), [touchscreen](), [web]() ### AI overview Flipboard describes bringing its mobile-first experience to the web and explains how it optimized scrolling and animation performance. The article discusses the limits of DOM updates during animation and considers hardware-accelerated HTML5 Canvas for building a user interface. ### Source excerpt Flipboard launched during the dawn of the smartphone and tablet as a mobile-first experience, allowing us to rethink content layout principles from the web for a more elegant user experience on a variety of touchscreen form factors. Now we're coming full circle and bringing Flipboard to the web. Much of what we do at Flipboard has value independent of what device it's consumed on: curating the best stories from all the topics, sources, and people that you care about most. Bringing our service to the web was always a logical extension. As we began to tackle the project, we knew we wanted to adapt our thinking from our mobile experience to try and elevate content layout and interaction on the web. We wanted to match the polish and performance of our native apps, but in a way that felt true to the browser. Early on, after testing numerous prototypes, we decided our web experience should scroll. Our mobile apps are known for their book-like pagination metaphor, something that feels intuitive on a touch screen, but for a variety of reasons, scrolling feels most natural on the web. In order to optimize scrolling performance, we knew that we needed to keep paint times below 16ms and limit reflows and repaints. This is especially important during animations. To avoid painting during animations there are two properties you can safely animate: CSS transform and opacity. But that really limits your options. What if you want to animate the width of an element? How about a frame-by-frame scrolling animation? (Notice in the above image that the icons at the top transition from white to black. These are 2 separate elements overlaid on each other whose bounding boxes are clipped depending on the content beneath.) These types of animations have always suffered from jank on the web, particularly on mobile devices, for one simple reason: The DOM is too slow. It's not just slow, it's really slow. If you touch the DOM in any way during an animation you've already blown through your 16ms