“Give me directions to foo” - gives directions to foo in apple maps
“Give me directions to foo using Waze” - gives directions to do using Waze
This might be new, but it definitely works on the iOS 13 beta, although I’m pretty sure it worked on iOS 12. It would still be nicer if we could just set default apps
Im two years in and I hate the keyboard. I actually didn’t hate it to start with because the bigger keys felt nice and I figured my accuracy would return after I got used to it, but it’s been literally years and I still make constant typos on this thing. I recently started using an external old-Mac-style keyboard and suddenly I can type without mistakes again, it’s honestly bizarre. Muscle memory wouldn’t last this long, there’s something about the newer design that just doesn’t work for me
> If I'm listening to a podcast on my phone, I'm going to have my phone on me. I'm not going to walk away from it because then I couldn't control the playback.
Every set of wireless headphones I’ve owned have let me control play/pause/skip from them, which makes up 95% of the playback controls I ever use. The last 5% I can do from my watch. Roaming about the house listening to stuff without a care where my phone is seems totally normal to me these days. I would never go back to wires now I’ve lived with the benefits of wireless.
FTR I was equally skeptic before I bought some cheap $10 Bluetooth earbuds to try running without wires tugging with every stride, and found myself wanting to use them all the time in spite of their awful sound quality so I bit the bullet and got some decent ones
A long press wouldn’t suffice, since you’d still need the second gesture (more pressure with the 3D Touch implementation) to switch from moving around a cursor to select mode (ie. moving around the second cursor). Not claiming 3D Touch is the only way it could be done, but a long press seems like it could only support a subset of apples cursor mode.
There's nothing "impure" about that. From Fielding's dissertation (emphasis mine):
"The key abstraction of information in REST is a resource. Any information that can be named can be a resource: a document or image, a temporal service (e.g. "today's weather in Los Angeles"), a collection of other resources, a non-virtual object (e.g. a person), and so on."
By the way, REST is not an ideology, it's an architectural style. It defines a set of constraints, and specifies the advantages and disadvantages of applying each of them.
And now your frontenders need to know how to write code in whatever your backend is written in, lest every new change be bottlenecked waiting for someone to build them new endpoints. Also, your backend guys are tied up constantly doing stupid endpoint changes, and both teams are wasting time messing around with extra effort to allow one side to be deployed before the other, instead of working on actual functionality work. Doing this in REST is a genuinely unpleasant experience, well deserving of being called hacky
> And now your frontenders need to know how to write code in whatever your backend is written in
Wat.
Frontenders can write their frontend code in whatever they see fit. REST is a contract on data and format of the data between frontend and backend.
> Also, your backend guys are tied up constantly doing stupid endpoint changes, and both teams are wasting time messing around with extra effort to allow one side to be deployed before the other, instead of working on actual functionality work.
Well, if your teams are dysfunctional, then of course, that's what you will end up having.
Now tell me:
- what will you do when your glorious ad hoc GraphQL query ands up bringing the database to its knees?
- what will happen when your glorious GraphQL schema doesn't have all the data the frontend needs?
> Frontenders can write their frontend code in whatever they see fit. REST is a contract on data and format of the data between frontend and backend.
Oh, it’s a contract? Amazing, I guess that means you can just update the contract and nobody is stuck doing busywork anymore. Nope? I guess then either your frontenders need to learn your backend stack, lest they be stuck waiting for someone to do the busywork for them. I feel like I’m repeating myself, because I am. Please don’t quote out of context
> Now tell me:
> - what will you do when your glorious ad hoc GraphQL query ands up bringing the database to its knees?
> - what will happen when your glorious GraphQL schema doesn't have all the data the frontend needs?
Sound like interesting, challenging, and satisfying problems for the backenders to work on. Certainly more so than adding/removing fields from serialisers. These also seem like much more rare problems than the small data requirement changes that are the backbone of frontend work.
I’d rather work on speeding up the things that slow down development and deal with performance when it becomes a problem. I dunno, maybe our experience differ, and in you world your app is relatively static and performance is crucial, but the world I exist in involves stakeholders constantly wanting minor changes, performance has never been a problem, and development is constantly blocking because of frontend/backend blockers on our “rest” api and capacity on either side being wasted at various times because of that blocking.
Sure, sometime someone’s going to write a horrendous graphQL query where the answer is going to be “sorry, we can’t make that perfomant so we have to disallow it”, but that’s a: solvable and b: going to happen a lot less often than your frontend is going to need an extra field (or no longer need a field, but since nothing breaks these change requests rarely come through and your backend is eternally querying and sending unused data over the wire)
> I guess then either your frontenders need to learn your backend stack
Why would frontenders need to learn the backend stack? Do you even know what REST is?
Riddle me this: what happens when frontend developers need data not exposed by the GraphQL schema? Do the need to learn the backend stuff as well? If not, why would they need that for REST?
> satisfying problems for the backenders to work on. Certainly more so than adding/removing fields from serialisers.
Because GraphQL automagically knows how serialize-deserialize any schema, riiiight.
> but the world I exist in involves stakeholders constantly wanting minor changes
So. How do you deal with those changes? Oh, let me see: you change schemas, you write new serializers/deserializers etc.
> development is constantly blocking because of frontend/backend blockers on our “rest” api and capacity on either side being wasted at various times because of that blocking.
For some reason you blame your failing processes on technology. Fix the process.
- what will you do when your glorious ad hoc GraphQL query ands up bringing the database to its knees?
With REST you can have an N+1 query, but you're making multiple round trips from the client to the server. With GraphQL, you can also write an N+1 query, so you can shoot yourself in the foot either way.
I would probably use graphql-middleware to log the backend calls, or just look at my backend's log, identify the N+1 query and instrument data loader to batch it out. But of course you should load test your app before even shipping it so why would you have this problem unless you do not test?
- what will happen when your glorious GraphQL schema doesn't have all the data the frontend needs?
I can add the field without impacting existing clients that I have shipped. With REST, the old clients would also get the new field.
- if your teams are dysfunctional, then of course, that's what you will end up having.
The point is that your teams can function independently of each other, each focusing more effort on doing their own job & less time syncing with the other team.
> With REST you can have an N+1 query, but you're making multiple round trips from the client to the server.
With REST I can specifically optimise the calls because I know the contract and the possible incoming/outgoing requests.
> I can add the field without impacting existing clients that I have shipped. With REST, the old clients would also get the new field.
Why are so many people discussing REST in GraphQL threads so oblivious of what REST is?
One word: versioning
> The point is that your teams can function independently of each other, each focusing more effort on doing their own job & less time syncing with the other team.
Don't blame your failing processes on technology. There's nothing magical in GraphQL that makes it a magical thing making teams independent of each other. Tell me: what happens when frontend team requests data that's not exposed in the GraphQL schema?
> Why are so many people discussing REST in GraphQL threads so oblivious of what REST is?
Why are you discussing graphQL you're oblivious to the problem it solves. Graphql obviates the need to version, like with REST. Facebook had that problem with 30k react components, their processes are fine. My processes are fine too, you are obviously just biased against graphQL. You can specifically optimize a graphQL query by the way.
Versioning creates an explosion of REST end points in fast changing code bases. GraphQL solves that problem. If you don't have that problem then don't use it. You don't need to insult other people who are explaining the benefits it had in their project. That seems oddly defensive of REST, which is the de facto transport for a GraphQL query (they aren't even mutually exclusive). This comment thread is like arguing what is the better fruit apples or potato. And potatoes aren't a fruit
I did not say that. That's a straw man. If you have the same problem as Facebook it is useful to consider the same solutions. No one is saying that all projects have the same problems as Facebook
You can still technically version a graphQL API just the same as with REST. I haven't heard of anyone having to do this. In practice you add new fields and stop using old ones incrementally.
The biggest benefit is a front end developer can mock up a new UI without waiting on a new backend endpoint. You can a/b test many variations of your UI without a plethora of ad hoc end endpoints
Apple has never sold updates for iPhones. What you’re misremembering is them selling updates for iPod touches back at iOS 2 because of some perceived accounting issue, and the cost was pretty token, something like $5-10 IIRC correctly. Hardly a cash cow that would have had them making more optimisations then they do today
> the convenience of Apple Pay seems to be moving backward as I'm forced to use my PIN and sign in all sorts of places I used to be able to just wave my phone at.
This is a rant against how you imagine things work, instead of how they actually work. I put my watch on in the morning and it is automatically unlocked the next time I unlock my phone with touch id. From this point on, the pin is never required. Apple Pay is just a double click on the long button, no pin entry as you've imagined if the watch is unlocked, which is true unless you've only just put on the watch.
waiting for the face to light up however, is a legit complaint. It really sucks that there's not even an option for "always on" that you could use while working out, as it's a pain in the ass to be running and want to check your current pace and find that wrist-flick detection failed so you're staring at an off instead of getting the data you wanted and getting back to looking where you're going quickly again.
How can a retailer ask for a PIN number on an Apple Pay transaction? They don't even know what account the money actually comes from, since Apple Pay only gives them a one-time use number for that single transaction. So how can they verify a PIN number in that context?
My experience using Apple Pay with a checking account's debit card at Whole Foods Market and Trader Joe's is that it only saves having to swipe/insert the physical card. I'm still required to enter the pin. Sometimes it gives me the options of "VISA Debit" or "US Debit" which both work the same way. A few times I've gotten lucky and it gives me the option of "Credit" or "Debit" and when I pick "Credit" it's a toss up -- probably driven by the amount of the transaction -- on if the transaction is complete or if I have to "sign" with the stylus on the POS.
Canadian? I'm betting this is a terminology collision—US debit cards use credit-card protocols to talk to banks, while Canadian debit cards ("ATM cards" or "client cards") use their own protocols for POS transactions, which Apple doesn't even bother supporting.
Instead, to support Canadian debit cards directly, Apple would seem to be using the Canadian banks' web payments infrastructure (Interac EasyWeb)—which is effectively a SAML auth flow using your card number + PIN as credentials.
Before this mechanism was introduced, Apple did first support Canadian "Visa debit" cards, though, so earlier Canadian users of the system—who have their phone pointed at a Visa debit card number they have, instead of their debit client-card number directly—might be confused by the assertion that Canadian debit card use on Apple Pay requires a PIN. It doesn't, for them.
I have the same experience as @TomSawyer, when a retailer supports NFC payments, but doesn't specifically support Apple Pay, it's hit or miss if it will require a PIN # or not for debit card transactions. For Credit Card transactions it doesn't always require a signature, but it does sometimes.
The retailer doesn't know what account, but the bank DEFINITELY does know.
I can't speak for the other commenters, but for me it's because my browsing style was formed back in the days of dialup in Australia. You'd click a link and wait 30+ seconds to have the page load, so instead of staring a loading page you'd open anything that looked interesting in a new tab and continue on the current page, so all the interesting links would be there ready to read without waiting. invariably you wouldn't end up having enough time to read them all, but they piqued your interest enough to open them, so you'd keep them around in the hope that some time later you would. Rinse, lather, repeat, and add in persistent browser sessions between restarts and suddenly you've got 100+ tabs open.
The internet is much faster these days, but I still open way more links than I actually have time to read because they sound interesting
I do that with HN actually. I visit between a few times a day and once every second day. I open whatever I think is interesting. Usually 1-10 tabs every time I go to HN. then I spend time in one or two tabs and read a lot, and close these two. Then I still have 8 tabs open.
Second step is repeat.
Third step is I have 400 tabs open.
“Give me directions to foo using Waze” - gives directions to do using Waze
This might be new, but it definitely works on the iOS 13 beta, although I’m pretty sure it worked on iOS 12. It would still be nicer if we could just set default apps