(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.
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.
Didn't mean for that to come off rude if it read that way. I haven't dug too far deep into HNKit - I was really just worried about the interplay of ARC and nonARC code and what that meant for the future of maintainability of my own codebase (really for things that go multiple classes deep, I didn't want to introduce retain cycles and the like).
I'm considering creating a branch of this with HNKit and starting to build that in to see how it plays with everything I have now.
Except for the fact that comScore knows what it's doing while this article doesn't. I'm gonna trust comScore on this one because it just makes sense. The iPhone 5 came out and HTC, Motorola, and Samsung's new flagship phones have yet to be released yet.
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.
In usability tests you'll see that pinch-to-zoom is hardly discoverable, or even particularly easy. It's a learned behavior.
Once users "get it", it's powerful. They'll attempt to pinch to zoom all over the place. I guess I don't see how this is any different. It's a gesture, and I find it to be intuitive (it's been available on the Android version for a really long time).
Apple has been teaching gestures to people through marketing. I always thought that was brilliant. Gestures are not at all discoverable, but if you show them often enough they become natural. Most of Apple's TV ads, especially those for iOS devices, are little tutorials.
It is, however, a bad idea to rely on that. I see gestures as I see keyboard shortcuts: not intuitive at all, but potentially great time savers once you learned them.
For those making touch UIs this means, quite simply, that you always have to be able to do something without gestures or that if a gesture is essential, it has to be taught to you.
I agree. The intuitive way to zoom in is to move your face closer to the screen. Pinching a screen makes absolutely no intuitive sense. People learned it by accident or because they were shown.
Test I've previously conducted as part of product development. I've, anecdotally, have heard similar reports from others as well when we've shared data.
Are you sure your two year old didn't watch you first?
My 18 month old niece was the same with my brother's iPad, being able to navigate back to the home screen, find the YouTube app, go to history, watch something from the list, full screen, rewind and go back to the history once the video had finished. She has now picked up using Android on Samsung Note II pretty kid. Kids are just really intuitive and learn very quickly by watching at that age, I was truly amazed since my 60 year old parents on the other end of the spectrum have great difficulty understanding this tech.
While I completely agree that the default controls need to be intuitive, I am also of the opinion that these little hidden gestures, these shortcuts, are not necessarily bad. I agree with John Gruber when he says that:
"... gestures are to iOS what keyboard shortcuts are to Mac OS — an alternative way to do something as a convenience for advanced users." [1]
I understand that this gesture doesn't solve the problem of one-handed zooming for everyone, and that the solution will need to be more obvious to include everyone. It's just that a more obvious solution may add unnecessary clutter.
There isn't anything particularly intuitive about the pinch to zoom gesture. Most of us already knew about it because we saw the iPhone keynote when it was originally released. I still meet people that own new-ish iPhones (4/4S etc) that aren't aware you can actually zoom in/out in the Maps/Photo etc apps.
People keep saying it's not intuitive, but stretching something by the exact distance you pull your two fingers apart seems pretty intuitive to me. It is a new gesture so it wouldn't have occurred to me to do it the first time, but that doesn't mean it's not intuitive. Something that's not intuitive would be a gesture that doesn't seem obvious even after you demonstrate it.
One of the biggest things I've despised about the mobile paradigm, and something I think apple helps foster, is that instructions and tool tips are mostly gone. Everything is supposed to "just work" but I wind up finding useful features I didn't know about months later.
There has always been a "one handed zooming" solution, but as we see in this thread, people don't see/like those buttons. http://i.imgur.com/TfaGExu.png
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.
You can also zoom in by double tapping on the map. This gesture usually performs a "centered zoom" meaning that the current center of the screen will remain the center of the screen after the zoom has taken place (unlike when zooming with the pinch gesture).
I agree. You can do an unzoom using a two-finger tap as well, and it much more memorable. It still doesn't qualify for intuitive, nor does it solve the one-handed unzoom problem though.
It would be a lot more discoverable if this "mode" were indicated on use - ie, some zoom overlay (even just a highlight) that showed that they'd activated it, and when it disappeared. It's almost a quasimode [1] - since it disappears when you let go - still mode indicators would be very useful here.
I suspect a great number of people here either don't use iPhones, haven't upgraded to iOS6, or don't use the special google maps app (I'm on 5.1.1 on a 4S, and the maps app that comes with the phone does not do this)
Or you could be completely wrong. This is hn, not some Amish blog. The hn crowd update their apps, compile their own kernels and don't use old hardware. Life's too short.
I personally did not update my phone iOS from 5.x to version 6 until Google released their Maps application about 4-6 weeks after the major version upgrade. I know of at least 2 other people that also did not update for the exact reason that they did not want to use the Apple/TomTom maps and directions.
obviously not IOS kernels, it was a generic comment, linux kernels, compile from source, keep up to date, use chrome not the browser that came with their machine etc etc. It really wasn't that hard to understand.
Actually, after rereading, Apple just says they generate X amount of solar, and that the datacenter is 100% renewable, leading dumb people like me to assume that the datacenter is 100% solar. But since they never say how much energy the datacenter needs, that's not supported by the facts... I assume they are actually supplementing the solar with purchased renewable energy.
He doesn't. The energy at the NC datacenter is a combination of solar, fuel cells driven by biogas†, and grid power offset with purchased clean energy credits‡.
␄
† This doesn't mean that the methane molecules entering the fuel cell came from the biogas facility. The biogas gets pumped into the natural gas system, and gas comes out at the Apple spigot, but no one tags and sorts the methane molecules in between. That would be silly.
‡ Which means they pay a premium to cause renewable energy to be produced. If tagging molecules was silly in the gas section, there isn't even a physical thing you could tag on the grid. The electrons only move back and forth a few inches in the wires, and joules aren't “real”. A lot of the joules going into that grid are cheap coal, a tiny bit of them are the more expensive renewables. Apple is paying to put enough renewables in to cover their use.
So there is a special thing called "renewable energy" which travels over the same grid as ordinary energy. It can be substituted for ordinary energy (but not vice-versa) and commands a premium price over ordinary energy.
Hydroelectric power is considered "renewable" for what seem like good reasons. Yet, if I lived next door to Hoover Dam I would not expect to be charged extra for the privilege of consuming its locally-grown renewability. In fact, I would expect to pay less because there would be less transport loss to offset.
I'm trying to figure out to what extent this amounts to Apple writing a check to someone to bless their electricity, much like the selling of indulgences.
There's a pool of generators that put energy onto the grid. Each one has a price per MW generated (or MW/$)
Generation is metered and consumption is metered.
So the consumer will say "bill me for the cheapest one" or "bill me for renewal one" (or better, contract a certain amount of power from 'FlowerPower Gen'), and the producer will have "I'll have to produce X MW to provide for contracted demand"
Producing renewable energy gives you credits which represent a cost difference between regular electricity and renewable.
The actual renewable electricity counts as regular energy, and anyone across the country can buy credits to say they subsidized renewable energy somewhere.
I'm wondering where's the ROI for a for-profit corporation in "buying credits to say they subsidized renewable energy somewhere" other than, say, Marketing?
When one sets out to write checks to charities the Hoover Dam isn't exactly the first to come to mind.
Still seems like a ridiculous number, though of course far less ridiculous especially for Java code with its legacy of setters and getters for even basic properties and FactoryOfFactoriesFactory classes.
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.
In Firefox OS, the browser is the OS. It'd be like saying you can't replace Dalvik in Android.
It's not about replacing the browser, it's about being able to replace things that you should be able to. There is no good technical reason to not let people replace Safari on iOS.
Not so sure about your last sentence. Can a replacement browser be any good without using JIT compilation somewhere? Is the sandbox going to allow it to jump into dynamically generated data? Are there any valid technical reasons for having sand-boxing in the first place?
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.
It's just as easy on Firefox OS. Writing a web service is not required! Mozilla provides one for you :)
BTW, both iOS and Android require servers to be available for purchase checks unless, as the app developer, you don't care about piracy (which might be legitimate for the "most people will buy it" argument).
As for JavaScript being easy to patch. Is it really easier though? You can literally copy around apk files or search for them on pirate sites to get paid Android apps for free. There are videos on youtube for how to Patch paid iOS apps with fake certs and DNS hacks.
Actually - on Android, if you want to 'verify' that your app was not pirated (i.e. the paid-for APK was not just copied from one device to another), you have to call their licensing service: http://developer.android.com/google/play/licensing/index.htm.... Of course, many paid apps choose not to add this additional layer of verification, but it is functionally similar to the Firefox OS solution (except with a web app, you don't even need to copy an APK - you just visit it on the web).
You can't compare JS patching to someone spending hours and hours finding methods for using fake certs and DNS hacks. Sure the end result may be similar but to get to their requires a A LOT less more. Anyone can open up a JS file, find a line of code that does security checking, and return it false. You can show someone that in a Youtube video. What you can't show someone is how to spend hours and hours looking for ways to trick the OS into believing that the packaged application was previously paid for even though it wasn't.
Obfuscated and minified JavaScript with license checking scattered in diverse places will be much, much harder to figure. And it'll vary from app to app, while with Apple devices if you've stolen one you've stolen them all. (I think that's the effect?)
I'd disagree with the last part. The majority of Android apps do no certificate checks, so it's pretty much as easy as Googling "<paid android app> apk" and clicking the first result. You can even do it on your phone if that's easier.
I think you are correct about opening up JS files though. Are there any good security measures against that?
Doing what you suggest would take "hours and hours" too, as you have to find a way to make the app run your modified JavaScript instead of the one that it retrieves from the server.
Libraries and services to manage this will appear. Mozilla are running their own, which most will probably use. (Think how Google runs the Play Store, but others can run Android app stores too. It's just that this will be far more open than that.)
Patching out code is something that's easy to do in anything while it's centralised. That's why you get do doing things like adding in a license checking macro in various places in many desktop apps: if you remove this check, that one may well still be there.
Just because it's in an ostensibly human-readable language doesn't mean it's human-readable or easily modifiable.
>> Libraries and services to manage this will appear. Mozilla are running their own, which most will probably use. (Think how Google runs the Play Store, but others can run Android app stores too. It's just that this will be far more open than that.)
It's an important point and outlines the differences in Mozilla's approach. The same applies for Mozilla Persona. The cost of openness is building a system that's loosely coupled and then adding the glue afterwards to make it easy for many.
It's quite the opposite of closed systems and you have to see the longer term vision to understand why Mozilla starts out with this type of solution.
@chrismorgan, it might go a long way to include the plans for a "hosted" version of the open model as a convenience layer. Most won't make that leap themselves.
My tentative design for the FFOS app I'm working on is to have only the rendering code delivered; the rest is requests out to my web server, which then frontends all the interesting stuff. In other words, it's going to effectively be a web page with some strange Javascript.
Honestly, I don't think it's going to be a problem... the magic is all going to happen on the backend: the frontend is going to be (relatively) simple code. Essentially just enough to call out to the backend and render the results. The entire thingie is going to be simple.
I'm not sure how Mozilla is going to handle users, etc, and how I can get that information transferred into my system so that users can get into their account from a regular web browser as well as the web app from their device. I need to figure that out, but I'm not there yet. The sales & user accounting systems are probably going to be 3-5x more troublesome than the actual program.
Mozilla Persona will be baked into FirefoxOS and the FirefoxOS Marketplace, thus it probably makes sense to use it for your regular browser users, too. https://login.persona.org/
I don't think the Content Security Policy for standalone Firefox OS apps allows that. I think it is all or nothing; you are either a packaged and self-contained 'privileged' app, or you are a web app that is loaded from the web.
The way pnathan described his app, systemXHR doesn't seem to make sense for it. You usually only need systemXHR when you are writing an app that talks to a third-party server that you cannot control and that you cannot convince to enable CORS. systemXHR also has different handling of cookies and HTTP authentication credentials.
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:
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.