I just recently started diving into GetStream to add newsfeed capabilities to our Mobile App.
What is the best-practice for handling inactive users? We have a mechanism in place that allows us to identify inactive users, so we can prevent sending emails and other notifications to these users.
I would rather inactive user feeds not receive feed-updates without having to unfollow.
Does getstream have any mechanism available to mark a feed as inactive so as to prevent it from being updated?
Related
I want to send web push notifications to registered users, are there any best practices on how to implement the cases when multiple users have access to the same device and one should not see the message of another user.
Thanks in advance.
A web push notification subscription is tied to the browser, not the device.
What you need to do is, map this id with your registered user when he logs in from a particular browser. Also, you need to remove the subscription id mapping with any other users in the system.
In the case of multiple users using the same browser, the above logic will make sure that at a time, a particular browser subscription id is linked only to a single user.
And when you want to send a notification to a registered user, you can retrieve all push subscription IDs linked to this user in your database, and trigger notifications to those subscription IDs.
And don't forget to unmap a subscription id when the user logs out from a browser. Otherwise, he will continue to receive all notifications even if he has logged out.
We are using the EnvelopeView: CreateSender endpoint on the server side and are authenticated under a service account we have dedicated for this process. Ultimately, we send a URL such as https://demo.docusign.net/Member/StartInSession.aspx?StartConsole=1&t=<GUID>&DocuEnvelope=<ENVELOPEID>&send=1 back to the end user to pick the signers, and populate tags.
All works fantastically, however, we were hoping to make it so the user can only see and populate the information for this single document. Currently, once the user clicks the link they are essentially authenticated as our backend service account and if they open another tab in their browser and go to (https://demo.docusign.net) they can see all documents and even change the password of the account if they wanted.
Is there a way to restrict this in any way? Would the experience be different if purchased an “API” account not tried to use an actual user account on the backend? Yes, we know about OAuth, but we don’t really want to impersonate the sender and prefer to keep a dedicated service account.
An "API" account would give you the same issues as dedicating one of your current users as a "Services Account," so I don't think that's a solution.
Instead, I suggest that you move all of the functionality that's needed upstream into your app. That way you will not need to present the Sender view to your users.
Your app can enable your users to:
choose who the envelope will be sent to
choose/edit the email messages, etc
choose the documents that will be sent
etc
If you have preset templates that include the document tabs/fields for the signers then there is no reason for the sender to deal with the sending screen for picking the tab/field locations on the documents.
This type of app will also give a smoother user experience to your users since they'll stay in your app rather than bouncing over to DocuSign for part of the task.
I need to add push notification in my web site
If a user has made payment for something... we show them alert in their account page on the website that you are now successfully connected to this community
If a user has done payment by check... we clear the payments by check through a cron job... once the job runs and payment is cleared... we show a notification to user whenever they log in saying that their check payment is cleared
A user sends a request to connect to an organisation... that organisation's admin should get an alert in their system saying that so and so person is pending approval from you.
Something similar to alerts that we get in our net banking might be... that your credit card payment is pending... something like that
Like we also get notifications on Facebook... the difference will be that instead of notifications we want to show alerts or messages directly displayed in their account
So, you want notifications in your system about payments.
In its simplest form, you could do it manually with emails, and/or popups in your application, that are loaded from DB when they login. This is sort of a manual system, and the Minimum Viable Feature could be quite easy to build yourself.
If you want it more advanced, like you mentioned, similar to Facebook's notifications button and feed. Then, yes, it might be easier to use getstream.io. It also has websocket integrations so you can get those notifications pushed in real-time. You can then also push other types of notifications in there, like for example: a notification when the user has logged in from a different browser (for security reasons).
I hope this answers your question.
Using Instagram's API, is there any way to request a list or count of an application's registered users?
Instagram's real-time subscriptions can send notifications whenever a registered user posts to their feed, but I haven't found a way to get a list of those users, or even a count. This is easy enough to store server-side, but seems like something which should be discoverable.
Your Question
Using Instagram's API, is there any way to request a list of an application's registered users?
A quick search yielded no results for such a functionality. This make sense, though, since Instagram wouldn't want to open up all its users to any app designer.
Your App
If you want the number of users using your app, then you can easily track this yourself.
Instagram App
As mentioned before, Instagram probably won't provide even basic count information about its registered users. Presumably, this is valuable information.
Your Example
Instagram's real-time subscriptions can send notifications whenever a registered user posts to their feed...
This is true, but with very limited scope. The subscriptions below are based on users who are using your app or other simple criteria such as tags or geographic data.
Users: receive notifications when users who have registered with your application post new photos.
Tags: receive notifications when a new photo is tagged with tags of your choosing
Locations: receive notifications when new photos are posted and tagged with a specific location
Geographies: receive notifications when a new photos are posted in an arbitrary geographical location as defined by a center point
and radius
As far as I have found this far there is no IG API, however as already indicated you can keep track on your app. HOWEVER, what has not been pointed out is that you won't be made aware if users terminate their account or revoke your app so the count's might be a little off. (or worse if you didnt start keeping track since the public launch of your app)
You could test on a periodic basis if you still have access, but that would require additional code, and a lot of API calls if you app has a lot of users. I hope that IG will add this function at some point.
The facebook chat api is a power tool. From a purely technically point of view, it definitely does more than its predecessor of private messages in the Graph API.
This brings up a question of where Facebook is drawing the line of abuse of its chat api.
So here's how I'm planning to use the Facebook chat api for my app.
The app is an event planning app that lets users invite their friends to an event. Other than sending SMS, and emails to notify the guests, the most reliable way is to send invitations through the list of facebook friends. And let's face it, sometimes you may not have the person's phone number in your contact book, and you definitely don't remember most of their emails, so facebook is your only source for reaching them.
So I need a solution to send invitations to the guests. Here are my requirements and conditions:
The guest is a facebook friend of the user
There's no way of obtaining the guest's email (unless the user enters it) or phone number (ie. sms is not an option)
Each guest must receive a link that is unique to him/her
No one else should be able to obtain this link (ie. the message shouldn't be seen publicly)
It must not require the user's interaction to send these invitations (imagine having the user confirm a facebook post 10 times for the 10 facebook friends he's inviting). The invitation must be sent automatically.
Here's the obstacle. Facebook had revoked the functionality to send private message recently (I was able to have my facebook friends send me private messages via an app just over a month ago, not anymore). However, I discover that I could do so using Facebook Chat API.
This seems to be a grey area, my app is using the chat api for the sole purpose of helping the users notify their friends of their event invitation. There's no intention of abuse (such as mass messaging everyone of the user's friends with a link to my APP/website). Is Facebook going to hunt me down and revoke my App's privilege to use Facebook's API?
Can anyone shed some light on whether my intended usage of the API is an abuse or is it legitimate? If it is not legitimate, what are your suggestions.
I'd recommend using core functionality wherever possible here. For example, you could utilise the Facebook 'Event' object and the Graph API to create invite-only events and to invite individual friends of your app's users. This would deliver the same functionality without the need for nonce-based invite URLs and possible misuse of the Chat API. Take a look at https://developers.facebook.com/docs/reference/api/event/#invited for details.