User Notifications in Laravel 4 App - notifications

In the event management app I am building I require user notification functionality. Having never implemented something like this before, I am after some advice on how you would go about doing this.
Here are a couple of scenarios that will require notifications.
Scenario 1:
Each event in the system has a start date associated with it. If the event also has delegates assigned to it that have a status of 'Provisional', I would like to send a notification 3 days before the event start date to any users with the role 'Admin', informing them that there are still provisional delegates assigned to this event.
Scenario 2:
There are accounts in the system, and each account has an account manager assigned to them. Accounts can also have multiple contacts associated with them. An account manager is able to assign a note to the account which is tied to a contact. So they can, for example, create a note of the type 'Scheduled Call'. The scheduled call has a date and time associated with it, so if around 1 day before I would like to send a notification to the account manager, informing them that they have a scheduled call due for this contact at the specified date and time. I'd like to keep sending or showing this notification until it is dismissed or deleted.
Summary:
There are several other scenarios but these 2 cover the basic functionality. I guess my question is this, has anyone implemented this or can anyone tell me how you would go about implementing such functionality in Laravel 4?
Specific questions are:
Method of Implementation
How to Automatically Check for these Specific Scenarios. Cron or via IronMQ or similar?
Where to store the code. In a helper function or it's own controller?
Are there any other considerations I have missed? Thanks.

I think you would need some sort of scheduled task / CRON job. Using the scheduled task, you can then run php artisan YOUR_CUSTOM_COMMAND. Obviously you would need to develop your own commands to use. See: http://laravel.com/docs/commands

Related

Notifications for inactive users

I’m implementing a solution that will notify users in a scenario very similar to a chat.
I’ll be using SignalR and Azure Notifications Hub for the job.
There are two scenarios that I need to address:
Notifying users that are currently connected and using my app - either web or mobile
Notifying users who are NOT currently using the app
I think SignalR will work just fine for the first scenario which is fairly easy.
My question is handling the second scenario which will require Azure Notifications Hub.
In a typical chat app, though it’s not real-time, there’s little delay before an inactive user receives a notification for a new message he receives.
How do I “trigger” a process that will send a notification through Azure Notifications Hub?
I can think of two ways to handle this:
Figure out a way to keep a list of users who currently have an active connection to my app. These users can be notified through SignalR. So after each new message, I could trigger a notification process that will use Azure Notifications Hub for users who are NOT in the active users list i.e. those who are NOT actively connected to my app.
Another approach would be to assume no one is connected. I could create an Azure Functions app that runs every minute to check on messages that are NOT opened. It would then compile a list of users who need to be notified and call Azure Notifications Hub process to notify them.
I don’t want to reinvent the wheel and want to tap into the experience of those who’ve already implemented a solution like this.
I’m currently leaning towards the second approach. I’d appreciate your suggestions, especially on approaches that I haven’t thought of. Thanks!

Receipt does not get updated after purchasing an automatically renewable subscription in a macOS sandbox environment

