Xuzz

(I've used GraphQL at Facebook, but I don't work on it.)

If I understand your post correctly, I think it could. GraphQL prefers to expose full objects, rather than IDs, which lets you query for data inside objects at the same time. So for your example above, you would only need one GraphQL query:

  viewer() {
    posts {
      node {
        author { id, name, favorite_color },
        // any other post data you want
      }
    },
    friends {
      node {
        id,
        name,
        favorite_color,
      }
    },
    notifications {
      node {
        source { id, name, favorite_color },
        // any other notification fields you want
      }
    },
  }

The "id, name, favorite_color" is just a sample set of fields, you could replace it with whichever your components needed. Relay also has functionality to avoid duplicating the set of fields, which is especially useful when you want to add or remove a field from what a reusable component needs.

Facebook Groups is available for Android: https://play.google.com/store/apps/details?id=com.facebook.g...

Hey, I wrote HNKit.

I'll admit I haven't had time to write documentation. However, most everything follows Cocoa conventions, and the headers should be pretty readable. Absolute worst case, there's an existing app using the framework as an example. :)

You can also combine ARC and non-ARC code in one project. HNKit was written before ARC (although I still prefer manual memory management), but there's nothing keeping you from using HNKit with an ARC-based app. And unless you're modifying HNKit itself, you wouldn't ever need to see or write any retain or release calls as a client of the API. Apple did a pretty good job making ARC and non-ARC code interoperate well.

I'm happy to help with any HNKit questions — feel free to open issues on GitHub if there's anything confusing. HNKit already supports most of the things you are hoping to implement (logging in, commenting, voting), so I would hate to have all that effort duplicated. If you have any specifics about things that could be done better, I'm all ears.

Performance-wise, HNKit hasn't been optimized, but it does do parsing on a background thread. In general, a bit of extra local parsing is almost always going to be faster than additional network fetches. I haven't had any performance issues, even on older devices, so I doubt that part will be an issue at all.

Interesting: comScore had iOS up and Android down. I think all that proves is that these numbers are essentially meaningless. http://thenextweb.com/mobile/2013/04/04/comscore-apple-incre...

Those are also in an uncomfortable place to reach with your thumb when holding the device once-handed — and might even be covered by the thumb, depending on how you're holding it.

Think about everyone who doesn't see this post. Will they figure this gesture out? Did you? If it takes a blog post at the top of Hacker News for people here to find this, it's pretty far from discoverable. Is it really that great if most people can't use it?

On the other hand, you don't need any instruction for pinch-to-zoom. Intuitive interactions like that — or even double-tap-to-zoom — are much harder to come up with, but they're also accessible to everybody. This is a cool piece of trivia, but it's far from solving the one-handed zooming problem. I hope Google (or anybody else) is working on something to make this better for everyone.

How do you know that more about this than Apple does? I don't see any reason to believe they're lying, from what you said?

I think the actual number is 65536 or similar — the 3 million may have been a misquote by TechCrunch.

Try putting a different browser renderer on Firefox OS. You're pretty much locked in to JavaScript — unless you can somehow build WebKit with Emscripten, you're already behind what iOS can do — even with Apple's rules.

Counterpoint: as a developer, this looks awful.

For iOS: write an app, set a price, release it. For at least 90+% of potential customers, they have to pay for it. Piracy requires modifying the device in a way that Apple blocks.

For Android: write an app, set a price, release it. Anyone can easily pirate it, but it's still easiest to buy it instead.

For Firefox OS: write an app, set a price... then write a web service to do receipt checking? Integrate a library to verify purchases? That's a lot of critical code I now have to maintain, and is easy to get wrong. And my app now depends on having a server available (either mine or, it seems, a third party) to verify. And, of course, it's all JavaScript: patching it out is trivial for piracy.

I guess it's more "open" or something, but it just seems like more work for the same result.

The Phone app has a blue status bar in iOS 6.

Yes, and you will note I said "slightly faster CPU and GPU". The point is that the whole device is much more resource constrained, as what needs to be done with the CPU and GPU on the original iPad is more than on the iPhone 3GS, but the CPU and GPU are not faster enough to create the same effective performance.

