Thanks, folks! It looks like there is a great challenge to make it work correctly. Let me refine the problem just to add interest.
First, the client signs into the app (getDealDone), at the same time committing to automatically renewing subscription. Let's assume this is on the next to the last Monday of March or September (for simplicity we are still all in Europe). As everyone would, so I have given seven (7) days of Free Trial Period. Here I want to put a trigger into the device to cut off in seven days, on the last Monday of the month - where we have tuned the clock ahead. Why in the device; the other alternative is to cron the server part to do the API calls just too many times per each 24 hours - which may be the only reasonable solution. Actually Google Play is setting the expiry correctly for the expiry day, but it does it day by day. So, for the first Tuesday after the initial subscription commitment, the expiry is exactly in 24 hours (give or take a few milliseconds spent in network comms and server response). Ant it goes on, and actually for the 7th day it does implement the move of the clock in the expiry time. For me it would be logical GP would set the correct time for the 7th day from the beginning, but these guys want to do it day by day, asking all people to send API's to them every day. It is vital to take the Google Play expiry milliseconds in, if you want for example to give a client a deferral in the next payment. All this is very simple, if you deal with a limited number of users for your app. But when you get to a few tens, not to speak about my dreams, or for any expiry times cross the summer/winter time changes with different countries, it begins to fall apart. And we haven't yet spoken about the case of September nor the case of those happy nations not implemented this clock jiggle. Does anyone have an idea how Apple is working with the subscription expiry's? The next chapter will be about the exchange rate changes and VAT stuff - more fun. _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
