Contact Picker, Fullscreen, & Payment Requests

[00:00:00]
>> Contact Picker, that sounds pretty cool. I'm not sure if it's too useful, unless you have a social network, but it sounds interesting. So with this API, we can read contacts from the user's database. This is mainly targeting mobile devices, because on desktop, you don't have a contact default app, but on iOS and Android it works.

[00:00:23]
On iOS it's an experimental API, so you need to enable it manually, on Android it works. You define the properties that you wanna get, like I want the name, the email, and the phone number. If you want one, the user should pick one or multiple, so you won't get the database.

[00:00:39]
The user will see a dialog, and he will pick one or more contacts. And based on user selection, you will get back into the contacts variable the array of contacts that the user picked, okay? What are you going to do with that is your problem. So it's not about the API.

[00:01:01]
So you get the email, you send that to your server, it's up to you. Fullscreen API, this is the one that we have been using in Cookie Masters. Because we were starting the cookie, then it was going full screen. It's actually simple, you just take a domElement, a div, a section, and you call requestFullscreen.

[00:01:25]
There is only one bad part here, Safari uses prefix. Remember I mentioned that we were about to see two API's with a prefix, this is a second one. So it's domElement.webKitrequestFullscreen, okay? You can get the current fullscreen element with document.fullscreenElement, and you can exitFullscreen element at any time.

[00:01:51]
In this case we are exiting from. Remember we were using the gamepad, and it was pushing a button that was exiting the fullscreen, well, I'm just calling that. And also, you can check the event fullscreenchange, because the user can typically get out of full screen with the Escape key.

[00:02:09]
Or on the phone dragging from the top, or maybe doing some gesture or something. And in that case, based on the user, you will get that event fire. Make sense? So going back to our code in, This is actually in Cooking.js. We have here the event handlers for fullscreenchange, and also for webkitfullscreenchange for Safari.

[00:02:45]
And then if we search here, this is where I'm requesting full screen. First, I'm verifying if requestFullscreen exists in Cooking.root, it's actually an element in the DOM. If it's there, I'm executing that function, if not, I'm verifying if the prefix version exists, and then call it. And something similar when you disconnect the full screen.

[00:03:13]
That's the only part that is tricky. But fortunately for all of you that are doing this workshop today, these are just the two API's with that problem. Ten years ago, most of the APIs were prefixed, and also CSS were prefixed. So every call to a capability API was actually really complicated.

[00:03:39]
Lot of version, we had the ms prefix for IE, we had the moz prefix for Mozilla, and the webkit prefix. Payment Request API. So this is an API that will let the browser be in the middle between you, actually the user, your user, and a payment processor. So we have the merchant, that's you, that's us, the user, and a payment processor.

[00:04:12]
Can be PayPal, Stripe, companies that are working with credit cards, debit cards, and are doing this stuff. The API is in the middle. So also, on iOS, you can use this API to use Apple Pay. But also Apple has its own JavaScript library, in case you wanna use Apple Pay separately.

[00:04:35]
So you can use Apple Pay. Apple Pay is the ability that some countries, or Apple has in some countries, only to actually pay with Touch ID or Face ID on your phone or your laptop on Safari. So we are not going to see the code directly, I'm just going to give you the idea, why?

[00:04:58]
Because unless you are working at the payment processor, typically you don't use this code directly. You use an SDK, a library, from Stripe or Paypal or other payment processors, and you just use it. They are using the Payment Request API, not you directly. But actually the idea is that the site will call the API directly or through a library.

[00:05:29]
We are here, then the browser UI and native dialog, such as the one you see here, will collect the payment details, credit card, all the stuff. And then it goes directly, the browser passes that response, to the processor site, okay? Actually, you as a web developer, you will never see the credit card details, that's the idea.

[00:05:55]
So we as web developer, we won't get the credit card numbers or anything. The idea is to avoid that. And also because it's targeting native dialogs. For example, on Android, you can have your Google Wallet set up with your credit card. So it's just a one tap to buy, you don't need to type any credit card or anything.

[00:06:18]
And on Apple Pay, it's just putting your finger or putting your face and accept the payment, and typically that's all. Okay, so that's the capability today on every browser, payment request.