I Managed to retrieve merchantSession object from Apple Pay server as below. I used Sandbox Test (Setup on itunesconnect and login the sandbox account on iphone and added tested visa card)
{
"epochTimestamp":15065...20,
"expiresAt":1506527672620,
"merchantSessionIdentifier":"2EF498A9E...C24",
"nonce":"f32....9",
"merchantIdentifier":"7941CB932...DE2",
"domainName":"mywebsite.com",
"displayName":"My Test Shop",
"signature":"30800609....0000"
}
However, in the Apple Pay pop-up sheet, it still stuck at "Processing", what do I need to do to able to process the next stage to show the "Touch Id"?
Also, below is my code snippet for onvalidatemerchant:
session.onvalidatemerchant = (event) => {
console.log("Validate merchant");
const validationURL = event.validationURL;
getApplePaySession(event.validationURL).then(function(response) {
console.log(response);
session.completeMerchantValidation(response);
});
};
Now if all the below are met, the payment sheet should be displayed on the iPhone. You should verify several things:
Your Mac and iPhone are connected to the same iCloud test account
Both are on the same WiFi
HandOff is on
AirDrop is on
Bluetooth is on
A simple check to see if they are connected is to open a browser on the iPhone/Mac and see it on the other device.
Related
Working on a Messaging Extension app for Teams that opens a Task Module in a Teams Meeting. This app is installed from the "Built for your org" section of the Teams store after being loaded into a Tenant by a Teams Admin. Any tenant user who has the app installed can select the messaging extension from the … menu in a Teams Meeting to initialize the Task Module.
Before initializing the Task Module, the app's bot must be added to the meeting chat so an "Add app" button is presented after selecting the messaging extension. This button sends through a payload with the justInTimeInstall value set to true. When a new Teams user who has never used the messaging extension before tries to tap on this Add app button on a mobile device, the button either does nothing and the user is returned to the chat (iOS) or an error page with a retry button is presented and the retry button keeps presenting the same error page (Android).
When examining a network trace of this button press, a 502 code is being returned with the following JSON:
{
"errorCode": 1008,
"message": "<BotError>Bot returned unsuccessful status code Forbidden",
"standardizedError": {
"errorCode": 1008,
"errorSubCode": 1,
"errorDescription": "<BotError>Bot returned unsuccessful status code Forbidden"
}
}
This combined with some other logging makes it seem like the response isn't even getting to the app's server. This is only a problem on mobile for a Teams user who hasn't used this messaging extension app. If the same user adds the app to the meeting from desktop/web, then they can come back on mobile and the "add app" button will work in any meeting from that point forward.
Is this a known issue or is there something that I might be missing here that's preventing the app from being added for new users on mobile?
i have a custom google home action implemented as described in the documentation (Oauth2 setup, sync, execute, etc... setup) and all works as expected on my Google home app and my google home physical devices.
Now, every now and then i need to reconnect the app in the Google Home App because it seems the app cannot reach my devices after some time. I checked my Oauth server if the refresh tokens are working ok and they do. Also my access token expires after 20 minutes and me reconnecting to the app should be done after some hours so the refreshing works in my opinion.
Now, are there any restrictions in using the TEST of the google home action?
The case i wrote is specific for personal use (intergration with personal server and domotica system) so i am actually not planning on releasing it, I just want to use it for myself. Is this allowed? Can i just leave my action in 'test' forever for such purposes?
EDIT: 18/05/2022: custom actions still working flawlessly after 6 months in test :-)
EDIT: 02/02/2023: custom actions still working flawlessly in test :-)
Additional question:
If i have to submit the app for release, i cannot meet the expectation in implementing state report as i have no control over the usage of buttons pressed at my home domotica. Is State Reporting also accepted when i report the state of my devices over time (let's say, every hour?)
tnx
EDIT:
So it seems there is something wrong with my refreshing of the tokens but i don't know what. When i try through postman, all works as expected, in stackdriver logs i see this :
jsonPayload: {
#type: "type.googleapis.com/google.identity.accountlinking.type.AccountLinkingError"
errorReason: "Failed to get response from 3P. 3P returned malformed response like invalid response code or un-inflatble body."
request: {
body: "grant_type=refresh_token&refresh_token=REDACTED_VALUE&client_id=qbusauth&client_secret=REDACTED_VALUE"
method: "POST"
uri: "https://******.azurewebsites.net/token"
}
sessionId: -1039956344
step: "REFRESH_ACCESS_TOKEN"
If you don't plan to submit your Action for release, you'll just need to occasionally re-enable device testing through the console.
To minimize the number of query intents to your fulfillment, you should implement Report State and proactively send device states to update HomeGraph. You would have to implement this if you decide to release your Action.
Is it possible to persist a Bluetooth LE connection on browser refresh? Or at least minimize the pairing time?
Eventually navigator.permissions.query would support this. Sample code from Web Bluetooth Specification
navigator.permissions.query({
name: "bluetooth",
deviceId: sessionStorage.lastDevice,
}).then(result => {
if (result.devices.length == 1) {
return result.devices[0];
} else {
throw new DOMException("Lost permission", "NotFoundError");
}
}).then(...);
However, no browser currently implements this.
As of Q3 2017 the chromium implementation is actively working on Web Bluetooth but not this feature.
I recently implemented a new permissions backend as well as two APIs that will enable previously permitted Bluetooth devices to be used.
The new permissions backend is implemented behind the chrome://flags/#enable-web-bluetooth-new-permissions-backend. The new backend will persist device permissions granted through requestDevice() until the permission is reset in Site Settings or the Page Info dialog box.
The getDevices() and watchAdvertisements() are implemented behind the chrome://flags/#enable-experimental-web-platform-features flag for Chrome 85.0.4165.0 or greater. The recommended use of these APIs is to use getDevices() to retrieve an array of permitted BluetoothDevices and then calling watchAdvertisements() on these devices to start a scan. When advertisement packets are detected from the devices, the advertisementreceived Event will be fired on the device that it corresponds to. At this point, the Bluetooth device is in range and can be connected to.
Please give this new feature a try, and file any bugs at https://crbug.com using the Blink>Bluetooth component.
I am configuring push notifications on for iOS using Xcode 7 and Parse. The notifications are working perfectly on a device running iOS 9.
But when running the application on a device with iOS 8, I am running into problems. I am unable to get the Alert View where the user can select to "Allow Notifications from App X".
But, the device token registration call is being called successfully when the user opts in to push notifications and the device is successfully registering an Installation object with a valid device token. Notifications are also being sent to the device.
If I go into Settings->Notifications->My App and turn the Notifications On or Off, it doesnt make a difference the notifications are still being sent through.
This is the code I am using to register for notifications:
let settings = UIUserNotificationSettings(forTypes: UIUserNotificationType([.Alert, .Badge, .Sound]), categories: nil)
application.registerUserNotificationSettings(settings)
application.registerForRemoteNotifications()
Found the solution here on stackoverflow... Registration for notifications are sent only once on devices running versions older than iOS 9.
As answered by another user here...
"The first time a push-enabled app registers for push notifications, iOS asks the user if they wish to receive notifications for that app. Once the user has responded to this alert it is not presented again unless the device is restored or the app has been uninstalled for at least a day."
OR
"If you want to simulate a first-time run of your app, you can leave the app uninstalled for a day. You can achieve the latter without actually waiting a day by setting the system clock forward a day or more, turning the device off completely, then turning the device back on."
Reference Links:
Push Notification ON or OFF Checking in iOS
https://developer.apple.com/library/ios/technotes/tn2265/_index.html#//apple_ref/doc/uid/DTS40010376-CH1-TNTAG42
I can´t make Apple Push Notifications work in development mode. The shouldSendPushNotifications method is never called on the source device when the target device is in background mode. I have uploaded my APN development certificate in the Sinch Dashboard and instant messaging works if both devices are in foreground mode. I have a valid device token which I´m using for my own Push Messages. Here is my code:
sinCli = Sinch.clientWithApplicationKey("XXXX", applicationSecret: "XXXX", environmentHost: "sandbox.sinch.com", userId: sinchUserId)
sinCli.delegate = self
sinCli.setSupportMessaging(true)
if let deviceToken = defaults.dataForKey(Globals.KEY_APN_DEVICE_TOKEN)
{
sinCli.setSupportPushNotifications(true)
sinCli.registerPushNotificationDeviceToken(deviceToken, type: SINPushTypeRemote, apsEnvironment: SINAPSEnvironment.Development)
sinCli.setPushNotificationDisplayName("MyApp")
}
sinCli.start()
sinCli.startListeningOnActiveConnection()
sinCli.messageClient().delegate = self
did I forget something?
I think I need to see your swift wrapper, but it almost looks like you are setting up the client for push (not managed), and then registring the token for managed push.
When using managed push (when you upload to cert to us) shouldSendPush is never called, because Sinch takes care of the pushing, you should just get a push. What you do need is to have a push delegate https://www.sinch.com/tutorials/ios-managed-push/