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.

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.

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.