In my app I need a central storage object that will be accessed from different parts of the application (like a singleton data holder).
AFAIK the clean way to implement singletons in Android is to use the ApplicationContext.
How can I
put data (like instance of List<MyPieceOfInformation>) in the ApplicationContext and
get them out of it
?
Is it correct that the only way to store more or less complex data in Android is to use the built-in SQLite database?
you can use mysql and others as well.
it is all depends if you want to save the data in local or external.
as external, for example, you can use mysql and web server, then communicate using json.
for saving List, you can use static.
In my app I need a central storage object that will be accessed from different parts of the application (like a singleton data holder).
Then use a singleton.
AFAIK the clean way to implement singletons in Android is to use the ApplicationContext.
First, there is nothing in Android named ApplicationContext. You probably mean Application.
Second, in the opinion of many experts (myself included), a custom Application is less "clean" than regular singletons.
Is it correct that the only way to store more or less complex data in Android is to use the built-in SQLite database?
Comparing a singleton to a database is like comparing an apple and an asteroid, on the grounds that both are made of matter and, in English, begin with the letter "a".
A database is persistent. You use a database when you want to save data persistently.
A singleton is not persistent. You use a singleton for transient data, such as a cache of data that is backed by a database.
Related
I been look into a lot of resource about Android MVP. From what I understand Model is the data access layer that solely deal with any work that relate to access data from the storage (database) of the system internally or externally. For example, external database like Firebase, internal database like Realm, etc.
My uncertainty
I am unsure about the 'SharedPreference' in Android, as it acts like a 'Permanent Session' which store the data within the application,
Does it mean that any data retrieval of SharedPreference Should be done in the Model Layer? or it is okay for me to simply retrieve SharedPreference data in View Layer to being displayed on screen?
Does it mean that any data retrieval of SharedPreference Should be
done in the Model Layer?
Yes
I am working with MVP for about 2 years and here is our team approach: Create a SharedPreferencesManager (Model) class to manage everything that belongs to SharedPreferences because SharedPreferences is a "lite" database (key-value)
It is just an opinion. Hope this help!
Is there a better architecture that we can follow other that making these fields static(bad for performance) or storing in Shared Preference.
Either use Shared prefs or a database. Both are optimized for quick and (more or less) safe access. It might be worth your while to read about Architecture Components, Room (or others such as ObjectBox, Realm, etc) and repository pattern.
Android Jetpack would be your best option. Check out the documentation on Data Binding, it would allow you to access fields like user_id without writing tons of boilerplate java/kotlin code, by injecting the data directly into you xml code. Here's the link: Android Jetpack Data Binding
There is nothing wrong in saving two/three Strings as static variables, In fact it is the fastest way to get repeatedly used variables. I prefer Application class to do so(static variables of Application class), but the issue is if your app happens to crash for some reason, application class is recreated and app starts from the previous activity, alas your static variables are long gone, be aware of this pitfall
Depends on how/when you are using these static elements.
A few application global variables like userSession object might make sense to store in the MyApplication file itself and made exposed throughout the app so you confirm it is valid when app returns from background each time for example.
SharedPreference is not a great place to store secure elements as it is on file storage in unencrypted xml format which rooted phones and others may have access to get to.
Database is a fine option, but it requires more code bloat and requires a database connection and query everytime you want to use the token if you don't plan to store it in RAM.
Another option is a singleton class that is meant to store your necessary application elements like FirebaseHelper for example that could populate into RAM on app startup and utilize your variables throughout the application life.
So really depends on your app needs. You can also use a SecureSharedPreference tool. There are a few open source options out there for this that you can just include in your project that encrypt the xml elements for you if you prefer to use the xml for storing these items.
If it was me, I would either you a secureSharedPref if it was simple things like userId, Token, or things like that that are fairly harmless. Of course it will encrypt them, but worst case if they got your token, they could make a few API calls if they knew what they were doing, unlikely. Now storing things like password, bank info, medical records, or anything else sensitive definitely should be in a Database. In fact, I would go one step further and layer it with SQLCipher.
So long story short is it depends on what you are storing and the risk assessment of it's content being accessed and each app will be different.
Absolutely nothing wrong with storing some static variables or singletons. Anyone building an enterprise level application will have a fair amount of statics in their application if it is architected in a good way.
My app will pull some json data when it is started and realistically, once the data has been pulled, I really won't need to pull it again for the duration of the user experience. The backend data may update a few times a day at most, so I think I would like to just grab the data upon app start and then use that same data for the duration and give the user an option to manually refresh the data. So, my question is, where/how should I store that data? I've got all of my data structures set up (classes and sub-classes). And there may be 200 or so instances of some of the classes. If I store everything as member variables in my activity_main class, it won't be available to other activities once the other activities are started. Storing them all in databases could be an option, but it sort of feels like overkill. I really don't need the data to persist between sessions. Is there a way to easily store it in memory and still have it easily accessible to all activities?
You should think about OS killing your app process on low-memory, so backing your data on disk is a good thing to do. Doing so you have an ability to show user data from disk cache while refreshing it in background from server.
Choosing the tool for data storage depends on the way you need to work with data.
Of course, there is an option to use Realm, but you should consider the fact that it is not the relational database. So if you have complex domain model with joins and other relational stuff for your business logic, I'd go with something other. It is thread-safe, also has migrations (but, as for me, migrarations are always pain, you just can not do anythig about it). Realm is supposed to be RxJava-friendly now (support added in v0.87) There are some disadvantages(part of them may already be fixed), but you should consider it before using.
As for more relational approach, there is SQLBrite library:
A lightweight wrapper around SQLiteOpenHelper which introduces reactive stream semantics to SQL operations.
It is not an ORM (but you can add some kind of it on top of SQLBrite if you wish: see this for more info). In fact, being alone this library is doing one thing (and doing it good) - it provides a mechanism for coordinating and composing the notification of updates to tables(Realm also has such ability) such that you can update queries(in SQL fashion) as soon as data changes. And it respects RxJava!
As an alternative to SQLBrite you can look at StorIO.
There are also lots of different ORM solutions, like GreenDAO, ORMLite etc.
But I'm pretty sure, one of the first two libraries (Realm or SQLBrite) will likely help you. So analyze your app, these libs and decide what fits better.
P.S. Great article on how RxJava would help you to work with data from different data sources (in-memory cache + disk cache + network) easily. Might be helpful!
I would still recommend a SQLite Databse, you can easily declare it as a 'in-memory' database, if that is what you want.
However.... I would be rather upset as a user of your application if it downloaded redundant data over and over. I would just recommend making a content provider and being done with it. This gives you access to a SyncAdapter, and defines clear boundaries between where code should go.
The 'trick' with making a good ContentProvider is to make good POJOs, that have methods to convert from POJO -> ContentValues and Cursor -> POJO(s).
Easiest thing is to do is store the json file in Apps data storage and parse the json every time you need.
But this is not recommended as it is costly to parse data every time.
Best option is to implement Realm (Replacement for Sqlite) which is very easy to implement and its amazingly fast.
I'm making a simple GPA android app. The user can input their grades and class names for each semester. How would I then store each of these semesters so that they can always be pulled up in the app? I might also need to store random variables that are alone.
I've briefly looked at options such as Shared Preferences, Internal Storage, and others. What option is the best for my needs? Please explain why. Thanks!
Here is Explanation...
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 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.
Considering this i suggest you to use Sqlite especially in your case.
Best luck
it depends on your need, some times you use all options in the same app,
for example : the best way to store grades and classes is using database, in android SqlLite database.
and for storing some variables values like username and password you just need to use shared preferences.... at least this is my policy in my apps.
SQLite will be the best for your scenario.
As you can create well formatted Tables with desired columns. Either you can use pre-developed database or you can create tables on the go.
In terms of storing data in Android, would it be more efficient to use a large ArrayList or setup an SQLite database? I have ~9000 bus stops and stop names (both in String) that I need to store and I was wondering which method would be the quickest or most efficient.
An ArrayList is probably a very bad idea. I assume you want the data to be persistent, so if your user kills your app your data will be lost if you use an ArrayList. A database is persistent(unless the user clears the cache of the app). So I would highly recommend using a database over an ArrayList.
If your data does not change then you could probably have it read on startup and kept in memory while the App runs. For example, having a .json file with all the stops, read it on startup, put the data in a HashMap or something that is easy to use since you will probably lookup stuff. It would probably work fine with ~9000 entries.
If you are going to add or update information about the stops during usage then the SQLite is the better choice though.
1.) Store and retrieve your data from a SQLite DB since you want persistance. And since you say you have 9k+ rows a simple select will give you everything at once and you can easily filter the data as well if you need to
2.) At startup, put all your data into efficient memory structures like HashMaps(or in your case arraylists) and reference them throughout the app. This way you'll only do one time access.
3.) When in doubt build a DB. No harm, more efficient and easier to handle than files