We created a wallet pass and sent the wallet pass invitation email to end-users. However, there was an issue with the back-end APIs which prevented the Apple pass from automatically calling the device registration API.
The question I have is, do we need to re-inform all user to reinstall the Pass, or will the Pass automatically try re-registering by calling the device API.
Thank you.
The way you have worded your question possibly describes an impossible situation. A valid pass will always attempt to register. You state that your API was the issue, but an issue with a web service implementation would not prevent devices attempting to call it.
If the pass.json contains a valid https webServiceURL an authenticationToken, it will call the device registration endpoint after it has been added to the user's wallet. If the device does not get a 201 or 200 response, it will continue to retry, progressively backing off from every few seconds, to every few days for a period of around 2 weeks.
Therefore, if your pass.json contained the correct information; assuming that the issue was with your device registration endpoint and assuming that you picked up and addressed the issue quickly, then you should see device registrations coming in without having to do anything.
If it took longer than a couple of weeks or if you want to accelerate the process, you could ask your users to toggle the Automatic Notifications setting on the back of the pass. This will force the device to attempt a re-registration.
If however, the pass does not contain a webServiceURL, or if the webServiceURL was incorrect, then the device will not call back, or will call the incorrect endpoint. In this case, the only option is to have your users reinstall the pass. In this case, it is not your API that is causing the problem, but your passes.
Related
I'm trying to completely unregister a device token using the Urban Airship API (http://docs.urbanairship.com/api/), previously registered via an iOS device. I am doing this because I would like to verify the complete remote notification registration process.
There is a GET device_id endpoint:
GET /api/device_tokens/<device_token>
I was hoping there would be an endpoint like:
DELETE /api/device_token/<device_token>
DELETE /api/device_tokens (+send json data)
Maybe what I'm looking for can be achieved some other way? Or maybe this is an incorrect flow? I believe the old interface/API had this capability which is why I assumed it still existed.
Right now I'm relying on the "last_registration" value (from the GET endpoint) to inform me that the device has been registered, but I would like some way to completely remove the registered device/token via the API.
Doesn't work that way. Apple is the one the assigns and manages the lifecycle of device tokens. Urban Airship is a provider that handles the management/storage/utilization of said device tokens. Apple, however, is the one that manages the lifecycle of the device token based on the device and its actions. The best thing is to simply listen to the feedback to determine if that device token is still active or not. Apple's documentation on the matter is available here.
In regards to the old API; there was indeed a way to mark the device as inactive. However, as stated above, Apple manages the device tokens status. So, if the DT was indeed 'active' despite a delete/inactivate call was made on that DT, Apple would simply re-activate that DT, rendering that endpoint pointless.
What is the ejabbered behavior for user who is un-expectedly disconnected from internet
vs
user who explicitly sent an 'unavailable' presence?
Would they both be considered offline (for both single user chat or MUC)?
I want a behavior where if a user is disconnected from internet, offline messages to be sent
If user sent a explicit unavailble presence, I dont want offline messages to be sent.
How can that be accomplished? I can write my hook. But I need to know in which situations, the hook will be called.
When the user gets offline, the default behaviour is the same, no matter which method is used (explicit session close or unvoluntary disconnect). This is per XMPP specification.
If you want to customise the behaviour, it will not be easy as there is no way to know the reason why a user if offline.
What I would do: I would use the last module and support an optional reason for disconnect and store it. When you disconnect unvoluntarily, I would modify code to store reason being something like "timeout". When you disconnect explicitely, I would store another flag. When you get an offline message, you can then check the reason from being offline coming from mod_last storage.
I'm following the Quick Start Guide, as I've just received my credentials. I went through the coblogin and user (consumer) creation successfully. For test purposes, I was able to search and list sites and infos.
When I try to invoke addSiteAccount1 using the user session token for the consumer that I create, I get an HTTP 200 response and no apparent error, no exceptions or messages. The JSON response is basically the same as the one listed in the API documentation page, however there's no ID I can use to list transactions. I'm using a real login/password account information on Chase (site ID 643).
By the way, if I use random strings for credentialFields[0].value (username) and credentialFields[1].value (password), I get the same JSON response.
Please help me clarify what is not working here.
addSiteAccount1 API will give you a response which should contain "siteAccountId" field this is the identifier for that particular user's Chase bank site.
This siteAccountId will have itemIDs which resembles different 'container'(in Yodlee terminology) like, all saving and checking accounts comes under bank container,while credit card comes under credit's container similarly loan and mortgages are other containers.
Now even under a specific container you might have multiple accounts for e.g., Chase Bank container you might have 1 saving's account and 1 checking account, for each there will be an itemAccountId available. This uniquely identifies that specific account and you can pass this itemAccountId (which you can get from getItemSummariesForSite API) in executeUserSearchRequest API to get the transactions belongs to this specific account.
For further help here is the link for the API flow which will give you an idea about how and when to use different APIs.
OK, I think I got it working, but maybe some documentation clarification is needed. Provided that all mandatory parameters in the addSiteAccount1 are present and contain no errors, the method call will be successful for a given consumer.
I then visited the getAllSiteAccounts method, which would show me all account aggregation for that user/consumer. I was able to see all accounts added, some had a message like "REFRESH_COMPLETE" and others would have "AUTH_FAILED". It seems that once one adds an account, the Yodlee robots will try to login and then synchronize the data for a given account. Makes sense?
I was only able to verify if the bank credentials were OK by calling another method.
I would like to know what is the clean & correct way to notify my WP8 app that the ChannelUri has changed?
I read that i need to handle this in the ChannelUpdatedUri method. But i have a few queries here. Doesn't this require my app to be running all the time?
Second query is suppose i use ChannelUpdatedUri to listen for changes to the Uri. If there is a change will the app be notified as soon as it launches? Or will it be notified at a later time?
The trouble is if the app is not notified on launch then there is a possibility that it may re-register for a new channel uri before ChannelUpdatedUri is invoked. Isnt it?
Please help!
You'll only get notified of a change in the ChannelUri when you have the listener attached and the app running.
The best approach is to always check for the current Uri and pass it to the server when the app starts. You could leave the listener attached for the lifetime of your app and get a new one if it's lost while the app is running but in reality it's far more likely that the channel will be dropped/disconnected when the phone isn't in use.
There is, of course, the scenario where a channelUri may expire when the app isn't in use but the utility of the app is primarily around sending notifications. Obviously you need the user to restart the app to get a new connection but you can't tell them to restart the app.
This is a generic problem: how do you tell someone that you can't talk to them?
The reality of this situation is that if you really need to tell someone to launch the app again you'll need another way to do it.
Unfortunately, it's not possible to get an updated channelUri from a background agent, but you could query your backend to see if you need one and then raise a toast to the user to prompt them to reopen the app. Or you could just update the tile from the agent when this happens.
Alternatively you'll need to send them the prompt in another way (e.g. email or SMS?) but this is reliant on you capturing and securely storing these details.
There is no perfect solution to this scenario other than creating an app that the user opens regularly regardless of whether there are notifications or not and simply having the notifications as an extra feature.
We currently have an implementation that uses boxes API. Our authentication process follows the process outlined here:
http://developers.box.com/get-started/#authenticating
Sometime in the recent past this has stopped working. When we go to the oauth URL (for example, https://www.box.net/api/1.0/auth/rev37d850p6pixlemm5ok8doxj2g77kg), it will initially show the login credentials page, but faster than a user could reasonably enter their credentials the page starts returning "expired ticket". If I immediately go to the token's page after creating it I can reload the page a few times before it goes into the "expired ticket" state. This is clearly not consistent with the expected 10 minute expiry time stated in the documentation.
We've had this authentication working correctly up to now, so it seems like something has changed.
We are investigating. More news once we have some additional information.
New info>> We've identified the bug, and will be pushing a fix this afternoon.
The fix has been rolled out. Please let us know if you are still experiencing any problems with SSO.
Our Android app has the same problem. As far as I investigated it, using get_auth_token API causes the ticket to expire. So you have to make sure the user has successfully logged in BEFORE attempting to get the authentication token (which is not the case with Box SDK for Android). But I don't see a viable way to check whether the user has logged in.