I need to be able to consume a purchase without an Android client being connected using a backend server. Is this possible? If not, why? I am trying to make it possible to process a purchase entirely without a user being connected in the case of a disconnection.
Do I need to send a message to my client from my server requesting consumption and then provide a response to the server when the purchase is consumed? This is what I am trying to avoid.
I see various other similar questions but they are for the AIDL API which is now discontinued for google-in-app billing.
Relative API(s);
https://mvnrepository.com/artifact/com.google.apis/google-api-services-androidpublisher/v3-rev103-1.25.0
SOLUTION: To my knowledge, at this current time, July 2019, it is not possible to consume a purchase from a server. It is only possible from the android client.
This means that the flow of the purchase depends on a request to a client and an response from the client, followed by a required GET to validate the purchase has actually been consumed.
Related
I need a good design to read the location from a user1 iOS and send it to user2 iOS.
How I should send this to the backend, using rest APIs?
The location data pushed to server should be at 20sec interval or more?
Once the location info is with backend how it should push that to user2, badges or a poll from the app?
Please suggest.
Of course, first step is to send the information to the backend, in that case you only need a rest api exposed with a method that can receive the POST.
Second step is send the information to the second device. Here you can implement in two ways:
Push notification, you can use tools from the iOS libraries to send the information to the second device and the application will use this information.
Read more about this here: https://medium.com/ios-os-x-development/learn-master-%EF%B8%8F-ios-remote-push-notifications-in-2018-in-under-10-minutes-825ca6bee092
Second option, it is to implement a websocket, your second device will be connected with a web protocol to receive information from the server. This is a solution for real time systems, every thing you need to send will be received by the target in milliseconds.
I'm trying to add an in-app subscription to my app and if I understand Google's guidelines correctly, the proper way to validate in-app purchases is as follows:
My app queries active subscriptions from Google's billing API
My app sends active subscription details to my server
My server sends the details to Google, which responds with whether they are valid
My server responds back to my app with whether the details are valid
My app now knows whether the user is legitimately subscribed
I'm not very familiar with network security, but this process is apparently secure because the alternative is to validate the subscription solely in the app which attackers can reverse engineer and figure out the logic behind it. But I fail to see how receiving a yes/no response from my server is better. Couldn't attackers spoof my server's response if they wanted? Or at least modify the code where the yes/no response is interpreted?
I am using mqtt and mosquito broker to build a simple instant chat for an android platform. Now I wanted to implement a condition where any client can check if another client is online.
I know about Last will and testament but I wanted a user to be detected offline only wen the application is inactive or the user is not currently using the app.
I actually dnt need any code, buh wanted an idea as to how to implement this and I would be much grateful.
You can do this without relying on MQTT internals which is much easier in my view. With this approach, you have much more control over what is going on:
The client can periodically send a message within another topic to inform the server of its availability. In case the server does not receive that message after a specified amount of time, it can assumed that it is offline.
The client can also send another message if the user logs out and inform the server a well.
If you insist on using MQTT internal structure, you may find this question useful:
How to Find Connected MQTT Client Details
I've been looking online for examples for this but I can't seem to find any. I'm trying to write a function in my groovy/ratpack web app that sends out email notification whenever an event is triggered. Any ideas would be apprecatied.
Have you considered using a service like SendGrid? https://sendgrid.com/pricing/
They have a free plan of 12,000 emails per month. You can use the http api with Ratpack's non blocking http client
I am looking for some guidelines as to how to secure requests from android client to server
How can i prevent un autenthic (users which initiate requests not from the android app) requests to be accepted and processed by the server?
Waybe generate token at user registration and use it somehow at each call?
My server is a lite instance and performance is top issue in the implementation of the server client communication.
Appreciate any help!
You could use Google Cloud Messaging as a via medium to make sure messages that reach your server are from the app, without getting too involved in details. Check the documentation here:
https://developer.android.com/google/gcm/index.html
Or else, as you said, create a unique id on registration and send it back to the client. Store it at both client and server. Now with each request from the client, add an extra field in the request and send the id also. Check this id serverside and make sure it is valid (this check could eventually become heavy on time).