"1) wait for the response back from the server to see what has been drawn. 2) Choose the wheel according to the reward."
The wheel now comes to rest on the prize you actually won. Until today it span to a random position and the prize appeared in a popup that had nothing to do with where the wheel stopped — you could watch it settle on "Free Latte" and be told you'd won something else.
The server still decides the prize, exactly as before. Nothing about how a shop's odds work has moved into the app, and the app still can't see the weightings. What changed is the sequence: the app now asks the server first, waits for the answer, and only then spins — aiming at the slice that won. Previously it started spinning the moment you pressed, so by the time the answer arrived the wheel was already on its way somewhere arbitrary.
The prize is announced only once the wheel has stopped, so the popup confirms what you can already see.
The result now carries the identifier of the pool entry it came from, and the wheel is drawn from that same list, so the app can point at the right slice with no guesswork. Matching on the prize's name would not have been safe — and this isn't hypothetical. The demo shop's live pool has two different entries both called "5 Points", and during the checks the draw returned each of them. By name they're indistinguishable; by identifier they're never confused.
A bug found along the way. The spin animation was being started as part of drawing the screen rather than in response to the press, so any incidental redraw quietly queued another spin. That was survivable while the stopping point was random — the wheel just span longer — but it would have pulled a spin off target now that it has somewhere specific to stop. Fixed as part of this.
| Suite | Result |
|---|---|
| App, on the real screens, incl. a control run against the old version | 6/6 |
| Staging, against the deployed service | 5/5 |
| Staging smoke regression | 5/5 |
The app checks read the wheel's real resting angle off the screen and work out which slice is under the pointer, rather than trusting the number the app asked for — a test that recalculated the same sum would agree with a wrong one just as readily. Done on the first, middle and last slices, because this kind of arithmetic wraps around and an off-by-one hides easily in a single example. One check deliberately holds the server's answer back for a moment and fails if the wheel starts moving before it arrives, which is the whole mechanism Narong asked for. Run against the previous version, the checks drop to 2 of 6.
The staging run spins the real service and puts everything back afterwards — the points, the spin chances and any coupons it caused — and it verifies that cleanup rather than assuming it.
No database change was needed. Verified on staging. A new Android build is needed for this to reach the phone.