I am trying to implement StoreKit's ability to have automatically renewable subscriptions in my macOS application.
After reading dozens of pages and checking examples, I understand how everything fits together but fail to get it to work correctly.
What I am trying to do:
As soon as the app starts, check if an active subscription is available by evaluating the local receipt. I'm specifically checking the unavailability of a cancellation date in any of the In-App Purchase field entries of the receipt and whether the subscription expiration date is in the future.
In case no (active) subscription is available, I'm purchasing the subscription using StoreKit's APIs.
Both scenarios are working fine as this flow works perfectly when the subscription is purchased for the first time. However, the receipt does not get updated automatically after the subscription expiration date ends. I'm expecting this receipt to be updated periodically as also shown on Auto-renewing subscription and app receipt. As a result the first step described above fails because the expiration date at some point is in the history and hence, is considered expired.
Two things I find strange:
My SKPaymentTransactionObserver instance only gets called after purchasing the subscription (after a user explicitly buying it). It never gets called when the subscription expires and should automatically renew (as shown in the above blog post);
Explicitly asking my receipt (containing the IAP's expiration date) to be updated using the SKReceiptRefreshRequest API fails by calling it's request:didFailWithError: delegate method. The error object is nil so I cannot see why it fails updating.
I can share code but I have a feeling this is not related to code but instead is some kind of project/environment setting and/or behaviour I do not fully get.
Do you have any suggestions what to try?
After a few days of experimenting I changed the mechanism to use the server-side validation documented on https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html#//apple_ref/doc/uid/TP40010573-CH104-SW1. Obviously this requires a web service running somewhere and makes your environment more complicated but at least things work in a more stable (and secure) way.

Strategy for notification checking

Is there a recommended strategy for checking of notifications within my AngularJS app?
By 'notification' I'm talking about message alerts that are to be displayed to a user when they're logged into the application.
My plan is to notify the user of unread notifications in the app's NavBar as shown below:
My app communicates with my restFul API (written using Node.js, express, MongoDB), so I anticipate that new notification will be written to a MongoDB collection with details the user the notification is intended for.
What I'm unsure about is how the AngularJS application will check for notifications once a user is logged on. I could call my API for unread notifications every time the user navigates from one path to another but that seems simplistic and it wouldn't work if a new notification occurs whilst a user is viewing a page.
Another way would be some sort of timer system that checked, say, every 30 seconds. But this would results in unnecessary polling of my API when there aren't any new notification for a user.
So, wondering if there is a recommended strategy. Thanks for your help.
Polling is a solution but it is very inefficient. The solution to your problem are websockets. Websockets is a technology that provides a full-duplex bidirectional communication between your clients and your server. So you can send messages from your server to your connected clients. Your server maintains an array of connected clients and you just have to know which ID you need to send a message to it.
For your stack, the best solution I have came to is Socket.io http://socket.io
It also have cool features. For example, you can "observe" models, so if a model change in your database, for example an update to a user profile is made, you can trigger an event and automagically send a message to your client. This client get and handles the notification and do something, like put a badge on your alerts icon.
Hope this is useful for you.

Unregister tags with Azure Service Bus Notification Hubs

I have inherited an iOS app that uses Azure Notification hubs to send notifications, however there is a snag.
The users select multiple categories for which to receive notifications (News, Sports, etc), and they can change these at any time. Whenever they add or delete an interest the app unregisters from the notification hub and subscribes with the new tags.
I thought that this was incorrect, but I can't find a way to see what tags a user is subscribed to, or add/delete a single tag.
In the current app, sometimes our test devices don't receive notifications that I think they should.
I've found answers online saying that you should avoid unregistering, and that there is a delay to register and unregister (such as the answer here, Android Azure Notification hub unregister)
I am looking for any insight on how to handle this usecase, of adding and deleting tags.
Since you didn't specify how you are communicating with the Azure Notification Hub, I will use the ANH REST API as reference.
"...I can't find a way to see what tags a user is subscribed to..."
If you request a registration (e.g. per registration ID), you will get the registration data including the assigned tags.
"...or add/delete a single tag."
You don't add or delete single tags directly on the registration in ANH, you basically update the whole registration, if necessary. Some ANH SDKs may have convenience methods for this, but in general, you just send the complete registration object with the desired tags to ANH and it gets overwritten. E.g. the REST API has an "Update Registration" method, but no "Add/Remove Tag" methods.
"I've found answers online saying that you should avoid unregistering, and that there is a delay to register and unregister..."
You should indeed not unregister and register for this use case because of the reasons you stated. This is probably also the reason for:
"In the current app, sometimes our test devices don't receive notifications that I think they should."
Never unregister and register again for updating a registration. Only unregister, if you don't want to receive notifications at all on a specific device.
"I am looking for any insight on how to handle this usecase, of adding and deleting tags."
Basically, just omit the "unregister step" and make the "register step" a "create or update registration step" using the actual ANH registration ID and all desired tags.

How to let only paid members into my iOS app's some sections with in-app purchase?

I am developing an application where I have a section only for paid users where they purchase for the section using the in-app purhcase system in iOS. I know that I need to keep track of the purchase history myself, and this is where the problem begins. I have a database and I am capable of storing users in my database, with a web service interface. How can I create a system where a URL is pinged only when a user has made the purchase.
As an example, I have the URL:
http://example.com/registerUserPremium/userid=123456
How can I get this to be called only when a purchase is made? The most elegant way seems like Apple pinging the URL with a special user ID upon purchase, but I can't find a way of doing it. It is obviously not a solution to make the user call that URL within the app, as it can be cracked/pirated. What is a good way of providing such a mechanism that is piracy-proof. My service is web-based, so if I can get this part done, the rest relies on my server-side mechanism (the user will just send a special key that is stored in its keychain, to the server) so I'll be able to finish the project. In short, I need a way to call a URL only when a purchase is made. What are some possible solutions?
Thanks,
Can.
I see two solutions:
"Server product model" (doc): the appstore contact your servers every time a user makes a purchase. In this case you have all of the information right away.
"Builtin product model" (same doc) in which the application gets the receipt from the appstore. In this latter case you can contact your server special URL, providing the receipt information, and the server can verify that the receipt has not been tampered with asking the app store to verify (it's a simple post, see here).