During In-App Purchase implementation in a project. I am working on the ASP.NET WEB API side. I need to use CRON JOB for timely receipt verification on the server side. I want that in-app purchase receipt verification should happen timely from the server side. That is an old project so I want a solution in ASP.NET.
Related
I have a working PWA application and i have tried integrating push notifications to it which worked. But those notifications happened totally in the front end, a user has to click a button and a push notifications would show up.
In my application i have a cronjob that runs every night to check if certain things are updated. If so i want to send a push notification to a user to notify them.
But i cannot find any information regarding this subject so I'm thinking it's not possible since the nodejs server doesn't have a connection to the PWA. Is there something I'm overlooking on my approach or is it simply not possible?
I am developing Xamarin.Forms application which will be used for Android and iOS. It will have access to full functionality with a paid subscription (monthly or yearly). We plan to use in-app billing for implementing subscription on both stores.
There is a situation if a user buys the subscription in Android app and then wants to use iOS app or vice versa. In this situation, the user should be able to use the other platform app, because the user already purchased the subscription. We are planning to fix this issue by a back-end REST API. When the user purchase the app in android or iOS, we save the subscription details to our back-end. So once the user purchased the subscription in any platform, the user can use the app on other platform and multiple devices.
But if the user cancels the subscription from outside the app like apple or play store, how we can update the status on our back end? Because at this time the action happening on outside the app, so we can't update the status on back-end.
For example, If the user subscribed the app from play store and also using the iOS version. Then the user cancelling the subscription on play store. After that the user is not using the android app. At the same time the status is true on back end. So the user can use the iOS version without a subscription. How we can handle this type of situations?
We research a lot and find out we can call app store and play store via their APIs which will return the entire subscription details. So we will call it from the back end as a cron job and update the latest status once in a day. So if the user cancels the subscription from outside the app, that status will update on the back-end via cron job. Is this possible? Any other better solution for this kind of issues?
I use serviceWorker to push client desktop notification. Clients receive message if they visit my site, how can Clients not visit can still receive the message(like onesignal.com)?
Clients/Users don't have to be on your site to receive notification.
But your client/user has to accept the notification request in your site at first, so you save the subscription object in your database and later you use that user subscription data to send notification to your client/user at any time using library like Web Push API.
If you need anything in particular, please be specific.
What is the difference between the newly release ASP.NET WebHooks and Signal-R? What are the advantages or disadvantages? What are the use cases for each technology?
SignalR is for notification within an ASP.NET app using WebSockets. You can exchange event notifications through WebSockets, however it requires a constant network connection.
WebHooks are for event notification across other web applications and other external services. (Think B2B communication). For instance, you can receive a WebHook when someone sends you money to your PayPal account. PayPal fires off a POST request to your predefined URL handler and then your app does something with that notification. You pre-configure everything on the PayPal side first. You also set up an application to handle the incoming POST request. The event notification is "pushed" to you in (near) real-time. No need to hold open a network connection while waiting for events.
The two can be complementary. For example, when you receive the WebHook from PayPal, you can notify a logged in user on your webapp (using SignalR/WebSockets) that money has been received successfully.
TLDR: Event notification across different web applications
It really depends on service you want to integrate with and how. WebHooks is a simple pattern for integrating event notifications across different SaaS services. If the service you want to integrate with supports WebHooks then you can use that. If it supports SignalR then you can use that. In that sense the two are quite complementary.
Check Henrik F Nielsen post at
http://blogs.msdn.com/b/webdev/archive/2015/09/04/introducing-microsoft-asp-net-webhooks-preview.aspx
I have an Azure web application (Asp.net MVC & WebAPI) that sends emails through SendGrid service. I'm not using SendGrid's API but rather use .net built-in SMTP that I configured in web.config and directed to SendGrid.
I'm now wondering whether I also need message queueing application in my solution that would be used to actually send emails to SendGrid to minimize request/response times of my web app?
Azure already has Queue Storage that I could use but I wonder how others have implemented this? I'm also looking for the most simple example of Azure web app using queueing if one exists.
I expect message queueing will become relevant when I'll have several emails to send during single request to make my app scalable. Currently I'm sending email synchronously when my backend executes code and so far with the low number of emails it works fine.
If your application need to manage and send bulk emails asynchronously, it would be better to have separate application which will take emails as bulk.
In my recent project, I have created separate application using web role, worker role and a service bus queue. Web role is a web API which used for application to post bulk emails and put it into a service bus queue. Then worker role will be responsible for dealing with the queues and send the emails. This allowed me to send emails asynchronously and storing any email messages or message status in a table storage.
Further, this approach helps me to use same notification application (email sending application) in different projects by using a wrapper to handle web api integration.