Im adding a time bomb to my application…
I wanted to know your thoughts if this is a robust idea:
Bare in mind ive done alot of research on a unique ID android can provide,but found
if its a phone, telephony.getDeviceID is useful… for other devices like tablets,
android_id is usefull…
(formatting a device to reset the unique id to cheat is unlikely for my app)
So ive decided to join them together as a big string for a unique id, regardless if the telephony will return null for non gsm devices.
So what do you think of this,
-
check,join and create the unique ID
-
connect to an FTP and upload a txt file with “20” within it.
NOW, whenever the user reopens
-
check,join and create the unique ID
-
connect to the FTP and check if that file exists
-
if it does, read, -1 the text within it, write it back to the ftp (so now the txt is 19)
Gradually… when 20 uses are over, and the text file has “0” in it, post a message linking to the markey to buy the app, otherwise exit app before anything is accessible.
What are your thoughts?
Th biggest problem I see with that will be WiFi firewalls, etc., that may pass HTTP (port 80) but not FTP traffic, in some cases.
Assuming you mean “HTTP, port 80” (or HTTPS, etc) when you say “internet based app”, I’d suggesting using the same access technique as the rest of your app… ie., use http with a POST or GET to a little PHP app on your server to take the ID, decrement it in a sql database, and return a ‘yes’ or ‘no’ response. Using HTTPS would also get around the snooping that Roland mentions. That way your authentication mechanism won’t fail if the rest of the app could work, or will at least fail in the same way.