Android Content Provider system allows other apps to access the data of an app.
Is there any equivalent, or similar approach in WinRT?
I read App contract and extensions and Share contract in MSDN, but it has to execute provider app (an app holds data source) firstly, and then select target app afterward.
In Android Content Provider however, it can query data provider's repository while using target app (data receiver) with no selection of choosing steps. small but big difference in usage.
I'm not sure what kind of data you want your app to share, but it seems to me that what you are looking for might be the file picker contracts. They, I quote:
Make files accessible from a file picker if your app has a unique and/or valuable view of those files or if users cannot easily access the files another way.
Related
My goal is to have a main application and a selection of independent separate data packs, which are available on demand as APK and have their own entry in the Play Store each. It's completely up to the user which, and how many, of these they care to install. Think language packs, keyboard layouts, dictionaries, this sort of thing. The application would always check what data packs are installed and give the user the choice of which one to use.
I thought that the data APKs would not provide any activities but would contain a Service that allows access to a ContentProvider of some sort. But it's all new to me and there's a lot of terminology that confuses me: is this a receiver? A provider? Both of these seem to fit my purpose to some extent. Do I need to have this service (one per data pack) run in the background, waiting for broadcast calls, or can I just somehow inform Android it exists, so it would launch it when this particular query comes from my application?
It would be ideal if nothing would have to be run in the background, possibly even during the listing phase. Then one data file would be chosen and the corresponding APK would only run for as long as the data is being accessed. All the data packs are of the same sort (dictionaries) and need not provide any further functionality than to provide some static metadata and then give access to a raw file.
All of the information I could find relates to "extension APK"s but that's orthogonal to what I want.
I thought that the data APKs would not provide any activities but would contain a Service that allows access to a ContentProvider of some sort.
You do not need a Service to provide access to a ContentProvider.
is this a receiver? A provider?
I do not know what "this" is in that sentence. A ContentProvider uses a <provider> element in the manifest. A Service uses a <service> element in a manifest.
Do I need to have this service (one per data pack) run in the background, waiting for broadcast calls, or can I just somehow inform Android it exists, so it would launch it when this particular query comes from my application?
None of the above. Your main app finds out about the existence of these "data pack" APKs via PackageManager. For example, you might use a standard naming convention for the application ID/package names for those "data pack" APKs, then use getInstalledPackages() to find out which "data pack" APKs are installed.
From there, you could:
Use createPackageContext() to access assets and resources in the "data pack"
Generate a Uri pointing to the "data pack" APK's ContentProvider, then use a ContentResolver to access content published by the APK (e.g., openInputStream(), query())
Use other forms of IPC (broadcasts, started services, bound services) to interact with the "data pack"
All the data packs are of the same sort (dictionaries) and need not provide any further functionality than to provide some static metadata and then give access to a raw file.
I do not know why you would distribute this material in the form of APK files via the Play Store. Just download the material from your own Web server, in some convenient format (e.g., ZIP archive).
Background: we are porting an enterprise system to have android clients. The architecture for windows and html is based around a core library that does the hard business logic but no user interaction at all, and we use programs or single page web apps to provide the user interface and simply call the core API library to actually do stuff.
The "core" is implemented as a shared library on windows and built into each app. If we mirror this and use a java library, we need to share files using external storage, which is a not permitted as data needs to be reasonably secure. (Nb data is binary data, not Sql database, in case that is relevant)
So we thought about using a bound service, and using intents, content provider etc, but it seems (from googling) we must then distribute the background service separately the user interface app, but this seems terrible experience for new users. However, a bound service seems ideal from all other angles.
We also cannot guarantee which apps a user might download, we will have at least 10 individual apps all doing logically different things, but referencing similar data.
In brief:
lots of individual apps all wanting access to same data
no control over which apps are downloaded
using external data is not permitted as data should be semi secure
using sqllite might not work as data is long binary chunks ( eg 3Mb plus ). (Ref: How to share data across a group of applications in Android )
some data files are big and do not want every app to download a private copy
some data changes dynamically, say every 15min
core business logic is big and complex, cannot be distributed in source form, lib/jar ok though.
the windows solutions all use network IO to an application server, but we want to avoid as much network traffic as possible by storing data locally.
How can we bundle a bound service in each and every user interface app we distribute? Or is there a different way to approach this whole design?
I think that there is a few number of options that you can explore:
1) I never have done this before though this seems possible as Android is package based.
First you need to use the same main package across all your apps though each app must be in a separated sub package, e.g. : main -> au.com.myapp.main and the app actually have it's first screen on app1 -> au.com.myapp.main.app1 .
Create on your main app a method(s) that will look for those extra packages (within your project), as it find something you create a trigger that will display a item on the menu. Each app should have the same main packages and main activity, as it will be responsible for enable the user have access to the others and all of them can share the same preferences, files folders and Database.
When installing the same packages should be overrides though those different ones should keep intact. You should have all the 'main' classes for each app, not the real main one declared on your manifest (that will be quite big depending on the amount of activities in all your apps) with those packages.
2) You can using Spongy Castle, create a shared zone (folder) where you create the DB and write your settings or files, encrypting everything with a key (strong one or using RSA) that might be made by the user or provided once for your company at the very first run. You must decide how to handle this.
3) You also can use the share id in all your apps and each app before run perform look up for all packages (it's possible to do) to know and if and what packages exist to check if there is a DB with data in that package.
4) Not really nice though create a background service that keep updated all tables in all apps (sharing id or using content provider), you can user AlarmManager to trigger it in intervals rather keep it on at all times and you have all apps.
My last project had a similar requirement though as the user had to login to do anything, I opted for the option 3 and each data pertinent exclusively to each app went the app DB.
I hope this helps.
Is there anyway I can do something like this
all data I/O functions are written in a library package
data can only be shared between apps with this library (optional)
every apps with this library can initiate the "DB" at first time, and later-installed apps can access the same "DB"
I thought ContentProvider is a perfect solution for me, but it seems that condition 3 is impossible.
any suggestion plz?
all data I/O functions are written in a library package
OK.
data can only be shared between apps with this library (optional)
Perfectly fine with the proper permissions for your provider (signature).
every apps with this library can initiate the "DB" at first time, and later-installed apps can access the same "DB"
I thought ContentProvider is a perfect solution for me, but it seems that condition 3 is impossible.
It's up to you to code the underlying structure of your data. Since you already assumed that the provider will belong in a dedicated library package, a possible solution is:
Implement your provider in package com.mysuite.library.
Publish this app in the Play Store.
Make client apps A, B and C.
Publish them in the Play Store.
Require your users to download this library package whenever apps A, B or C can't find com.mysuite.library installed.
However, if you don't want to provide a central package, I believe you will need to serve a provider in each of your own apps, with different authorities (to avoid CONFLICTING_PROVIDER error). Upon initializing each client, you first check if there is another provider in your namespace (com.mysuite.provider*), assuming you either know all possible authorities you are going to create and/or iterate among them when searching (com.mysuite.provider1, 2 etc.).
However, this proposition may create problems with custom backups (say, if only one of the clients is backed up), which will force the re-creation of data. It certainly has caveats and is definitely more complex (ugly, IMHO), but it can be made to work.
Personally, I'd stick with option 1 (library package). I don't see users complaining when downloading required library packages for apps.
It's just an architectural decision, really.
There are only four ways to maintain shared data:
You have a single APK that stores the data and makes it available to other apps. If this app is uninstalled the data is gone.
Every app maintains its own copy of the data but synchronizes changes to the others.
The data is stored on the SD card. This is generally a poor solution though several apps do it.
The data is stored on a server and is only accessible when the device has a network connection.
Once you've chosen where you want your data to reside, you can transfer it around by any number of mechanisms.
ContentProvider is a good choice if you are not storing the data on SD card or on a server, but you want to be able to transfer the data to apps that don't know it exists using content: URI's.
If you have no need to ever share any of this data with anyone outside your particular suite of apps, and your data is not structured as a database, you may prefer a simpler transport.
I am thinking regarding the future options of my app and I am thinking of the idea of backing-up the data from the application's Database and also sharing that data with another phone, say via e-mail, messaging, Bluetooth, you name it, but basically saving it as a file and opening it from the other phone and having the same values on both phones.
What would be the best approach for such an Android application?
Would Content Providers accomplish exactly this or are they concerned with sharing data only between different Apps? Thanks!
I believe it is possible ,
If you read the documentation about the internal storage here, It mentions
You can save files directly on the device's internal storage. By default, files saved to the internal storage are private to your application and other applications cannot access them
So i believe you can copy the whole sqlite DB file to some temp location then share that file via BT or email or any other sharing option .
But DO NOTE, that the same application package can only access the file if you want perhaps another application to use the db then u need to set the SharedUserId , as mentioned here
Content Providers are generally only for sharing your app's data to other apps.
Content providers are the standard interface that connects data in one process with code running in another process.
I am building an application that needs to keep an list of contacts. That list will be built by inserting data by the user directly or by selecting from Android contacts.
But my list of contacts must not be accessible from outside my application (and will be a password protected application).
I guess I can use a SQLite database and encrypt the data. But is it somehow possible to do it on top of the Android contacts provider?
I am targeting 2.2.
Quoting the first sentence of the Content Providers page of the dev guide:
Content providers store and retrieve data and make it accessible to all applications.
The providers are actually built with accessibility in mind, which is exactly the opposite of what you want. Databases, on the other hand, are accessible exclusively by the owner app. You could, in theory, create a content provider that only provides encrypted data, but I can't see the point in doing that. Your data would be less secure and you would not get any additional advantage over a database.