Reputation: 35
The business context of the use case is that we are building a backend server (multi-tanent) which will serve apps from multiple platforms (iOS, Android, Windows phone 7, BlackBerry, j2me phones). The business would like to reward users with first time installation of the partnered apps. So, business wants track separate first time app install users from reinstall (delete & install) users. So, we expect the partnered mobile apps would send the unique identifier (using the unique identifier specification we decide here) to our backend server through a web service after installation & server would verify it & return back the reward, if its a first time installation.
So, ideally, all we want to define here is the unique device identifier specifications with following properties..
Looking forward to innovative brains to discuss this.
Thanks for reading this.
Upvotes: 1
Views: 9840
Reputation: 1172
I suggest using IMSI, where available. IMSI is a unique subscriber identifier available programmatically on most platforms, except Windows Phone 7. It is linked to the SIM card / MSISDN and will therefore change if the SIM / MSISDN is changed. With IMSI you will be identifying the end-user rather than the handset that they are using.
Upvotes: 2
Reputation: 4296
You're fighting a losing battle 'trusting' the device to give you a consistent unique ID, any jailbroken iOS device allows you to change the UDID, I'm sure thats the case with Android (and probably windows phone too), MAC addresses are useless as they can be changed in software.
Even things like IMEI and IMSI can be faked. The 'best' solution would be to have a login server side where you (the trusted party) can set properties on the users account.
Trusting the other side to give you either consistent or 'non-fraudulent' information is a recipe for disaster, and if you are 'giving away rewards' as you say, it'll be a costly disaster.
Revise your business case.
Upvotes: 3
Reputation: 1962
There are different ways to identify a device. For mobile phones, generally, the International Mobile Equipment Identity or IMEI is the first thing to be considered. For newer phones, there is also the Mobile Equipment Identifier or MEID. For iOS devices, including the non-mobile phone devices like the iPod, there is the Unique Device ID or UDID.
Upvotes: 0
Reputation: 8126
For Windows Phone 7 device unique id
can be accessed via DeviceExtendedProperties class:
object DeviceUniqueID;
byte[] DeviceIDbyte=null;
if (DeviceExtendedProperties.TryGetValue("DeviceUniqueId", out DeviceUniqueID))
DeviceIDbyte = (byte[])DeviceUniqueID;
string DeviceID = Convert.ToBase64String(DeviceIDbyte);
MessageBox.Show(DeviceID);
Description from msdn: A unique hash for the device. This value will be constant across all applications and will not change if the phone is updated with a new version of the operating system.
Upvotes: 2
Reputation: 28509
Apple are deprecating the UDID. So right now there is one, but in future, there probably won't be.
With Android, devices with SIMs generally have a unique ID, but it's not always available (e.g. SIM-less devices) and Google's guidance is to create your own unique ID. You could send it to cloud storage so it's always there. http://developer.android.com/guide/topics/data/backup.html
Another alternative with Android is to request account access permissions in your app, and access the user's Google account name, i.e. their gmail address. You could use their gmail email account (used for Android Market etc) as a form of identifier. This has the benefit of working across all their devices, e.g. if someone has a phone and two Android tablets, they can be identified as one person.
AccountManager accountManager = AccountManager.get(myApplication);
Account[] accounts = accountManager.getAccountsByType("com.google");
String gmailEmail = accounts[0].name.trim();
I think it would have been better to ask a question for each platform as the answers are almost entirely platform-specific.
Upvotes: 1