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?
Related
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.
It seems when you download a new Google Suite app for iOS - whether GMail, Inbox, Calendar or whatever - they offer you to log in with your account and already present to you the account you have logged in elsewhere.
The question is both for iOS and for Android.
I know that apps can use Safari or the new Safari WebView (Chrome Tabs in Android) and a permanent cookie to share data between apps. It's a bit clunky, and can be broken by the user deleting cookies. But other than that, it works.
Google seems to be using something else. AdvertisingID? How exactly do they achieve this feat of sharing data on both operating systems?
AppGroup allows data sharing between two different apps or even app and widgets by creating one common shared path (like document directory). Data saved over there can be accessed by any app which is associated with that particular AppGroup. It is an offline data sharing between apps.
Communicating and persisting data between apps with App Groups
On Android:
They probably use Content Providers. As described in this link,
A content provider manages access to a central repository of data. A
provider is part of an Android application, which often provides its
own UI for working with the data. However, content providers are
primarily intended to be used by other applications, which access the
provider using a provider client object. Together, providers and
provider clients offer a consistent, standard interface to data that
also handles inter-process communication and secure data access.
A content provider coordinates access to the data storage layer in your application for a number of different APIs and components, these include:
Sharing access to your application data with other applications;
Sending data to a widget;
Returning custom search suggestions for your application through the
search framework;
Synchronizing application data with your server;
Loading data in your UI.
TL;DR In short, Content Provider is a layer that allows you to share your database with other apps/widgets. So Google Probably has a Content Provider in every app which shares the accounts that have been used on this app.
On iOS:
Now I'm just an Android Developer, but after a quick Google Search, I found this post which talks about UIPasteBoard:
Use the UIPasteboard class to let a user to share data from one place
to another within your app, and from your app to other apps. For
sharing data with any other app, use the systemwide general
pasteboard; for sharing data with another app from your team—that has
the same team ID as the app to share from—use named pasteboards.
I can't assure you that this is exactly the way Google does it. But If I were to implement such thing across my apps, I would use this.
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 have looked through so many similar stackoverflow posts but none of them seem to solve my specific problem. I want something like the iOS Shared Keychain storage, that any app signed by the same certificate can read and write to. The only answer everywhere is using Content Providers, but unfortunately with Content Providers, it seems that one app needs to be the host, and the other apps are the clients. I seek more of a peer-to-peer style of data sharing, where I have many apps but my users may have perhaps downloaded only a small subset of them (but more than one). There is data that will be shared between those apps, and any of the apps may be uninstalled at any time, and more apps by the same vendor might get installed at any time. In any case, the data should persist as long as there is at least one app by that vendor. When all apps are uninstalled, only then should that data be destroyed. These apps do have a common package name, but a unique application name.
Any suggestions?
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..