I have two separate APK's on Google Play. I'm planning a new version of each of them that has a new in-app purchase.
I want each of my two apps to be able to query the other one to see if the item was already purchased in the other app, so the user will not have to buy the item in both apps if they have both apps installed.
I have already released both apps and they do not have a shared ID, so I don't think that's an option, because I don't think you can change the sharedID on a published app. Also, it is possible that the user installs/uninstalls these apps in various orders, or downloads them on another device, so it is not adequate to simply make a Broadcast at the time of purchase.
Is there a way to query another app for a simple boolean response?
Is there a way to query another app for a simple boolean response?
I affraid not.
most close to it would be sharing preferences across packages, but its not officially supported, and I wouldn't count on it to work across all platforms.
or MODE_WORLD_READABLE preferences, but as mentioned in the answer - it's not secure, and it anyway deprecated in API 17.
only 3 ways supported with android API to communicate between different apps are:
Accessing ContentProvider
sending and receiving BroadcastReceiver
remote Service binding
I think that you can achieve easily your goal with any one of the three, although you right when you say that sending broadcast from one to another is not the safest way.
if I had to implement such feature - I would create a simple ContentProvider from one of the two apps, and access it from both apps to store and retrieve this shared information/data.
another good approach, would be doing some server side verification to get this information. of - course it limitations are that you need to have one, and you have your users to be connected to network for that..
Related
We have a requirement to share some very simple data between Android apps, the data will basically just be a string but we want to ensure it's only shared between apps signed by us. The sharing of the data also needs to be programmatic i.e. without user interaction to initiate the sharing.
The issue we have with many of the data sharing methods we've found is that they imply the data is owned by one particular app which then makes it available to other apps. The data we need to share could be generated by any app so it doesn't have a natural owner.
Our ideal solution would be something similar to the Keychain on iOS where any app can write the data and any app can easily check if the data has already been written.
We have seen some solutions that involve setting a shared User ID for the apps but this appears to be deprecated in Android and also one of our apps is already in the store so the ID cannot now be changed.
Is anyone aware of any possible solutions on Android for this usecase?
Illustration:
How do I pass data coming from a form in my app to a third-party app?
Also, what are the terms, functions and APIs about doing this?
It is possible through Intent and URI.
The app that is receiving your data should support be open to receive URI so that you can fire up the Intent method it will open the app and send data.
You can refer: https://developer.android.com/training/basics/intents/sending.html#java
Unfortunately there is not a one-size-fits-all solution to this question, as such you are going to receive a variety of different "solutions" but the truthful answer is, it depends on the implementation of the app built by the other party;
Intents
If the third-party app is open to receiving data through intents, and hopefully the developer of that app has documented this somewhere. This would be the most streamlined approach.
It is important to note with this implementation that if there are specific apps you have in mind to connect to, and your application is going to be publicly available, then the user will need to have those specific third-party apps installed. This is easier if you only have one specific third-party app in mind (you can check the user's device to see if it is installed and inform them), and gets exponentially more cumbersome for every additional application you wish to connect to, not only due to having to instruct the user about yet another required third-party app but also as you will need to make sure you are able to pass all the necessary data to a completely different application.
Have a look at this earlier question to see how this can be achieved.
APIs
Another solution would be to use APIs. Just like intents, this requires the third-party developer to have exposed their application to these specific API calls, which you can then connect to to pass your data. The simplest real-world implementation of this approach would be signing on to an application using a social media account instead of having to create a separate account per application.
This is less streamlined than the intents approach as it would involve additional steps of posting your data to the API and then opening the other app in order to retrieve the data and proceed.
I'm trying to understand how applications are storing data without the use of a login system. Example, an android app starts you with 500 coins and you use some of them. You have not logged in at all and you delete the 'app data' in settings and uninstall and reinstall. The app still knows you only have 450 coins left for example. The app requires internet connection so I'm assuming they are storing the info on their server. If so, how are they uniquely identifying your device? In my reading so far it seems there is no full-proof way to uniquely identify a device every time.
I'm asking because I'm going to be working on an app where I don't want to require a login but I also don't want the player to simply reinstall and get to start over. So, my question is how does everyone handle this situation to work for both iOS and android?
Google offers Firebase, which is used for notifications, but makes use of a unique identifier for an application instance on a device (both on iOS and Android), they could be using this.
There are some more providers that offer a similar service (for example OneSignal).
Reference: https://firebase.google.com/
I'm developing an Android game, and now I'm in the stage where I want to create a multiplayer option.
My task it to pass between two users on different phones an integer.
My thought is to do it via facebook, to enjoy all the social benefits of it.
Do you know what API's\technologies I need to use?
I installed the facebook SDK, but cant find the specific API's to do it.
Thanks Allot, Vlady.
If the two users play against each other (or with each other) then the best approach would be a P2P connection, that it the two devices should have a socket between them for passing messages.
If that's not possible for some reason, then the fallback would be to have a central server to which all clients are connected, this server will then route the message from user A to user B.
As for the facebook option, what's the point?
It's not what their api is for.
You can use the Achievements to publish user scores and such, gain more engagement and virality, but that's not for the communication between the clients.
I am writing a basic app that interacts with a webservice I'm writing using AppEngine. I was wondering what the repercussions are of using login based authentication and managing users individually on the server side.
I know the business benefits of knowing your users and since I plan to eventually have some user generated content in the service, I realize I will eventually have to add it.
Right now, I'm concerned more about the technical aspects of adding this feature. What are the development and maintenance costs of adding these services right now versus adding them at a later point in time i.e. when the datastore is already populated with some 'anonymous' data and not user histories are kept ?
I know this is a vague question so I'll try to quantize the situation. Let's say we have an app that allows users to search the surrounding area for restaurants. The app only needs to send to the service the type of restaurant, say 'Chinese' ? The app is popular and gets a 100k users. Now we want to add a favorites system. Would we have been better off adding it from the start or is it better to wait to get some user and then add features ?
An underlying concept here is also the value that users attribute to a personalized experience and it would be great to get some insights from experienced App developers.
It seems feasible to build your system from the ground up using an internal unique identifier to segment user data. To start, just use the device's unique identifier to authenticate, then add a login-based scheme later.
I recently rolled my own api-based authentication system using GAE, and one of my biggest regrets has been not biting the bullet and doing it sooner. That said, if the context warrants (ie you want to test out a concept and see how well it resonates), I'd say you are safe going with an extendable approach, like the one I've described.