I have scenario where there are 4 (or more) applications, the first one which runs on a device (it can be any one of the 4 applications) will generate a Unique ID and store it on some where, and all other applications which runs afterwards requires to read Unique ID that was generated by the first running application.
I want to exclude External Storage option as some user may easily change the stored value.
I also considered Shared Preferences, but it seems using Shared Preferences we can implement multiple applications to read the data generated by a single application, but all applications cannot write this shared data.
You can also have the Sqlite DB option and share a ContentProvider for the other applications to be able to access or modify the data. The advantage is that this data will be stored locally, the disadvantage will be that if you want a security for your data you will have to encrypt your data or choose the Remote Server option.
Related
The android documentation has the following options below but does not explain what circumstances each is best for. What are the pros and cons of each method? e.g. Under what conditions would SQL be better than Shared Preferences?
Shared Preferences
Internal Storage
External Storage
SQLite Databases
Network Connection
Different Storage options in Android
Content Providers
Consider the structured data added to the device from application1 is
not accessible to another application2 present in the same device but
the profile photo added to the device by application1 is available to
the application2 running in the same device
Consider android device as a city, the applications in it are the
houses in the city, people in the houses(application) are the data.
Now content provider is like an broker in the city(android device).
This broker provide access for the people in the city for finding
different houses referring as the content provider in the android
device provide access for the data in the device for different
applications.
Shared Preferences
Consider I have an App say a Face book App which I use to log in to
my account.
Now the very first time I enter my username and password to get
access to my account. Say I log out of the application an hour later
again I use the same Face book App to login again to my application.
I have to enter username and password again to login to my account
and I set a theme to my application and other settings on how my app
looks in my current phone
This is un-necessary because consider I am using my phone to login to
the application. So I will always use my phone to login again and
again, thus entering my credentials again and again is more work
shows it’s not a user friendly app
Shared Preferences is very handy in such scenarios where I can use
its feature to share my data in a xml file Which physically exists in
the Android app installed in my phone which is not destroyed even if
the app is closed. Here we can save user preferences data of the
current application.
As a result next time I open my app in my phone I can see the data
automatically filled in the necessary fields and the settings are
File Storage
In Android we can use the device storage space to store the data in
it for the applications. The type of data involves things such as a
text file, image file, video file, audio file etc.
As seen in the figure as we can see that there are two places we can
do this. One way is to write the raw files into primary /secondary
storage. Another way is to write the cache files into the
primary/secondary storage.
There is also difference between storing raw data and the cache data,
the raw data once stored in memory by user has to be explicitly
deleted by the user explicitly otherwise it would exist till then.
Cache data stored in memory is not a permanent data because the
system automatically deletes it if it feels there is shortage of
memory.
Internal Storage:
Consider a user in an application has stored data in internal
storage, then only that user of that application has access to that
data on the mobile and that data is automatically deleted when the
user uninstalls the application. Speaking of which internal memory is
private.
The apps internal storage directory is stored using the name package
name in a special place in the android file system.
Other apps or users of current app have no access to the file set by
a particular user and a particular app unless it is explicitly made
available to the user for readable/writable access.
SQLite
Sqlite is used to store more structured data locally in a mobile
where the android app is running. Structured data involves as of
which shown in the figure like a student’s information in the form of
rows and columns.
Sqlite offers similar functionality like Mysql and oracle but with
limited functional features. Some of the things involve performing
query operations on tables. There are features though like creating
views but also some features are not available like stored procedure.
Sqlite is very helpful in storing complex and large data which can be
downloaded once and can be used again and again until the application
is running. When the application is closed the sqlite database is
also destroyed.
Putting all the pieces together
Shared preferences are good for storing ... an application's preferences, and other small bits of data. It's a just really simple persistent string key store for a few data types: boolean, float, int, long and string. So for instance if my app had a login, I might consider storing the session key as string within SharedPreferences.
Internal storage is good for storing application data that the user doesn't need access to, because the user cannot easily access internal storage. Possibly good for caching, logs, other things. Anything that only the app intends to Create Read Update or Delete.
External storage. Great for the opposite of what I just said. The dropbox app probably uses external storage to store the user's dropbox folder, so that the user has easy access to these files outside the dropbox application, for instance, using the file manager.
SQLite databases are great whenever you are going to use a lot of structured data and a relatively rigid schema for managing it. Put in layman's terms, SQLite is like MySQL or PostgreSQL except instead of the database acting as a server daemon which then takes queries from the CGI scripts like php, it is simply stored in a .db file, and accessed and queried through a simple library within the application. While SQLite cannot scale nearly as big as the dedicated databases, it is very quick and convenient for smaller applications, like Android apps. I would use an SQLite db if I were making an app for aggregating and downloading recipes, since that kind of data is relatively structured and a database would allow for it to scale well. Databases are nice because writing all of your data to a file, then parsing it back in your own proprietary format it no fun. Then again, storing data in XML or JSON wouldn't be so bad.
Network connection refers to storing data on the cloud. HTTP or FTP file and content transfers through the java.net.* packages makes this happen.
SharedPreferences is mainly for application-specific settings that you can access via your Settings menu - like application settings. It's a good idea to keep everything simple here - mostly boolean flags, short strings, or integers. SharedPreferences data persist on device reboot, and are removed along with app uninstallation. Data is saved as a key-value pair.
Internal Storage is mostly used for larger non-persistent data storage. You utilize internal storage if you want to process an image, a short video clip, a large text file, etc. But you don't store the processed data in the internal storage - its function is more like a CPU's RAM. The amount of available internal storage for your application depends on the device, but it's always a good idea to keep anything under 1MB. Data is referenced via its file path.
External Storage does not only refer to the SDCard storage, but for higher-end phones, this can mean internal mountable storage (like in the Galaxy Nexus or S2). This is where you store the large video files, the high-resolution images, and the 20-megabyte text file you want to parse in your application. This is also a place to store data that you want shared across devices if you swap sd cards. Data is also referenced via its file path.
SQLite Databases is where you'd store pretty much anything you want in a regular database - with the advantage of organizing things into tables, rows, and columns. It works best with things that you want displayed in the UI as lists - the best example would be the great invention knows as the CursorAdapter. Data stored here also persist on device reboot, and are removed with app uninstallation. You can also share data across applications with sqlite db if you hook it up to a ContentProvider. Data is accessed using a Cursor, where you can call methods as if you're executing sql statements.
Network Connection is not really a data storage technique, but can be a way of persisting data for a specific user provided the device is connected to the internet, using some sort of authentication. You have to balance out between downloading data every time the app needs it, or having a one-time data sync, which would ultimately lead to another of the storage options mentioned above.
Shared preferences are key/value pairs, nothing more. So if you want to keep track of say, students and their test score, it really won't work well for that.
A database is just that, a database. You can define as many columns (and tables) as you need to get the job done.
If it's preferences for your app, use shared preferences (almost any preference I can think of can be done that way), if it's anything else more complicated, use a database.
I want to use sharedpreferences in my login form, but i also want keep XAMPP as my main storage. What is the best data storage when I want to do my app in offline mode?
Yes, you're allowed to mix and match any type of data storage you wish because none of them were designed to be in conflict with each other.
However, it's a good idea to understand what type of data storages is available for you to use, because different types of storages has different benefits and drawbacks.
SharedPreferences is a great way to store a user's preferences, or simple data with a single value. It's great for storing a user's preferences because when creating Settings, it's extremely common to use Preferences which directly reflects the values within your SharedPreferences. However, due to it's design, SharedPreferences isn't a good idea to store large amounts of data or dynamically created data.
For that, it's better to use a database and you're free to use any type of database you wish. But for offline mode, it's best to use the SQLite Database that's offered by Android by default.
However, if you do want to use XAMPP, it's not uncommon to see developers who store their full data in an online database, but cache a few data within a local database like SQlite.
Therefore, there's zero conflicts among data storage options, so mix and match to what benefits your app's design best.
If you want to store data in locally then you can use SQLite Database and yeah XAMPP is whole different thing to store data for this you need to create APIs to communicate with database.
You can also use Sharedpreferences for storing the data but Sharedpreferences will store data with the key-value pair only.
But you can use both for different different purposes for the same app
The android documentation has the following options below but does not explain what circumstances each is best for. What are the pros and cons of each method? e.g. Under what conditions would SQL be better than Shared Preferences?
Shared Preferences
Internal Storage
External Storage
SQLite Databases
Network Connection
Different Storage options in Android
Content Providers
Consider the structured data added to the device from application1 is
not accessible to another application2 present in the same device but
the profile photo added to the device by application1 is available to
the application2 running in the same device
Consider android device as a city, the applications in it are the
houses in the city, people in the houses(application) are the data.
Now content provider is like an broker in the city(android device).
This broker provide access for the people in the city for finding
different houses referring as the content provider in the android
device provide access for the data in the device for different
applications.
Shared Preferences
Consider I have an App say a Face book App which I use to log in to
my account.
Now the very first time I enter my username and password to get
access to my account. Say I log out of the application an hour later
again I use the same Face book App to login again to my application.
I have to enter username and password again to login to my account
and I set a theme to my application and other settings on how my app
looks in my current phone
This is un-necessary because consider I am using my phone to login to
the application. So I will always use my phone to login again and
again, thus entering my credentials again and again is more work
shows it’s not a user friendly app
Shared Preferences is very handy in such scenarios where I can use
its feature to share my data in a xml file Which physically exists in
the Android app installed in my phone which is not destroyed even if
the app is closed. Here we can save user preferences data of the
current application.
As a result next time I open my app in my phone I can see the data
automatically filled in the necessary fields and the settings are
File Storage
In Android we can use the device storage space to store the data in
it for the applications. The type of data involves things such as a
text file, image file, video file, audio file etc.
As seen in the figure as we can see that there are two places we can
do this. One way is to write the raw files into primary /secondary
storage. Another way is to write the cache files into the
primary/secondary storage.
There is also difference between storing raw data and the cache data,
the raw data once stored in memory by user has to be explicitly
deleted by the user explicitly otherwise it would exist till then.
Cache data stored in memory is not a permanent data because the
system automatically deletes it if it feels there is shortage of
memory.
Internal Storage:
Consider a user in an application has stored data in internal
storage, then only that user of that application has access to that
data on the mobile and that data is automatically deleted when the
user uninstalls the application. Speaking of which internal memory is
private.
The apps internal storage directory is stored using the name package
name in a special place in the android file system.
Other apps or users of current app have no access to the file set by
a particular user and a particular app unless it is explicitly made
available to the user for readable/writable access.
SQLite
Sqlite is used to store more structured data locally in a mobile
where the android app is running. Structured data involves as of
which shown in the figure like a student’s information in the form of
rows and columns.
Sqlite offers similar functionality like Mysql and oracle but with
limited functional features. Some of the things involve performing
query operations on tables. There are features though like creating
views but also some features are not available like stored procedure.
Sqlite is very helpful in storing complex and large data which can be
downloaded once and can be used again and again until the application
is running. When the application is closed the sqlite database is
also destroyed.
Putting all the pieces together
Shared preferences are good for storing ... an application's preferences, and other small bits of data. It's a just really simple persistent string key store for a few data types: boolean, float, int, long and string. So for instance if my app had a login, I might consider storing the session key as string within SharedPreferences.
Internal storage is good for storing application data that the user doesn't need access to, because the user cannot easily access internal storage. Possibly good for caching, logs, other things. Anything that only the app intends to Create Read Update or Delete.
External storage. Great for the opposite of what I just said. The dropbox app probably uses external storage to store the user's dropbox folder, so that the user has easy access to these files outside the dropbox application, for instance, using the file manager.
SQLite databases are great whenever you are going to use a lot of structured data and a relatively rigid schema for managing it. Put in layman's terms, SQLite is like MySQL or PostgreSQL except instead of the database acting as a server daemon which then takes queries from the CGI scripts like php, it is simply stored in a .db file, and accessed and queried through a simple library within the application. While SQLite cannot scale nearly as big as the dedicated databases, it is very quick and convenient for smaller applications, like Android apps. I would use an SQLite db if I were making an app for aggregating and downloading recipes, since that kind of data is relatively structured and a database would allow for it to scale well. Databases are nice because writing all of your data to a file, then parsing it back in your own proprietary format it no fun. Then again, storing data in XML or JSON wouldn't be so bad.
Network connection refers to storing data on the cloud. HTTP or FTP file and content transfers through the java.net.* packages makes this happen.
SharedPreferences is mainly for application-specific settings that you can access via your Settings menu - like application settings. It's a good idea to keep everything simple here - mostly boolean flags, short strings, or integers. SharedPreferences data persist on device reboot, and are removed along with app uninstallation. Data is saved as a key-value pair.
Internal Storage is mostly used for larger non-persistent data storage. You utilize internal storage if you want to process an image, a short video clip, a large text file, etc. But you don't store the processed data in the internal storage - its function is more like a CPU's RAM. The amount of available internal storage for your application depends on the device, but it's always a good idea to keep anything under 1MB. Data is referenced via its file path.
External Storage does not only refer to the SDCard storage, but for higher-end phones, this can mean internal mountable storage (like in the Galaxy Nexus or S2). This is where you store the large video files, the high-resolution images, and the 20-megabyte text file you want to parse in your application. This is also a place to store data that you want shared across devices if you swap sd cards. Data is also referenced via its file path.
SQLite Databases is where you'd store pretty much anything you want in a regular database - with the advantage of organizing things into tables, rows, and columns. It works best with things that you want displayed in the UI as lists - the best example would be the great invention knows as the CursorAdapter. Data stored here also persist on device reboot, and are removed with app uninstallation. You can also share data across applications with sqlite db if you hook it up to a ContentProvider. Data is accessed using a Cursor, where you can call methods as if you're executing sql statements.
Network Connection is not really a data storage technique, but can be a way of persisting data for a specific user provided the device is connected to the internet, using some sort of authentication. You have to balance out between downloading data every time the app needs it, or having a one-time data sync, which would ultimately lead to another of the storage options mentioned above.
Shared preferences are key/value pairs, nothing more. So if you want to keep track of say, students and their test score, it really won't work well for that.
A database is just that, a database. You can define as many columns (and tables) as you need to get the job done.
If it's preferences for your app, use shared preferences (almost any preference I can think of can be done that way), if it's anything else more complicated, use a database.
I am building a React Native application and I need to save some sensitive data like a token and a refresh token. The obvious solution is to save that information using AsyncStorage. The problem is the security level of the AsyncStorage.
AsyncStorage provides a way to locally store tokens and data. It can
be, in some ways, compared to a LocalStorage option. In full
production applications, it is recommended to not access AsyncStorage
directly, but instead, to use an abstraction layer, as AsyncStorage is
shared with other apps using the same browser, and thus an
ill-conceieved removal of all items from storage could impair the
functioning of neighboring apps.
https://auth0.com/blog/adding-authentication-to-react-native-using-jwt/
In a native app, I would go for Keychain in iOS and Shared Preferences in private mode in Android.
For what I read in the documentation provided by React Native:
On iOS, AsyncStorage is backed by native code that stores small values
in a serialized dictionary and larger values in separate files. On
Android, AsyncStorage will use either RocksDB or SQLite based on what
is available.
https://facebook.github.io/react-native/docs/asyncstorage.html
They never talk about the security of that data.
It is the best solution create a module for Android (that uses Shared Preferences in private mode) and another for iOS (that uses Keychain) to save the sensible data? Or it is safe to use the AsyncStorage methods provided?
Just digging into the React Native code, I found the answer.
Android
The React Native AsyncStoragemodule implementation is based on SQLiteOpenHelper.
The package where all the data classes are handled: https://github.com/facebook/react-native/tree/master/ReactAndroid/src/main/java/com/facebook/react/modules/storage
The class with the instructions to create the database: https://github.com/facebook/react-native/blob/master/ReactAndroid/src/main/java/com/facebook/react/modules/storage/ReactDatabaseSupplier.java
By the Android documentation, the databases created by the application are saved in private disk space that's associated application, so it is secure.
Just like files that you save on the device's internal storage,
Android stores your database in private disk space that's associated
application. Your data is secure, because by default this area is not
accessible to other applications.
Source
iOS
In iOS the AsyncStorage values are saved in serialized dictionary files. Those files are saved in the application NSDocumentDirectory. In iOS all applications live in their own sandbox, so all files of one application are secured, they cannot be accessed by the other applications.
The code in iOS that handles the AsyncStorage module can be found here: https://github.com/facebook/react-native/blob/master/React/Modules/RCTAsyncLocalStorage.m
And as we can see here the files used to store the values saved by the AsyncStorage are saved under the NSDocumentDirectory (inside the application sandbox environment).
Every App Is an Island An iOS app’s interactions with the file system
are limited mostly to the directories inside the app’s sandbox. During
installation of a new app, the installer creates a number of
containers for the app. Each container has a specific role. The bundle
container holds the app’s bundle, whereas the data container holds
data for both the application and the user. The data container is
further divided into a number of directories that the app can use to
sort and organize its data. The app may also request access to
additional containers—for example, the iCloud container—at runtime.
Source
Conclusion
It is safe to use AsyncStorage to save user tokens, since they are saved under a secure context.
Please note that this is only true for Android devices without root and for iOS devices without jailbreak. Please also note that if the attacker has physical access to the device and the device is not protected. He can connect the device to the mac laptop and extract the documents directory and see all the contents saved under the documents directory.
AsyncStorage saves key-value pairs as a plaintext JSON file in the Documents directory. It does not encrypt its contents.
This is a security issue (at least on iOS) because it's possible for an attacker with access to the device to obtain a dump of the contents of the sandbox and trivially extract any data saved through AsyncStorage.
This used to not be clearly stated in the docs for AsyncStorage.js, but it is now:
https://github.com/facebook/react-native/pull/8809
Also see: https://stackoverflow.com/a/38398114/1072846
If someone wants the additional step of having the data encrypted, you might want to look at this: https://github.com/oblador/react-native-keychain
It uses facebook conceal internally.
I really recommand you to use a library like react-native-keychain to store private data in react-native
For Android API level:
16-22 use Facebook Conceal
23+ use Android Keystore
You can use it like that:
// Generic Password, service argument optional
Keychain
.setGenericPassword(username, password)
.then(function() {
console.log('Credentials saved successfully!');
});
// service argument optional
Keychain
.getGenericPassword()
.then(function(credentials) {
console.log('Credentials successfully loaded for user ' + credentials.username);
}).catch(function(error) {
console.log('Keychain couldn\'t be accessed! Maybe no value set?', error);
});
I'm developing a group of complex Android applications that need to share common state and configuration settings.
For example, see this picture explaining my scenario:
I want that APP 1, APP 2 and APP 3 be able to access (read/write) data to the common storage area. Additionally, I need uninstall protection i.e. I don't want the data to be removed when the user uninstalls any of the apps.
I've already read about SQLite databases, ContentProviders and writing on Internal and External storage, but each of the above mentioned methods have disadvantages as listed below:
SQLite database: DB is deleted on app uninstall and is private to each app
ContentProvider: The data is removed when the app with the ContentProvider is removed
Internal storage: Is private to each app and data is deleted on app uninstall (http://developer.android.com/training/basics/data-storage/files.html#InternalVsExternalStorage)
External storage: Is unreliable (user may remove SD card)
Store on server: Not possible, user may not have reliable internet connection
EDIT:
I don't want any dependencies on Google Play Services because I will be distributing the apps via Play Store and as 3rd party downloads.
Please help me out.
Google Drive sort of does this for you. You basically get granted permission to a local filesystem that is backed by a remote one. On most phones this is getting preinstalled so the uninstall issue you are worried about is less of an issue.
You could create a folder for your apps that you can then read/write.
https://developers.google.com/drive/android/
You can use the shared preferences object to read and write preferences data from a file. Most important is to use MODE_MULTI_PROCESS. The bit MODE_MULTI_PROCESS is used if multiple processes are mutating the same SharedPreferences file.
Use the following code:
SharedPreferences shPrefernces = context.getSharedPreferences("filename", MODE_MULTI_PROCESS);
String s1 = shPrefernces.getString("keytosearch1", "");
String pass = shPrefernces.getString("keytosearch2", "");
I agree that Shared Preferences with world_readable will not sufficient for you or sharing across internet is not possible, but still you can do one thing.
Using Broadcast receivers and Custom Broadcasts.
with redundant common data across all apps with shared preferences.
Who updates the data will send a broadcast to system.
All the apps implement broadcast receiver. when ever a new broadcast received they update the data in shared preferences.
App A -> sends broadcast when data is updated.
If App B is installed already App B also receives broadcast and save the data from that intent.
if App B updates new data.
APP B -> sends broadcast for the common data
Other Apps will update data.
Only common data will be lost when all apps are removed. If at least one app is installed data persists.
Preference data will always be stored inside each applications own context. Use sharedUserId and have a new preference file created in all the apps. On opening each app, the app has to check for the preference value from all other applications context and should write into its preference based on last updated time value available in the preference to find the latest updated one.
Whenever any app is opened, the latest data will be stored in its local. if any of the app is installed or uninstalled, this should work fine.