UrbanApps / Armchair

A simple yet powerful App Review Manager for iOS and OSX in Swift
MIT License
1.2k stars 137 forks source link

Armchair alert doesn't show up #38

Closed odedharth closed 8 years ago

odedharth commented 8 years ago

Hi,

I set Armchair this way:

            Armchair.appID("1044050208")
            Armchair.significantEventsUntilPrompt(0)
            Armchair.daysUntilPrompt(0)
            Armchair.usesUntilPrompt(3)

And expected Armchair will show up on the third sessions, but nothing happened.

coneybeare commented 8 years ago

Did you step through the code to see why?

odedharth commented 8 years ago

@coneybeare which object should I debug?

coneybeare commented 8 years ago

I would place your breakpoint either in showPrompt or ratingConditionsHaveBeenMet

grizzly commented 8 years ago

same here, seems both of your mentioned functions are never called....

your incrementUseCount() only increments the values but never calls showPromt (or did i miss something?)

coneybeare commented 8 years ago

incrementUseCount is never called directly by the user, but is called before a call to showPrompt in incrementAndRate. Can you reproduce what you are seeing in the example project with a basic setup?

coneybeare commented 8 years ago

Actually, I see why this might be happening. Sorry it took me some time to reacquaint myself with the code.

The application lifecycle notification callback methods only call incrementUseCount and not incrementAndRate. This is fine and by design so that the user is not bombarded with a review prompt immediately after opening the app, where chances of a review are lower. The library was really designed to keep significant events as the primary trigger for a review, when the user satisfaction is highest. A user is more likely to review if you do so at a point where it does not interrupt their flow. They came to your app for a reason, and now once they are in, you are asking them to stop doing that reason while they help you out by writing a review. Let them finish that reason (beat a level, do a thing, open stuff, check this or that) then ask them upon completion of said significant event.

But, if you want to keep significant events at 0, you should manually add showPromptIfNecessary wherever it makes sense in your app. I would recommend using significant events to trigger instead though as you will get better clickthrough rates to the App Store.

This presents a minor problem for me because the default for this value is 0 (has to be) so I may add a condition to the lifecycle callbacks that checks whether or not this value is 0 and perhaps call for a prompt. I have to think about it because it could cause unintended prompts for others. My gut tells me no and that the solution is for you to add the showPromptIfNecessary call to your setup, and add this info to the readme.

Either way I decide, you have a solution now.

grizzly commented 8 years ago

yes thats the point. if you only want to have the use count (as odedharth describes) there is no call of showPromt. Your class is incrementing the useCount value but then never tries to fire the showPromt.

Other cases have this call: if someone calls userDidSignificantEvent, the function itself calls incrementSiginificantEventAndRate, which calls showPromt.

so do we have to call showPrompt(ifNecessary.... explicid?

best stefan

coneybeare commented 8 years ago

Yes, that is the solution (for now) as I detailed in length above. If you are using significant events at 0 (highly unadvised) then you will have to call showPromptIfNecessary() from wherever it makes sense in your app. Fixing the lifecycle callbacks so that it automatically shows on app open or launch would introduce unwanted behavior for just about everybody who is using significant events > 0.