I think there’s an uneasy relationship between OGS and the 3rd party phone clients: on one hand it’s great to have a variant of excellent options for folk to use the server. Clearly the OGS API is supported for exactly this kind of reason.
On the other hand, phone clients take users away from features that might persuade them to help pay the bills. So implementing features specifically for people who then won’t use the OGS client seems like it would be a dubious proposition.
Would the availability of push notifications for OGS supporters persuade you to sign up as a supporter?
That doesn’t sound especially convincing. I don’t expect the native clients take away any users from the web site - they allow users to play who otherwise wouldn’t or would play less frequently. A lot of my play time at the moment is with the Sente app but I wouldn’t think to stop supporting ogs because I don’t use the web UI as often as I used to.
Basically, I’m pretty sure it’s not a zero sum game, I expect pretty far from it.
Would it be possible to add the AI Review to the API calls? Then the app can call for the review sgf and it would have the ai at the level the user is paying for.
Notification servers are cheap and notifications help with retention - OGS would probably benefit more by offering such a feature to everyone if it existed.
I assumed the main reason notifications aren’t well supported yet is that the setup isn’t straightforward trivial
Interesting take. It’s definitely not how I see it, and I was under the impression that @anoek does not see it as such an adversarial relationship either. I could be wrong of course, and I realize that nowadays Anoek is not the only developer, but as siimphh says I don’t think this is a zero sum game. Like it or not, many users (particularly the young ones) judge an online platform like OGS higher if they have a decent mobile app as well.
If the desire would be to just not allow the 3rd party apps to be decent, then Anoek could just pull the plug…
They could definitely steer you towards OGS instead of using some of the other online services (fox or kgs or whatever) that might offer it. They could steer you towards OGS instead of relying on some crap app that you see on play store. They could in fact steer you towards playing GO instead of giving it up in disgust (e.g. grow the whole market, thus growing your share).
If driving more traffic to the website is a concern, we can discuss how I can link the site in the app. Already in each game you can “open in browser” (which I use to see AI reviews), but if something more visible is required, then of course that can be added.
Bottom line is, from what I understand the effort to support push notifications is really low, and it might even be used to support proper browser notifications. I understand that the creator of Surround just implemented it on his own server and is just polling server to server. His solution would not scale IMHO, I’m just mentioning it to show that the effort was probably not that big.
The AI review API is already there and I could implement it, but then I’d have to try and explain to the user about OGS supporter. Due to the google policies I can’t just link to the website for them to purchase it as that would get my app banned. I’d have to use the google play payment system with takes 15% + local taxes (such as VAT) off the top. It would also create some interesting tax implications.
I certainly don’t speak for anoek - if you’ve spoken to him already, then you probably know better than me what he thinks about it.
I just described how I would see it if my primary income depended on OGS donations.
If you could elaborate on how that would help, it seems like that’d be a good idea.
OGS definitely would benefit from the increased number of users, which is a very important thing to achieve.
But I struggle to see the incentive - even any “advertising or other inducement” - for people who use the 3rd party clients to sign up as supporters of OGS.
… right, but “use OGS” is only part of the goal. More users → good. But not sufficient. “More supporters” is what pays the bills. “More users but decreasing proportion of supporters” is a dubious proposition.
Obviously it’s not that simple - clearly effort goes into supporting 3rd party apps That’s why I described my perception of things as “uneasy relationship”.
And that’s why it strikes me as a win-win if push notifications were a supporter feature…
Just to clarify I don’t feel there’s any adversarial relationship, the mobile apps fill a need that OGS doesn’t have the resources to provide itself. Plus, there’s a lot of users that use both, so it’s not cannibalizing or adding undo extra support I don’t think, I think it’s great.
Anyways, re notifications, it’s one of those things where I’m probably making a mountain out of a mole hill a bit, but basically the complexity is that it’s not just a matter of slapping in the 5 lines of code or whatever it’ll take to actually send out the notification. It’s a matter of
Adding systems for device registration for a minimum of 3 platforms - Android, Apple, and web - which I’m not sure if there are sub cases for that or not. All of these take a bit of research.
While we’re at it, might as well add webhooks to help support the third party sites, or at least lay the groundwork for it.
Supporting multiple devices for each of those
Supporting multiple apps for each platform, or at least add the ground work for that
Supporting multiple player accounts per application, which will presumably share the same notification delivery address, which has some implications about how things are displayed and managed on our end.
Creating a UI to support device management and the notification controls that’s not exceedingly complex
Updating/revamping the notification system to control which notifications go to where and dealing with multiple platforms/devices per platform/player accounts per device.
Last time I worked with Apple Push Notifications you couldn’t just connect and send one message per connection if you were sending a lot of notifications, they wanted you to connect a small number of times and send lots of notifications per connection. This implies a very different pattern than we currently employ for delivering notifications so will require writing up a new service to deal with it.
Creating minimal apps on ios and android to test using multiple users on the same platform, registration, de-registration, re-registration, blocking and unblocking notifications, and whatever else a user may be able to do.
Navigate adding whatever app keys to the appropriate places so things work for production, beta, and ideally development if apple/android/web will work from a development environment. (If it’s only on beta, that slows down the development cycle a lot)
Whatever else I don’t know that I don’t know and learn along the way.
The 5 lines of code to actually send out the push notification.
So I view it as a bit of a notable undertaking. Certainly doable and something that we want done, but it hasn’t made it to the top of the big-project-todo list yet.
Voice of experience in real-world job here here: improved processes around managing settings on different environments: you might want notifications coming from beta/test/dev environments briefly during testing of those features, but you don’t want to leave them on for ever, or send them to the production destinations, or else you end up sending your customers duplicate notifications. “Oh let me just comment out that ‘if env == PROD’ line, I’m sure I’ll remember to put it back” doesn’t really work.
Surely we don’t need anything even remotely as complicated as that. What I’m thinking is something along the lines of: Google Cloud Messaging | CodePath Android Cliffnotes It’s just a couple of endpoints and a database table.
I’m sure @HongAnhKhoa can back me up on this as he did it for Surround.
For Surround, it’s much more complicated than that. However, a lot of the complications are due to the fact that it’s a proxy server and not OGS itself. Some examples:
I need each client (can have multiple clients per user) to tell the server what they have seen, so that when a client has seen a move then the notification for that will not be sent to the other clients.
I need to parse and compare OGS data on server to figure out what notifications need to be sent.
Each client can have their own notification settings. (A real example: user can set the notifications for “time running out” to be sent to both their iPhone and iPad, while notifications for a new move to be sent to their iPad only)
It should be simpler to implement push notifications from OGS server, but still not as simple as your article. At least OGS needs to have a way for mobile clients to give them push credentials, and also needs to support multiple devices.
This is correct, I got away with it easily because I set up my server from the beginning just for push notifications, so I can use Python’s asyncio for everything. Adding this to an existing server is not a trivial task.
Also, I imagine debugging push notifications while the backend and the client are control by different parties will be quite painful…
For me, I would much prefer that OGS supports webhooks for notifications. That should be much simpler to implement and it will eliminate the majority of the complications and server cost for me already. (Another minor reason is that I am not entirely comfortable to give OGS the ability to send arbitrary push notifications to my app).
I can make push notifications in my app available to everyone for free if webhooks are supported.
This would not be hard for OGS: whenever OGS sends a websocket notification for a new move without the user being present just send a push instead.
That’s not how most notifications services work, right? If I get a new email I get a push on all devices where I have gmail installed. If I view the email on my phone, the notification on the tablet does not magically disappear. That would be unnecessary work, at least it would be something to be done as an improvement at a later date.
On android at least this can be handled on the receiving end, no need to bother the backend with this. Backend just fires notifications (they are free on FCM), it does not need to handle anything else.
Yes, I agree the endpoint that needs to happen is the one where the device agrees on a token with the server. And yes, it does need to support more than one device.
Right, that’s why I said the complication was due to the fact that my server is not OGS
I found out that this needed to be done during testing. Otherwise, if you are logged in on two or more devices, while you use one of them to play your correspondence games, the others will get a lot of notifications due to your opponents making move in those games you just played.
It’s not possible on iOS (at least when I worked on this), you can run some logic before displaying a notification but you have to display something after receiving a push from server. This is to prevent apps from abusing notifications to keep running in the background.
Hi folks, long time, no see. But here’s a big update for your enjoyment:
· Puzzles screen (thanks to bqv for the contribution)
· More notifications controls. You can now disable notifications for live games for example.
· Screen will now stay on while playing a game (thanks to kpe for the contribution)
· Lots of bugfixes
· Stats screen improvements (thanks to bqv for the contribution)
· Fixed issue with rewinding a face-to-face game with handicap
· Fixed an issue with refusing to give notification permissions causing the app to become unresponsive.
Small bug to report. I am using the client on a onyx boox page eInk tablet (1680 x 1264). When starting “face to face” mode the bottom controls (new game, pass, etc) are not visible
Thanks for the report. It sometimes happens (it’s a bug somewhere) but it should clear itself out when you open the game. Can I get a link to the game if it doesn’t?
Love the app! Been having a new issue with it lately, though. When I click “Play Online” and hit “Search”, the “Searching” indicator no longer comes up, and I never end up in a game no longer how long I wait. Seems like it just immediately cancels the search.