Braydon_SFXMember, Sous Chef, Bowlboy SidekickPosts: 9,273
edited September 2014
Great video as usual.
The reason why your text expression was firing when the "contained" condition was selected was because of the state of the table - "unpurchased" was most likely contained in that cell. The phrase "purchase" is contained in the word "unpurchased" - which is why it was firing.
Thanks for recording! Huge help!
....Just cause I'm a nice guy...I'll give you an "awesome."
I have been struggling with the placement and handling or "Request Purchase Data". I agree with you some people wont log into the store and choose cancel then look at the items for sale. The problem is if they then decide to buy something and press the items button they wont be able to buy because the table is empty.
The ways to handle this that I can think of are;
Have a Open Store/Store Open button. Problems with this are it is an extra step in the process.
A Popup explaining to the user they are not buying anything only logging into the store. Problem it will still have the word buy or purchase in it and it may still freak out people who are not fluent in english.
Put "Request Purchase Data" in each buy button. Can't see a problem but that doesn't mean there isn't one.
I am overthinking it and stop worrying about it.
***EDIT: @CodeWizard I just did another test I logged out of the store and reinstalled my app. I pressed the buy button and when it asked me to login I cancelled but it still retrieved the table information even though I wasn't logged in.
My question is why ask them to log in at this point why not do this when they are ready to buy?
@colander, a combination of options 1 and 2 is the best way to do it. One call needs to be made when displaying the options anyway to get the localized descriptions and price.
To option 3: Putting the data request in each button (option 3) can be very annoying or unnerving in countries with low mobile bandwidth. Fetching even a single item could take a few seconds. And the description/price should be prefetched once anyway.
@Hopscotch said colander, a combination of options 1 and 2 is the best way to do it. One call needs to be made when displaying the options anyway to get the localized descriptions and price.
I have seen this mentioned before somewhere else. I have only tested on iOS and they display all the purchase data so why do we need to display it also? I assume the others also do this. It has been awhile since I bought anything on Amazon and I can't remember how they handle it and I have never used google or Tizen.
To option 3: Putting the data request in each button (option 3) can be very annoying or unnerving in countries with low mobile bandwidth. Fetching even a single item could take a few seconds. And the description/price should be prefetched once anyway.
People will only press the buy button when they are ready to buy and it will only ask them to login if they are not already logged in. It will do this anyway as part of the purchase process by putting the two processes in the buy button you only get asked to login once if they are separate you will be asked twice if you are initially logged out. It will just update the table and they will never know it happened. You may even be able to update the relevant row but I haven't tested that.
@The_Gamesalad_Guru said:
I believe that is the OS requesting the login not GS. If a person is logged in as most users are for cloud access et.. It doesn't ask you to sign in.
I think so too and hadn't thought it could be GS until you mentioned it. I am only thinking of people who prefer to be logged out and only login when they have too and when someone is logged out by the app store, by accident, by their carrier, etc.
@colander, you should call Request Purchase Data as your shop scene opens or in the change scene behaviour just before.
The Request Purchase Data behaviour triggers the login request if the user is not already logged in. This is necessary though to fetch the current and localised description and price for each item that is to be displayed on your purchase buttons. This is how the guidelines want it.
@Hopscotch I see what you are saying you need to do it this way to display the localised data in the text beside the button or in the button or both.
I am not too concerned about that, everything else in my app is in english so I will keep the store text in english too. It will be displayed in their language by the store when they go through the purchase process. Regarding price data nearly everyone would know their approximate exchange rate anyway.
Having said that I can see the value in using localised data and need to think about it some more. The first thing that comes to mind is I use custom fonts which I will have to ditch and use the standard GS fonts which don't look so good.
As I said you don't need to fill in that data just display it from the table when the data is pulled then the name and price will be in the rate of the store being called and the name will be in the language.
@The_Gamesalad_Guru said:
As I said you don't need to fill in that data just display it from the table when the data is pulled then the name and price will be in the rate of the store being called and the name will be in the language.
We understand that the data in columns 3 to 5 comes from the provider we are only discussing the second half of your statement, to display it or not, the pros and cons of it.
Great video as always!
Not sure why, but it won't ask me to log in to my iTunes account when testing in AdHoc.
Also, the state of column 5 is automatically purchased. Any thoughts?
@The_Gamesalad_Guru
OK, but Im not prompted to log in at all so i can't sandbox test it. The only rule that fires is my change attribute. Nothing gets updated in the tables since Im not able to log in.
@Dues said:
The_Gamesalad_Guru
OK, but Im not prompted to log in at all so i can't sandbox test it. The only rule that fires is my change attribute. Nothing gets updated in the tables since Im not able to log in.
I usually have to log out of my itunes account in the iOS settings before I'm prompted to login my app
@Dues said:
The_Gamesalad_Guru
OK, but Im not prompted to log in at all so i can't sandbox test it. The only rule that fires is my change attribute. Nothing gets updated in the tables since Im not able to log in.
If you're doing a repeat test and you already signed into your sandbox and didn't sign out it won't.
@jonmulcahy Tried thats also but it did not work. Thanks
@The_Gamesalad_Guru
Hmmm.....I clearly must be missing something somewhere......The problem is I never got asked to log in to Itunes in the first place.
I thought that when the callback rule is fired I would get a pop up saying: log in to your itunes account, but I didn't.
I also tried creating a new testuser but the problem is still the same.
@The_Gamesalad_Guru said:
So when sandbox testing you know not to sign into it through settings right? Make sure you're signed out of any account before you open the app.
Yup, still does not work
Have to go over it again.
@Dues If you fill in your "Product ID" in "In App Purchase - Buy Item" don't use the Expression Editor but type directly into the empty field. That worked for me, maybe it works for you too.
The_Gamesalad_Guru
Member Posts: 9,922
Comments
The Guru is fantastic, follow the path of the Guru!!
Thanks
Well presented and clearly explained as always!
Thank you @The_Gamesalad_Guru!
Thanks @The_Gamesalad_Guru - Nice work!
Thanx all!
Great video as usual.
The reason why your text expression was firing when the "contained" condition was selected was because of the state of the table - "unpurchased" was most likely contained in that cell. The phrase "purchase" is contained in the word "unpurchased" - which is why it was firing.
Thanks for recording! Huge help!
....Just cause I'm a nice guy...I'll give you an "awesome."
Thanx for confirming that @Braydon_SFX I realized that after some thought. I don't usually do a ton with text as triggers.
Good Job! Thanks!
I have been struggling with the placement and handling or "Request Purchase Data". I agree with you some people wont log into the store and choose cancel then look at the items for sale. The problem is if they then decide to buy something and press the items button they wont be able to buy because the table is empty.
The ways to handle this that I can think of are;
Have a Open Store/Store Open button. Problems with this are it is an extra step in the process.
A Popup explaining to the user they are not buying anything only logging into the store. Problem it will still have the word buy or purchase in it and it may still freak out people who are not fluent in english.
Put "Request Purchase Data" in each buy button. Can't see a problem but that doesn't mean there isn't one.
I am overthinking it and stop worrying about it.
***EDIT: @CodeWizard I just did another test I logged out of the store and reinstalled my app. I pressed the buy button and when it asked me to login I cancelled but it still retrieved the table information even though I wasn't logged in.
My question is why ask them to log in at this point why not do this when they are ready to buy?
@colander, a combination of options 1 and 2 is the best way to do it. One call needs to be made when displaying the options anyway to get the localized descriptions and price.
To option 3: Putting the data request in each button (option 3) can be very annoying or unnerving in countries with low mobile bandwidth. Fetching even a single item could take a few seconds. And the description/price should be prefetched once anyway.
I believe that is the OS requesting the login not GS. If a person is logged in as most users are for cloud access et.. It doesn't ask you to sign in.
I have seen this mentioned before somewhere else. I have only tested on iOS and they display all the purchase data so why do we need to display it also? I assume the others also do this. It has been awhile since I bought anything on Amazon and I can't remember how they handle it and I have never used google or Tizen.
People will only press the buy button when they are ready to buy and it will only ask them to login if they are not already logged in. It will do this anyway as part of the purchase process by putting the two processes in the buy button you only get asked to login once if they are separate you will be asked twice if you are initially logged out. It will just update the table and they will never know it happened. You may even be able to update the relevant row but I haven't tested that.
I think so too and hadn't thought it could be GS until you mentioned it. I am only thinking of people who prefer to be logged out and only login when they have too and when someone is logged out by the app store, by accident, by their carrier, etc.
@colander, you should call Request Purchase Data as your shop scene opens or in the change scene behaviour just before.
The Request Purchase Data behaviour triggers the login request if the user is not already logged in. This is necessary though to fetch the current and localised description and price for each item that is to be displayed on your purchase buttons. This is how the guidelines want it.
@The_Gamesalad_Guru
Great work as always!!!
@Hopscotch I see what you are saying you need to do it this way to display the localised data in the text beside the button or in the button or both.
I am not too concerned about that, everything else in my app is in english so I will keep the store text in english too. It will be displayed in their language by the store when they go through the purchase process. Regarding price data nearly everyone would know their approximate exchange rate anyway.
Having said that I can see the value in using localised data and need to think about it some more. The first thing that comes to mind is I use custom fonts which I will have to ditch and use the standard GS fonts which don't look so good.
@colander, yes, the font style break is an issue.
But THAT is precisely why I have been preaching for Device Language attributes.
http://bugs.gamesalad.com/show_bug.cgi?id=289
That way you could have different graphics depending on language for purchase buttons. Depending on how many different languages you want to support.
The current price is supposed to be read from the server though, as the tier pricing may, and does, change over the lifetime of your app.
As I said you don't need to fill in that data just display it from the table when the data is pulled then the name and price will be in the rate of the store being called and the name will be in the language.
We understand that the data in columns 3 to 5 comes from the provider we are only discussing the second half of your statement, to display it or not, the pros and cons of it.
Thank you!
Great video as always!
Not sure why, but it won't ask me to log in to my iTunes account when testing in AdHoc.
Also, the state of column 5 is automatically purchased. Any thoughts?
For non consumables once you buy it with the test account you can't reset it.
@The_Gamesalad_Guru
OK, but Im not prompted to log in at all so i can't sandbox test it. The only rule that fires is my change attribute. Nothing gets updated in the tables since Im not able to log in.
I usually have to log out of my itunes account in the iOS settings before I'm prompted to login my app
Thanks a lot @The_Gamesalad_Guru
If you're doing a repeat test and you already signed into your sandbox and didn't sign out it won't.
@jonmulcahy Tried thats also but it did not work. Thanks
@The_Gamesalad_Guru
Hmmm.....I clearly must be missing something somewhere......The problem is I never got asked to log in to Itunes in the first place.
I thought that when the callback rule is fired I would get a pop up saying: log in to your itunes account, but I didn't.
I also tried creating a new testuser but the problem is still the same.
So when sandbox testing you know not to sign into it through settings right? Make sure you're signed out of any account before you open the app.
Yup, still does not work
Have to go over it again.
@Dues If you fill in your "Product ID" in "In App Purchase - Buy Item" don't use the Expression Editor but type directly into the empty field. That worked for me, maybe it works for you too.
@een2drie Thanks!
Thought I had gone through them all but apparently not!
Now Im going to face palm myself......hard...