Frédéric Filloux:
It didn’t take long for Google to fire back at Facebook’s Instant Articles. While the two company strategies differ, they both impact the future of news content distribution on mobile platforms.
Five months: that’s all it took for Google to respond to Facebook’s mobile offensive. In Mountain View, where the response has been brewing, the product is called AMP – Accelerated Mobile Pages. Not a super sexy name, but it could have been worse: the project was initially called PCU for Portable Content.
[…]
How did Google achieve such loading speed improvements? Again, in plain English: “amp-html” strips off most of the conventional web page payload and only keeps the HTML code directly involved in content rendering: text, images, videos gifs, basic ad formats and a few strictly mandatory trackers. Everything else —javascripts, iframes, embeds, large chunks of the CSS etc.— known to slow down page downloads is shuttled to a separate “container”. As for ads, they load separately, usually one second after the editorial content. No more waiting for a promotional video to start playing.
To speed up access, the other trick is a massive caching process that looks like this[…]
Update (2015-10-14): Felix Salmon:
AMP is based on an important insight: that almost all of that evil advertising technology is written in JavaScript. If you create a new standard for mobile pages which essentially strips out all JavaScript, or at least banishes it to the bottom of the priority stack, then suddenly people will be able to read the web pages they want to read on their phones, on the go, without waiting first to be identified and tracked and sold off to the highest bidder.
[…]
Ultimately it all comes down to power dynamics. Advertisers and media buyers have more power than any individual publisher: they can demand more intrusive ads, more trackers, more scripts, and the publishers will simply comply, lest they lose precious revenue. We’re all living the painful results of that dynamic. But there’s one entity even more powerful than the advertising industry, and that’s Google. If Google tells everybody to turn those off those scripts, then those scripts will be turned off—and advertisers will be forced to compete on the basis of creative output, rather than technological firepower.
Update (2015-12-16): Todd Hoff:
AMP is two things. AMP is a restricted subset of HTML designed to make the web fast on mobile devices. AMP is also a strategy to counter an existential threat to Google: the mobile web is in trouble and if the mobile web is in trouble then Google is in trouble.
[…]
Will Google advantage AMP in search results? Not directly says Google, but since faster sites rank better, AMP will implicitly rank higher compared to heavier weight content. We may have a two tiered web: the fast AMP based web and the slow bloated traditional web. Non AMP pages can still be made fast of course, but all of human history argues against it.
Accelerated Mobile Pages (AMP) Advertising Google Optimization Web
Nick Heer:
Make no mistake: this is user-hostile. Facebook is actively creating channels to continue refreshing their app in the background when the user has explicitly stated that they do not want it to. Ironically, the best way to reduce the battery and data consumption of the Facebook app in the background is to switch Background App Refresh back on.
Federico Viticci:
Every time I take a look at a friend’s iPhone, Facebook is the app with the highest amount of battery usage in the background – even with Background App Refresh turned off. This has been going on for years, and instead of fixing the issue, it does seem like Facebook is always coming up with new ways to circumvent user control and consume more energy.
[…]
With iOS 9’s improved energy consumption stats, it’s easier to guess one of the various tricks Facebook may be employing to stay active in the background and drain battery. On my girlfriend’s iPhone, for instance, iOS 9 reports 5 hours of on-screen usage for the last 7 days, and another 11 hours of background audio usage with Background App Refresh turned off.
My guess is that Facebook is hijacking audio sessions on iOS by keeping silent audio in the background whenever a video plays in the app. And because, by default, videos on Facebook auto-play on both Wi-Fi and Cellular and few people ever bother to turn it off, that means there’s a high chance the Facebook app will always find a way to play a video, keep audio in the background, and consume energy to perform background tasks.
Lee Bennett:
Explains why I always have to force quit FB to regain ringer volume control. GRR.
Previously: iOS Background App Kludge.
Update (2015-10-14): Landon Fuller:
Where are the appstore reviewers? We’d need a jailbreak to independently investigate/confirm what they’re doing on our phones.
Update (2015-10-23): Ari Grant (via Paul Haddad, comments):
The first issue we found was a “CPU spin” in our network code. […] This repeated processing causes our app to use more battery than intended. The version released today has some improvements that should start making this better.
The second issue is with how we manage audio sessions. If you leave the Facebook app after watching a video, the audio session sometimes stays open as if the app was playing audio silently. This is similar to when you close a music app and want to keep listening to the music while you do other things, except in this case it was unintentional and nothing kept playing.
Update (2015-10-27): Nick Heer:
My understanding of the media APIs in iOS is that they will suspend operation when the app is backgrounded unless explicitly told to keep running. […] Whatever the case, it’s not working for Nate Boateng.
John Gruber:
Via Twitter, a few DF readers claim that the new version of the Facebook app still consumes a lot of energy in the background, even with background refresh disabled in Settings: General: Background App Refresh.
App Store Battery Life Facebook iOS iOS 9 iOS App iOS Multitasking
Robert McMillan (comments):
One day, Lauren was playing with the MIT command module simulator’s display-and-keyboard unit, nicknamed the DSKY (dis-key). As she toyed with the keyboard, an error message popped up. Lauren had crashed the simulator by somehow launching a prelaunch program called P01 while the simulator was in midflight. There was no reason an astronaut would ever do this, but nonetheless, Hamilton wanted to add code to prevent the crash. That idea was overruled by NASA. “We had been told many times that astronauts would not make any mistakes,” she says. “They were trained to be perfect.” So instead, Hamilton created a program note—an add-on to the program’s documentation that would be available to NASA engineers and the astronauts: “Do not select P01 during flight,” it said. Hamilton wanted to add error-checking code to the Apollo system that would prevent this from messing up the systems. But that seemed excessive to her higher-ups. “Everyone said, ‘That would never happen,’” Hamilton remembers.
But it did. Right around Christmas 1968—five days into the historic Apollo 8 flight, which brought astronauts to the moon for the first-ever manned orbit—the astronaut Jim Lovell inadvertently selected P01 during flight. Hamilton was in the second-floor conference room at the Instrumentation Laboratory when the call came in from Houston. Launching the P01 program had wiped out all the navigation data Lovell had been collecting. That was a problem. Without that data, the Apollo computer wouldn’t be able to figure out how to get the astronauts home.
History Programming
MacNN:
When asked for more details, Ryan told us that “several developers (including Mariner) participated in his bundle last year. It did relatively well, from what we could tell. After the bundle ended, Samuel/Dan/Isaac (he goes by many aliases) was to have paid said developers their share. That didn’t happen. We pursued him (and continue to), but since he is in the UK, the probability of ever getting funds is small.”
Additionally, Charlie Monroe, the developer of movie cataloging app Rottenwood, spoke to us about the matter as well. Monroe said that he had his app in one of the bundles: “I supplied licenses to the guy, everything. Never heard back from him, never got a response to any of my emails after the sale.”
MacNN has reached out to nearly all of the developers associated with MacBundler and Bundlecult offerings. We’ve received responses from eight other developers who have confirmed non-payment from Bundlecult-related bundles.
[…]
Mayer from CoreCode discovered that Bundlecult, Macbundler, creativeloots, mightyloots, oyoyo, poplytics, printplum, smugcase, futurestaff, and 99closets are all related to the lessprices.co.uk domain -- which was suspended Thursday morning for reasons as yet unknown -- but has returned since.
Update (2015-10-14): Mark Munz:
MacNN didn’t contact me, but I can confirm MacBundler’s stopped paying app developers as far back as Apr 2014.
Update (2016-04-10): MacNN:
There have periodically been bad actors among software bundle creators, and it has come to MacNN’s attention that there is likely another that has been running bundles for some time under the BundleCult and MacBundler names, amongst others. Does this all sound familiar? It should -- MacNN originally ran the story about the group and issues paying developers in October, and we’re reminding readers now about it, because another bundle by the same group has gone on sale today.
MacNN:
We have periodically since October tried to reach out to the organizer to get their side of the story, but have never gotten a response until now. MacNN has finally received an email, and had a brief exchange earlier today from Dan Kingsley, the self-proclaimed “curator” of MacBundler. In the response, we were given some information by Kingsley discussing the situation, but in doing so, it raised more questions.
Business Mac Marketing
