Is there any way to get application insatllation time in iPhone? I wanted to use this information as a unique identifier, can I use it for this purpose?
There is no way to get the application installation time.. You can keep track of the first launch of your application within your application using NSUserDefault.
In application didFinishLaunchingWithOptions: you could do
NSDate *date =[[NSUserDefaults standardUserDefaults]objectForKey:#"FirstLaunchTime"];
if (date == nil) {
// nil means your application running for the first time
[[NSUserDefaults standardUserDefaults]setObject:[NSDate date] forKey:#"FirstLaunchTime"]; // set the current time
}
NO. You don't know anything about the actual installation (duration / time) within your app. You only know the first start date.
For unique IDs, check this answer:
How to get the UDID in iOS 6 and iOS 7
You can have a field in user setting for this and when user installs and opens it you will get a callback in appDelegate's didFinishLaunching method.
Here you can check if the particular field is nil then only store current date time. You can use this date time in your app.
What you could do is check the /Documents directory to see if there's anything it when it is first run (there shouldn't be if it's the first time it's been installed on that device). If not, write a file there with the current time stamp.
I guess you could use this information as a unique identifier, but in theory, there could be multiple people who open the app for the first time, at the same time. I wouldn't do it.
Related
Is there a way (in code) that you can give an app different features based on when it was purchased??
I have people who have bought my app for a different price and some had it free during a promotion.
It would be nice to give a little thank you with an extra feature in my app for the ones who paid for it.
Is that in anyway possible?
Without having it in place beforehand, you won't ever know about the past, but nothing prevents you from putting the timestamp of when a user first opened your app into e.g. the user settings. Something like
[[NSUserDefaults standardUserDefaults]
setObject:[NSDate date]
forKey:#"install_date"];
which you could then use to decide how to "treat" (I guess) the user. The one catch is that if a user ever deletes the app and then reinstalls it, their early adopter bonus or whatever will be lost. The only other option you have is to send the device ID to a dedicated server somewhere, e.g. a PHP script with a simple MySQL db where device id's are stored along with dates. You could then do something like
NSDate *purchaseDate = [[NSUserDefaults standardUserDefaults]
objectForKey:#"purchase_date"];
if (nil == purchaseDate) {
// we need to get the date for this user from the server, or
// we need to register the user as it's the first time
} else {
// we know when this user installed the app, and they did so
// (approximately) at the purchaseDate time.
}
Date format issues aside, the above should be pretty straightforward, but as said, does require a server somewhere (which can be a slow mo because the above only happens on first install and reinstalls).
Edit: you can use [[UIDevice currentDevice] uniqueIdentifier] (deprecated as of iOS 5) or [[UIDevice currentDevice] identifierForVendor] (new as of iOS 6.. lol) to get the device ID.
You have to manage it by code officially Apple don't provide any code for that. But if in case you need any kind of analysis of app. Like , which part of app was used by user, which part makes crash of app, something kind of feature you can try this Flurry Analytics for it .
There is no way to detect from within your app when an app has been purchased. You could add detection of when it was installed, but that could have happened at any later time, even multiple times.
I am building an app that requires core date to update every Sunday. e.g. it will save "thisWeek"'s data to "lastWeek" every beginning of a new week, and reset "thisWeek" to let user input new data for new week.
My question is how to achieve this even if user is not running the app at all?
Use UILocalNotification with repeatInterval property which reschedule the notification with calendar interval. I suggest to go through following Apple iOS guidelines. Bottom line, your app will be open when notification will occur.
UILocalNotification
Just do the archiving if necessary whenever the user starts the app. If your data is timestamped this should be simple and there is no requirement for the phone to even be switched on.
This isn't possible. Your application cannot execute code unless the user has launched it. You could provide a local notification to prompt the user to reopen the app, however this is a sub-optimal solution.
A better solution would be to timestamp your data and then whenever the user opens the app, regardless of when, you can process all of the data and move it where it needs to go.
I would show an alert to the user when the user updates the app (not at the first installation) and/or show an alert to the user after the seven days app usage for example.
Is it possible? Where can I begin from?
Thanks.
For an alert when the app updates: store the app version in NSUserDefaults. On launch (use -applicationDidFinishLaunching:), check this value. If it's different from the current version, throw up an alert then update the value. If the value is empty then it's first launch.
For after seven days, do something similar: store the date of first launch in NSUserDefaults. On each launch, check if that is more than seven days ago. You might want to also store a boolean to show whether you've done this alert, as otherwise you'll be nagging users on every launch beyond seven days. You might also want to do the check in -applicationDidEnterForeground: as well.
I have an app that requires me to take an action after some period of time. For example, if an user hasn't been inside the app in few weeks, when the user eventually starts the app, I have to ask them to put in a special code that was given to them when they installed this app. (this is an in-house app and i am being required to do this due to security concerns)
I am using the [NSDate date] method to retrieve the date when the user logs in and save it into a database. I compare this saved date next time they open up the app and see how long its been since their last login. The problem is that [NSDate date] gives the time that is effected by the time settings that can be changed manually by the user in the native settings app. As you can probably tell, this causes lots of problems to my situation. If the user is suppose to be put the special code after 3 weeks of inactivity, he can cause the app to show this screen by modifying the time in the native settings app or worse, get away from it by setting the time to a previous date that will be within 3 weeks of his activity.
Is there a way to get the "system time" instead of the "user time"? I have looked into mach_absolute_time() but this gets reset after restart of the device. Since the time of inactivity I will be comparing against is pretty large, chances are device would have been restarted by then. I also thought of using network connection to get the time from servers outside the app, but lots of users won't have access to wifi where they use their iPads. That will be my last resort solution if i can't find anything else. Because of their location during usage, I am trying to use everything on the device itself.
Am I overlooking something simple here? this seems too simple of a problem to not have an answer. Please guide me toward the right direction. Thank you in advance.
Why not query a remote server for the time - lots of NTP servers about or just make a simple HTTP request to a php script on your own server. Of course if your app is likely never to be connected to the internet that could be a problem, but once you have a 3rd party time its quite easy to guess if the user has been playing with the clock.
If this is an inhouse app (so you aren't constrained by Apples approval process), you could mark your app as doing some background stuff (voip or receiving location updates), so that the app will always be active and you'd be able to update some sort of an "unused" counter. Voip app will even be restarted by the OS after device reboot.
But of course it'll drain the battery somewhat.
Either: make having the actual time an essential feature of your app. This way the users will have a need to keep the time of the device current and can't go back three weeks
Or: mark the code as expired and save this information before the app informs the user. This will stop most user from setting the time back. Most will try once or twice, see that the app stays disabled and will give up.
You can also save the timestamp of the last successful execution and if that is more than a reasonable time frame in the future (remember summer/winter time) then consider it a "hack attempt". Put a CRC check (or whatever obscure idea you come up with) on that timestamp and save it too and you will stop a large number of script kiddies.
You can never stop the diehard hacker who search actively for every trick you might have put into the app. Just focus on the "average" user.
I am developing an enterprise app which has a lot of dynamic content. Is there a way to have the app auto update the content(new stories, download new videos, etc) at 3am every Sunday.
Is this possible?
While it’s not possible to do this when the app isn’t running, you can do it fairly easily at launch or while running (if it’s going to be running at 3 AM). Here’s what I’d do:
Store an NSDate using NSUserDefaults for the last time you updated.
At launch, if a 3 AM period has passed since that date, initiate a sync.
Also at launch, start an NSTimer with a long interval—5 minutes or so. At each firing, check if a 3 AM period has passed and if it has, initiate a sync. You could even roll the last bullet’s code into this NSTimer’s firing method and just run it once at launch. Just be sure to update the NSDate object each time.
In the application delegate, in the methods called from returning from the background, check the time and sync if necessary—or just start the NSTimer and have it fire immediately first.
That should cover all of the scenarios where you need to update the app.