Yes, raw performance may be better on the original iPad. But raw performance is irrelevant if you can't get the same effective performance for the user.

The iPhone 3GS is much faster than the original iPad. On the iPhone 3GS, you have a reasonably slow CPU and GPU, but you also only have 320x480 pixels to deal with. On the iPad, you have a slightly faster CPU and GPU (but still single core), but have to render to 1024x760 — way more pixels. You also don't have any extra RAM on the iPad, but your images and framebuffer still have to cover that extra area.

The net result is that the iPhone 3GS is much faster in practice than the original iPad (or the iPod touch 4G, which has similar issues to a lesser extent — but which they still sell, so can't drop support for). Another similarly underpowered device is the iPad 3, so I'd expect them to drop support for that even before the older iPad 2.

Yeah, but there's nothing stopping someone from porting JailbreakMe to 4.2.1 — it already works on 4.2.8 for the Verizon iPhone 4, and the other versions are similar enough. The hardest part would be the CPU (armv6 vs armv7), but it's clearly possible.

Removal of a specific exemption from a law is not the same as "becomes illegal". Do we have any clear reasons that this becomes illegal, or is it now just more of an unexplored gray area of the law?

It wouldn't be perfect, but the Google Now app could recognize that you're nearing an airport — something iOS does support, with background location updates — and then download the map data when it gets that notification. iOS apps can also share data between apps from the same vendor (via the Keychain, pasteboards, or various other mechanisms), so there wouldn't be an issue with passing that data over to the Google Maps app for offline viewing.

User location is available to background iOS applications; Apple includes two APIs specifically for that purpose: fine and course background location updates. The app will be notified whenever the user's location changes, if it's activated or not.

What APIs would something like Google Now need that don't currently exist? The only one I can think of is a way to launch it easier, rather than with an icon. But the push and local notifications, geo-tracking, ability to access your Gmail, and even the ability for Google Maps to pre-download map tiles are available to Google on iOS. What else does it need?

But your two cousins, who may have smartphones, could both have your grandmother as a shared friend — and thus, since they were both connected to you and were connected to your grandmother, Facebook assumed you might know your grandmother?

There's just an amazing lack of interest in the Surface altogether — except, apparently, from the freedom groups still upset about Microsoft while mostly ignoring the rest of the industry.

The reason the Apple TV 3 hasn't been jailbroken is because it provides a tiny attack surface. There's no web browser to exploit, and there's no iTunes syncing. So even when exploits have been found in various parts of iOS, most of those parts either don't exist or inaccessible on the Apple TV.

This is no different than on the iPad. And as with the iPad, finding a security hole to work around the signature requirements is very simple compared to actually porting Linux. Indeed, as the Surface is a new product, I'd guess it might actually be much easier to find such a flaw than it has been on the iPad — which has had multiple such flaws discovered and exploited (http://en.wikipedia.org/wiki/IOS_jailbreaking#Recent_release...).

No, you can easily block taking a screenshot, as long as (and as with Facebook Poke and Snapchat) you require a finger on the screen. I explain it here: http://blog.chpwn.com/post/38491252231

Yeah, probably. Anything that gets in front of the app should call one of those two, and do so pretty immediately. A timer for a second or so later should be pretty safe.

I looked into how SnapChat does it, it's pretty simple: http://blog.chpwn.com/post/38491252231

I wonder if they could use anything from the Magenta project, an attempt to make an iOS-compatible Linux implementation.

Website: http://crna.cc/magenta.html + http://crna.cc/magenta_source.html

HN discussion: https://news.ycombinator.com/item?id=4087224

Hybrid. You can select UI text everywhere from the message chrome to the settings page, so there's definitely HTML 5. But other parts are definitely native, like the label and account lists.

However, the screen is "PenTile" (http://en.m.wikipedia.org/wiki/PenTile_matrix_family), which means that each pixel is only 2/3 of what we'd usually think of a pixel. And it really does look like crap, even at high densities (such as on the Galaxy Nexus).

If you calculate out the number of subpixels (what actually shows colors on the screen, the important number), the 2048x1536 display on the iPad is still significantly ahead: https://www.google.com/search?q=2560*1600*2/3+-+2048*1536