Archive for January 9, 2018

Tuesday, January 9, 2018 [Tweets] [Favorites]

Unregistering Block-based NotificationCenter Observers

Ole Begemann:

Yes, you still have to unregister block-based observations manually (as of iOS 11.2). The documentation for removeObserver(_:) is at least misleading if not wrong.

[…]

When you do the unregistering in deinit, you must make sure not to capture self in your observer block. If you do, your deinit will never get called because the block retains self (preventing its destruction) and the notification center holds a strong reference to the block. Your object will live forever.

[…]

I suggest you write a small wrapper class for the observation token the notification center returns to you. The wrapper object stores the token and waits to be deallocated. Its only task is to call removeObserver(_:) in its own deinitializer[…]

Previously: NSNotificationCenter With Blocks Considered Harmful.

Pop-up Mobile Ads That Trap

Lily Hay Newman:

Ads that automatically redirect you from your daily browsing to a flashy sweepstakes have long been an incredibly annoying facet of the internet. But the versions that have evolved on the mobile web are particularly vexing, because they can trap you with a pop-up “notification” and nowhere to go.

These redirects can show up seemingly out of the blue when you’re in a mobile browser like Chrome, or even when you’re using a service like Facebook or Twitter and navigating to a page through one of their in-app browsers. Suddenly you go from loading a news article to wriggling away from an intrusive ad. What enables these ad redirects to haunt virtually any browser or app at any time, rather than just the sketchy backwaters in which they used to roam? Third-party ad servers that either don’t vet ad submissions properly for the JavaScript components that could cause redirects, or get duped by innocent-looking ads that hide their sketchy code.

[…]

Sometimes the ads are even designed to block your “Back” button, or keep redirecting when you try to close them, making it difficult to escape without having to restart the browser.

Even ads from top, reputable sites do this.

Using HTTP to Avoid Mixed Content Warnings From Ads

MyFitnessPal (via Matt Birchler):

Although our home page at http://www.myfitnesspal.com may not indicate the presence of https in your browser’s interface, the actual login “lightbox” or pop-over window on the home page does send your login credentials via https.

Once logged in, however, most data interactions on the site are not sent via https. This is a concession we have made in order to be able to offer our health and fitness tools for free. Our revenue model is mostly comprised of presenting advertising on the site. We work with a number of ad aggregation companies, and these partners serve their ads to us via http. As a result, we cannot serve most pages of the site via https without badly reducing the usability of the site. As but one example, many browsers and internet security programs are prompted to present warnings to users because of “mixed content” on pages of our site, when some content on a given page is sent via SSL and some is not.

Is there an advantage to the ad companies in not offering HTTPS?

The Kindle Moment: Fire and Fury

Kirk McElhearn:

You’ll note that the Kindle version currently costs more than the (unavailable) hardcover. This is a sort of surge pricing for books; why discount the hottest book of the season? It’s not a loss leader like the latest novels by Dan Brown or Stephen King, it’s a must-read that people want now, because it won’t be as interesting in a week, after many of the salacious elements are reported in the press.

It’s not often that a book like this drives demand so much that the publisher can’t keep up. Amazon is stepping in to help meet that demand, shifting a lot of readers from print to ebook. Even if they don’t have Kindles, they can read it on their phones or tablets.

I bet there are a lot of shared highlights.

Reverse-Engineering the iPhone X Home Indicator Color

Nathan Gitter:

  1. The home indicator’s color is determined by the system and cannot be modified directly.
  2. The home indicator’s color is determined by the content underneath, and it is not always a solid color.
  3. The home indicator on the simulator is not an accurate representation of the home indicator on a real device.
  4. The home indicator animates to its new color(s) when the content underneath changes.
  5. The home indicator is either in a “light” or “dark” state.

[…]

If a screen in your app has a background color in the middle range where the home indicator could be either light or dark, you may prefer one style over the other. If the status bar is white, for example, it may look more visually balanced if the home indicator is white as well. Being aware of the home indicator’s nuanced behavior can help ensure that it doesn’t accidentally animate between light and dark when it could be distracting to the user.