I'm implementing notifications into my app, but I am trying to figure out what I need to do to know if a Channel is an "Update" vs a "New" channel that wants to receive notifications.
Currently, everytime the app is ran, it sends me the new channel and the expire date. When I want to send a new notification, I am going to assume everyday, I'll get a new one of these for the same person. I need a way to only send it to the person once.
I was thinking about using CoreApplication.Id and store that, but I am not sure if that is unique per application install.
Any ideas how to go about this? I have read several articles, but they are all just showing how to push it once, no mention to this problem.
Thanks!
You will need to add another aspect of identification in your service. Because the URI can change any time, and there maybe multiple installs of your client, you will have some challenges trying to identify unique per user notifications without having identified some "user" id uniquely.
Likely, you want to take advantage of either:
Microsoft Account, using this to identify the user
Make the client application get a "unique" identifier for your client from your server (it could just be a GUID), and save that in roam settings. This will travel with the client across machines. If it's there, clearly it's not a new customer.
Note that if the user uninstalls your app on ALL their machines/accounts, then the roaming setting may go away. This is an undefined period of time.
Related
I'm new to xamarin so I'm still trying to figure out how some things work.
The things is, I wanted to create a simple application where the user will recieve an email if his account logged in into an unknown device (yes, it looks like a login alerts).
Correct me if my proposed method is incorrect, I want to create a list of every known device each user has logged in, and compare it to a current device the login attempt was made. Is there a way where I can use a unique android device ID in Xamarin that I can use for this situation?
Any answers/suggestions will be much appreciated 😁
Thank you in advance
Using device ID would mean that if user uninstalled your app and stashed the phone for a year, it would still be considered trusted. Users most likely won't remember what they did in the past and blame you for failing to alert.
What you should use is instance ID. An UUID that app generates once and then saves. So uninstalling your app or clearing its data would make it "brand new and untrusted" - because that's exactly what users expect.
To paraphrase Fifth Element: Device not important. Only app important.
Also note that mobile users expect to log into app once and remain logged forever. Some apps (like banking apps) add extra PIN, fingerprint or password to actually access the data, but the app remains paired to the user account forever. In that case, there is server-side list of app instances paired to user's account, so it's trivial to notify about new pairing. Bonus-you don't need any client-dependant IDs, have the server assign the ID on pairing.
I have an application with one DB which is used by many users. Whenever one user makes changes, we save the changes to the database.
Now, I need to notify other logged-in users about this change. How can this be done?
I'm thinking - when the application succcessfully saves / updates the data in the database, the application will send a notification to the connected clients with the new record updated or added.
I'm using C# and SQL Server database.
Your immediate options are push-based notifications with something like a message bus, or polling loops on known ids.
Message busses operate on publish-subscribe models which work well for Windows applications. Have a look at MassTransit or MSMQ as a starting point. There are plenty of options out there. They can be combined into web apps using something that essentially wraps a polling loop with the client like SignalR.
Polling-based options work typically on a timer and do quick timestamp or version # checks against the database, reloading a record if a difference is found.
Push-based are more efficient but only notify of changes between supported applications. (Client to Client) they don't detect changes by applications that don't participate as publishers, nor do they see changes made directly to the database.
Polling-based options cover all changes, but are generally slower and require a schema that has version information to work effectively.
I'm trying to implement my C# backend's communication with Notification Hub. I've read almost every tutorial about Azure Notification Hub, and I can't find a decent tutorial that explains what actually corresponds to what. I think there are two ways of representing a device (from what I've understood): an Installation and Registration, and Installation seems to be newer and more preferred.
However, when I get into Installation, I get more questions in my mind:
What is InstallationId? Is it something that I create, or something that I get from somewhere, either device or PNS.
Do I need to set up ExpirationTime, or does it default to longest (it says 90 days is the longest)? What if I want it to be longer than 90 days?
What is PushChannel? Is it, just like InstallationId, something that I create, or get from somewhere?
How are templates exactly used?
Out of all these variables, which one is the actual device push token that I get at the client?
I usually don't ask those kind of questions that seek for a tutorial-ish answers and have multiple questions, but I've tried to search everywhere, but the more I search, the more it gets complicated and I don't even know where to start. Any answer would be a good starting point to anyone trying to learn Notification Hubs, just like me.
InstallationId is an abstraction on top of device token/key/channel etc. It's a unique id that you create when you 'install' a device (or user if your OS/platform allows separate tokens for multiple users). This is an id you can use to associate tags, templates etc with the device. You create an installation once and then keep the id somewhere in the local storage and then make updates to the installation associated with the id if you need to.
You don't need to explicitly set ExpirationDate. I think in the past tokens on most platforms used to expire, so this was a way to let Notification Hubs know when not to try to push to the token. I believe now it's not the case. So what happens is if Notification Hubs cannot deliver a notification to a device for a number of times, it just deletes the registration by itself.
Has this post on templates been useful?
PushChannel stands for 'The channel URI if registering the installation for WNS; Device Token if registering for APNS.'
Let me know in the comments if I can clarify any of these and I'll update the answer.
There is actually a 3rd option besides Installation and Notification: DirectSend.
The Direct-Send technique is less of an abstraction than Installation and Notification. With Direct-Send you can send notifications directly to one or more specific devices. Basically you use the actual deviceToken- as in what #NikitaG notes for PushChannel.
If you need to be able to decide specifically when your back-end application pushes to a specific-device-A-but-not-B vs. pushing to a specific-device-B-but-not-A vs. specific-device-A-and-specific-device-B according to some schedule Direct-Send can be enabling.
I'd listed some of the resources discussing Direct-Send at Azure Notification Hubs Send Notification to Specific Device.
Im have created a software application which is windows based. Soon im going to make it live. Means my clients will be able to use it after they download it from my website. Also to mention i have made the software in a way that it works only with the key that i provide. Initially its gonna be a free trial.
Here im generating 35 digit key and its a unique one. Means once the user requests me for the key and i send him/her the key, he/she may be able to use my application. But the real problem arises from here.
I want the code to be used only once.
Ex: If my application is downloaded by the user, he can use the key to use my application but the same key cannot be used by any one else. Lets suppose my key is xxx the same code xxx should not work for any other person who has downloaded my application. Just to make the software to be used only by genuine users.
i have also gone through this link
http://social.msdn.microsoft.com/Forums/zh/winformssetup/thread/301913a0-ecf9-4095-8d66-a3f4baeea6eb
by Danny Staten
I still haven't met my requirements.
First of all i thought to get the Ip address of the person who is registering to download my application and based on that i can limit my key to be used only by the person whose ip address would be stored in my database. But i think it would be wrong/ unnecessary process. And to use my application the persons network cable should have been plugged each and every time. But it wouldn't solve my purpose.
Secondly i thought of creating a process of the application pinging to my server or to me.
Like initially when the user runs the application(online or offline) the application should work, but as soon as he connects the network cable/plug to network an alert should be provided to my server or to me. And from my side i can make a check if the user is using the key that i have provided to him. If in either way the user is not genuine i should be able to stop him from using my application anymore. From my side i have decided to store the keys inside the database which have been provided by me. And each requested keys in another table. Im not sure if im going the right. But as of now this is the thing that has come into my mind.
But to summarize, in the end i want that a key should be used by only one user. Just to avoid a million different users using my application with a single key.
Im not sure with any idea that i have provided.
Now is there a way i can achieve that?
Get hardware fingerprint of his machine and generate key based on that. Your software should check whether the key was generated for that specific machine.
This however requires online activation of your software. You can do this in two ways
letting user start unactivated application and display HW fingerprint which he sends to you. You then return activation key which he enters.
your application connects automatically to activation service and sends the fingerprint, receives activation key and stores it
Another point would be to include information about several components of hardware and allow user to change one or few. E.g. take fingerprint of HDD serial number, MAC address, motherboard SN, some CPU info (e.g. family name), you should allow user to upgrade or add another HDD.
There is SO topic about getting hardware information.
You have to make a choice I think, the stronger your key system will be, harder it'll be for your users.
IE: A good system would be to generate a hardware key, so it only gets installed on the computers that are registered. Although it works well, users who buy a new computer will probably get in the trouble of asking you to register a new hardware key.
And if you only give them a key (like a serial number), it'll probably easy to use it on another computer.
So basically, if you don't think many users will give away their key because the software isn't going to be used by many people, I would not get a "super-strong" hardware authentication..
Also, don't register an IP address, everyone with a dynamic IP will hate you for doing this.
I will try and explain exactly what I want to achieve first.
Imagine two users are using a windows forms application, when User A opens a particular form a lock is applied to the data record underlying the form so that only that user can make changes at that time.
User B has a list of all records (in a grid) which among others contains a reference to the record already opened by User A. What we want to do is when User A opens the records User B's list of records is updated to show a lock icon next to the row to indicate the record is in use.
This is a trivial example of what we do with messaging but you get the idea, User A does something User B needs to knows about it.
I have implemented a system using Jabber-net for C# and an OpenFire Jabber Server. Basically when a message is to be sent, a new row gets inserted on a messages table in the database. The messages table is watched by a service client using the SqlDependancy object, so that when a new message is ready the service builds the relevant message and sends it to the desired client via Jabber and the OpenFire server.
This works OK, however OpenFire's out of the box functionality is for supporting Instant Messaging which obviously isn't what I'm trying to achieve . The problem I have is that if a user is logged in to two Application Contexts (i.e. Test and Live) OpenFire does not know which one to send a message to because the JID structure of user#server/resource takes no notice of the resource.
Basically the way I'm currently using OpenFire and Jabber-net isn't quite right.
Is there a pattern I can use for achieving what I want to achieve i.e. send a message to a client telling it do something, whilst being able to specify which client you are sending the message too. XMPP seemed like the answer because I can construct my own messages types to be parsed.
My application is a Windows Forms, .NET 3.5 C# application.
I'd just add some more data to indicate which Application Context is affected and have the other clients decide whether they need to handle the message or not.