I have a basic query here. My app has a bit longer signup process. While testing I came across a bug where, whenever amidst the process if the user goes out of the app or kills the app, the remaining process is just left and it migrates to the a specific page, that i want the user to usually go to already.
Example if I have 5 ViewControllers and then a default 6th and if the users kills the app on 3rd VC, and then restart the app, it'll go to the 6th vc and ignore the rest of signup.
How do I avoid this. is using NSUserDefaults an optimal option. If yes How do i exactly implement it.
Cheers!
Yes, using NSUserDefaults to store the previous state of an app is common. (However, apps that have a server backend may store some data there too.)
Use the keychain to sensitive data (e.g. account details). (You must never ever store sensitive information in NSUserDefaults because it can be read.)
What you store in NSUserDefaults (and the keychain) depends on your application. If fields are filled in and/or options selected during the process, you need to store that.
Be pragmatic: It's very nice to users store app state. It can however get rather complicated. Don't waste time (with chances for bugs) trying to cover situations that don't occur often.
Related
My iOS app uses CoreData as its data store and I have added a watchOS app to accompany it. Currently the workflow between the iOS and watchOS apps is as follows:
The watchOS app exposes a menu representing a subset of functions available in the iOS app
Choosing one of these options sends a message to the iOS app telling it which option was selected
The iOS app responds by packaging up any data needed by the watch for that particular function into a dictionary and sending this back to the watch in the reply handler
The watchOS app presents an interface to the user allowing them to change the values in the data
Each change sends a message to the iOS app which updates the core data store with the new values
This is working fine but clearly requires the phone to be connected to the watch throughout the use of the app for it to work. I'm wondering whether a model like the following would be possible:
As above
As above
As above
3a. The watch stores the data locally
As above
Each change updates the watch app's local copy of the data
The user can later check the data back in to the iOS app at which point it is merged into the core data database
I can guarantee that conflicts would not be an issue as the user would never be able to modify data which had already been created on the phone (it is not a requirement of the app to be able to do so).
So my question is, would the latter case allow the watchOS app to operate independently of the iOS app with the exception of transferring data, and is this a preferable method to the way I am handing this currently?
It's simpler for your watch app to be dependent on the phone. It's more complex for it to operate independently of the phone. Only you can
answer whether the added complexity to support true independence is worth it, since you're the person who has to implement, support, and maintain any additional code needed.
Do the changes make the watch app independent?
No, they don't let the watch app operate independently, since the watch still must request/receive data from the phone during steps 2 and 3.
For the watch app to be completely independent while away from the phone, it would have to query a local copy of the data which the phone updated as needed, instead of requiring the phone to send any remote data that the watch needs.
Is the change preferable?
Not as it stands. Your proposed change to defer updating the phone (even though it's still reachable) may require much unnecessary code related to locally storing data for the present, and merging updates back to the phone in the future.
Also, while you promise there presently is no merge conflict to deal with, there's no guarantee that any revisions you make to your app in the future won't introduce the possibility for conflicts to occur.
If you choose to establish two persistent stores, it would make your app less fragile to implement a merge policy now, to avoid your updates from completely failing to save, should a future conflict occur.
The real question...
Is the freedom to operate away from the phone (for hours) worth showing stale (or possibly misleading) data to the user?
Unless you also provide an indication showing when the data was refreshed by the phone, the user may assume that the displayed information is current and accurate, even though it may be hours old.
This adds more complexity to the watch app either in the user-facing UI or behind the scenes to handle stale data.
For your consideration, Apple Watch's Weather app simply shows no data at all when it can't obtain the current weather data from the phone (since users would want to know the current temperature and chance of precipitation).
Problem
When A user downloads my application, they'll have the ability to use a certain feature. Say, 5 times. After them times are up, they'll require the iAP to continue using it. However, I have a few problems.
I want to make it simple, and just store it in the userDefaults, or keychain. However, if they re-download the app will they then have access to the feature another 5 times?
And I don't want to have to include external information from a data-base with user logins etc.
Solution
Being able to check if this particular phone has used the application before, if not. They have 5 goes stored in their defaults. However, if they haven't where to go from there?
1- At anytime the user may restore his device and reconstruct the keychain and use 5 times more.
2- You can set a server for user management.
I guess first option is acceptable and easier than second. Not much people resets his device's data just 5 more rights in some game.
Check NSUserDefualts if you have saved their usage counter. If you haven't, save it as 1, otherwise increment it.
If you've saved it before, and the increment is at 5, tell them that free trial is up.
Technology-wise - if they delete the app, I believe you'll lose your NSUserDefaults as you can see here. What about using iCloud? Is that too much? You could store that trial is up. But yes, internet connection would be necessary for that operation.
If your app is really good and users will want to use it then they won't think about deleting and re-downloading. If they won't see value in the iAP, they'll try to "hack" it. That's a philosophical answer...
I was attempting to use apple's HealthKit authorization modal in my App's settings, to allow a user to toggle their info on/off for sharing. It automatically pops up the authorization screen. However it seems to only do it once and then never again. At least until 24 hours later maybe, where it will prompt again if needed.
Is this meant to be used similarly to PushMessage requests, where a user is prompted once and then not ever prompted again from the same request?
I'm skeptical to add this modal prompt in the App's initial load as it is quite intrusive as a full screen modal; even if called only once ever.
Basically the user suppose to see it once (as when asking to grant push notification permissions, or access to contacts).
I have found out that for each datatype you want to share with Health app (or read), you got one shot with the modal prompt. This prompt might be a bit tedious to the user as it shows the entire types your app ask for permissions (both read and write), and I assume this is why Apple said a best practice of HealthKit is to ask the entire permissions your app need at the same time (though some might argue with that in a matter of UX).
If you wish to ignore Apple suggestions of this best practice, you can ask for read/write permissions for each datatype separately - Doing so will result prompting that modal sheet each time you ask the permissions to a different type.
In the bottom line, this permissions sheet is meant (by Apple) to be shown to the user once. You can find a way to pass that limitation (yet for a limit amount of times - depends on the amount of datatypes available), but I won't recommend bypassing Apple's guidelines (it is never a good idea).
A trick to use is to modify the Share/write types in your authorization, this will require the user to look at it again, thus pop it up every time.
I have a game where users can do a certain activity once per hour. How can I make sure it's been an hour since the last time they attempted something without them just changing their devices current time in settings?
Also, if I wanted to prevent the user from just deleting the app and re-installing it so they could constantly keep trying without having to wait to full hour is there any way I can store data on the device even after an app delete or would that have to be a server thing?
If I don't have a server can anyone think of a clever way to do this via Free in-app purchases or something?
The only way to persist data in a way that survives app reinstalls is to save it to the keychain. This works, because keychain data may be shared across multiple applications; the rest of your application's data is removed on uninstall.
If you need a reliable way to tell the current time, the device must be connected to the internet. In this case you would be able to check the current time using one of the time services through the NTP.
That sounds like exactly the sort of task you would need a server for.
When the user wants to perform this limited action, have them ask the server for permission. You can log the user's ID and request time, decide if they can execute the action, then return a small success/failure message. Works if they change their clock, works if they log in from a different device, works if they wipe the device data.
What I would like to know is whether there is anything wrong (in terms of the law, and App Store guidelines) with storing information about your application, and broadcasting it to an online location for gathering.
Specifically, an application which would normally not connect to the internet, connecting when it starts up and storing usage information like time of day, the device ID, and how long the person uses it for.
I'm guessing this sort of behavior is fine so long as you get the users consent first?
It’s fine if you ask the user first and give him an option to turn this feature off. We were once spanked out of the App Store simply for uploading a new game high-score record without a cancel button. It’s quite a long time and the rules might have changed, but better safe then sorry and your users will like the confirmation screen, too.