UIApplicationWillEnterForegroundNotification

UIApplicationWillEnterForegroundNotification

[nicklockwood]

Hi Mic,

It shouldn't impact it, but maybe a better idea would be to use the significant event count feature instead. You could log a significant event each time the app launches, and use that to trigger the rating dialog instead.

As I said, it shouldn't be a problem to disable the notification, but you're better off not modifying the library unless you have to because that way you won't have to re-apply your change every time I do a new release.

Nick

(Sent from my iPhone)

On 14 Dec 2011, at 10:51, Mic Pringle [email protected] wrote:

Hey Nick,

Would it cause iRate any issues if I remove the support for the above notification ?

My iOS app is a music player which will naturally spend most of its time running in the background, only being brought to the foreground by the user when they wish to change the track or album etc. Therefore I don't think that using this notification to increment the use count really suits this scenario, and as such I would only like this to happen on app launch.

As far as I can I only need to remove the observer and the subsequent selector but before I do this I just wanted to make sure nothing else, that Iv'e missed, relies on this particular notification.

Mic

---

Reply to this email directly or view it on GitHub:
#10

Hey Nick,

If I do go ahead and modify iRate I'd probably maintain my own branch so as not to end up in the situation you describe.

I did think about using the significant event option but it seems incorrect to do so as application launches shouldn't be seen as an external significant event since support is already built right in.

At the moment I have three options ...

1 - Modify the code to remove the UIApplicationWillEnterForegroundNotification observer
2 - Set the usesUntilPrompt to a really high number
3 - Use the - (void)logEvent:(BOOL)deferPrompt method to log each launch as a significant event

Perhaps a better option would be to add a method/property to disable the UIApplicationWillEnterForegroundNotification support so the developer can continue to use iRate in the manner intended, without any workarounds, but the decision is put on the developer as to whether bringing the app to the foreground should be treated in the same manner as launching the app.

Let me know your thoughts.

Mic

[nicklockwood]

Hi Mic,

Here's how I see it:

My aim with the library is to make it as useful as possible to a wide audience, but avoid adding features that only apply to one user, or where it will improve the library for a few users at the cost of the majority.

Your aim should be to use the main fork if possible, or persuade me to make changes to the library to support your needs if it doesn't already do so, and only as a last resort should you fork it because even with github's excellent merging, that's still making more work for yourself, risking introducing bugs, and losing the benefits of me supporting issues you have in future.

It doesn't sound like your problem is particularly unique, but the solution of disabling the foreground event is obviously not something I could ever merge into the trunk. A better solution might be to do as you suggest and add a flag to ignore foreground events, which could then be a feature I could merge back in, but before doing that, let's just analyse your problem at bit more:

There are three way to trigger a prompt at the moment: 1) number of launches/foreground events, 2) number of days, 3) number of user-defined events.

Criteria 1 and 2 must both be met to trigger a prompt. Criterion 3 is independent (it will trigger a prompt even if 1 and 2 have not been met).

The aim of these options is to defer the prompt until the user has used your app for a long enough time to have developed an informed an opinion about it (preferably a positive one). For a typical app like a game, this period is about 10 days assuming they use it at least once a day, which is why the uses and days both default to 10.

The reason why I treat foreground events as a use is because app launches are a very poor metric for interaction on modern iPhones because an app may stay running for days at a time but be opened and closed multiple times during that period. This is equally true for your app - cold launches tell you nothing about how much users are interacting with your app.

On the other hand, foreground events are quite a good metric for how much people are using your app. A user who installs the app, runs it a few times but then never really interacts with it won't generate any foreground events. A user who does use it properly will presumably frequently change tracks and so generate a lot of foreground events - more than most users of most apps.

So it seems to me that the best option is to do exactly what you said in option 2; Leave the days parameter at the default of 10, and set the uses parameter to something much higher than normal, say 100. That way users will only be prompted if they have had the app installed for at least 10 days and have used it a reasonable amount during that time.

Alternatively you could ignore the days and uses completely (by setting them both to a very high number) and log an event whenever the user plays a track, or whatever other metric makes sense for your app, and then prompt the user after they've played 100 tracks (or whatever).

Nick

Thanks for the very comprehensive response Nick.

I need to give this some more thought, especially your idea of ignoring uses and days altogether and instead using an app specific metric such as track plays which is something I'd not considered previously.