In my app, I get Lync Presence of our employees through UCWA. It works fine, but I need to knock to Lync with reportMyActivity every 3-4 minute.
I don't need to get presence info at night when employees are not at work, so I stop reportingMyActivity at the end of the working day and resume at it's beginning. Then trying to extend presence subscription, and if I get 404, I create new presence subscription. But no presence updates after those manipulations.
Is it designed to work this way? How could I avoid reportingMyActivity at night?
If you don't do reportMyActivity your Application will be drained, because assumed inactive.
I think you only have two options then:
Keep doing reportMyActivity regurarly also at night, you'll just stop extending presence subscription. Very likely you'll have to manage access token expiration too, which is normally 8 hours valid
You let the App shut down, and a complete new token acquisition, Application creation, presence subscription flow will start next morning
Related
I have a new iOS App with an auto renewing subscription feature.
I'm using the Mercato lightweight Storekit2 library.
I issue a start to the transaction listener in the AppDelegate didFinishLaunch along with a retrieveProducts(), activeSubscriptions(), and activeSubscriptionsIDs().
It all works, BUT: the validation of an active subscription does not asynchronously complete until well after the initial viewWillAppear().
Therefore it always starts off in non-valid display mode, and premium features are available to select by the time the user starts navigating.
Is there a faster way to get a validation upfront, or failing that, is there a way to post an event that a subscription test has completed, so I can display, then stop some sort of distracting, time wasting animation until validation.
In our design we have something of a paradox. We have a database of projects. Each project has a status. We have a REST api to change a project from “Ready” status to “Cleanup” status. Two things must happen.
update the status in the database
send out an email to the approvers
Currently RESTful api does 1, and if that is successful, do 2.
But sometimes the email fails to send. But since (1) is already committed, it is not possible to rollback.
I don't want to send the email prior to commit, because I want to make sure the commit is successful before sending the email.
I thought about undoing step 1, but that is very hard. The status change involves adding new records to the history table, so I need to delete them. And if another person make other changes concurrently, the undo might get messed up.
So what can I do? If (2) fails, should I return “200 OK” to the client?
Seems like the best option is to return “500 Server Error” with error message that says “The project status was changed. However, sending the email to the approvers failed. Please take appropriate action.”
Perhaps I should not try to do 1 + 2 in a single operation? But that just puts the burden on the client, which is worse!
Just some random thoughts:
You can have a notification sent status flag along with a datetime of submission. When an email is successful then it flips, if not then it stays. When changes are submitted then your code iterates through ALL unsent notifications and tries to send. No idea what backend db you are suing but I believe many have the functionality to send emails as well. You could have a scheduled Job (SQL Server Agent for MSSQL) that runs hourly and tries to send if the datetime of the submission is lapsed a certain amount or starts setting off alarms if it fails as well.
If ti is that insanely important then maybe you could integrate a third party service such as sendgrid to run as a backup sending mech. That of course would be more $$ though...
Traditionally I've always separated functions like this into a backend worker process that handles this kind of administrative tasking stuff across many different applications. Some notifications get sent out every morning. Some get sent out every 15 minutes. Some are weekly summaries. If I run into a crash and burn then I light up the event log and we are (lucky/unlucky) enough to have server monitoring tools that alert us on specified application events.
I am creating an application which has a follow mechanism where the followed user has to accept the request of a following (similar to private accounts on instagram).
I then want the following user to find out when the other user has checked a million times (every time the following user opens the screen if I did the query in viewDidLoad). However, the problem with this, is that there will be a lot requests which will expensive to me as I will have to pay for the requests to Parse so I want to minimise these queries.
Currently, the best thing I can think of is to check once a day at midnight for example but this doesn't seem very seamless.
Is there a better way of doing this?
For starters consider how stale you are willing to allow an app's view of the world to be and cache the response that long. If a user views that screen every 30 seconds you might only want to actually check with the server 5 minutes after the last successful response (or the last response which had 0 follow requests).
You might consider switching from this sort of "pull" polling where the client decides when to ask the server if anything has changed to a "push" model where the server can inform the client when a change occurs. For example you can send a silent background push notification to a user's devices when they have a follow request, the app can then respond by performing your existing query.
You might still want polling or user triggered requests (like a "pull to refresh" gesture) as a fallback for missed notifications or devices with notifications disabled but you should be able to drastically reduce request volume.
I am new to Facebook development and I am wondering how I can delay execution of an app notification by a given amount of time (days)?
At https://developers.facebook.com/docs/games/notifications or via Google I can't find anything regarding delaying notifications, everything seems to happen immediately.
What I am trying to achieve is that when a facebook app is loaded, I will add a notification to be executed in x days so that the user is reminded of returning to the app then.
I will do this every time the app loads, overwriting the existing notification that was still to be executed.
By that, the user will get the notification only when he really is not logged in for x days.
I'd like to solve that through Facebook alone and not through timers on the server. Can it be done?
There is no way to send delayed notifications, you need to do that on your own. For example, with a Cron Job that checks for the timestamp of the last login every day. Creating a new delayed notification (and deleting the old one) whenever the user logs in would be a weird solution anyway...Those things are usually done with Cron Jobs, there is no need to use the Facebook API when you don´t need it.
I have implemented som auto renewable subscriptions in my app and everything works well. I perform a purchase in the app, everything gets synced to a server, and the server then checks the iTunes API as soon as the subscription has expired to detect if the subscription has been renewed.
One thing confuses me though. Every once in a while I get a call to transactionsUpdated within my app with a transaction with status: Purchased. This is usually done after I restart the app.
Why do I get these calls? Has it something to do with the subscription beeing renewed? Can I safely ignore these calls? Everything seems to work fine.
Thanks in advance!
Yes, what Apple is doing is sending you a receipt for an automatic renewal of the subscription. Because all durations are drastically shortened in the sandbox, the subscription will get automatically renewed by Apple every few minutes, for a limited number of times (like 5), before they stop renewing.
Since you're already checking for new receipts at the right time on your server, you can ignore the receipts they're automatically sending to the app on occasion.