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!
Related
I’m new to Android development and I’m about to implement simple Preferences for my app. It appears SharedPreferences is a dead end and has lots of warts, so I’m looking at DataStore (non-Proto) vs Room. Since I ALREADY heavily use Room and LiveData (yes, I know Flow is the new hotness) in my app for other things, is there any benefit to using DataStore too? I understand Room is recommended for large or complex data as I’ve already reviewed the following, but I’m hoping a more seasoned developer can further hit this home for me:
https://android-developers.googleblog.com/2020/09/prefer-storing-data-with-jetpack.html
https://proandroiddev.com/lets-explore-jetpack-datastore-in-android-621f3564b57
https://medium.com/better-programming/jetpack-datastore-improved-data-storage-system-adec129b6e48
Thank you.
The official blog post you linked has a section specifically about Room vs DataStore:
If you have a need for partial updates, referential integrity, or support for large/complex datasets, you should consider using Room instead of DataStore. DataStore is ideal for small , simple datasets and does not support partial updates or referential integrity.
User preferences almost always fall into the 'small, simple datasets' that can be easily expressed as key/value pairs (or something more complicated if you want to use the Proto DataStore) that do not need the overhead of a table schema, SQL queries, custom parsing, or the 'relational' part of a relational database.
The problem with datastore is you cannot just fetch or update a part of data from a list like you can with SQLite libraries such as Room. This is true for both Proto and Preferences version. So if you have 10 thousand elements and you save them to DataStore and then you want to update 2 of them based on a condition you'll have to fetch the entire list, manipulate it and put it back. Here Room (or any DB solution) will be a way to go
But if you just want to save user preferences or small data it would be an overkill to use a DataBase - here DataBase Proto will actually be the perfect choice
I am currently trying to wrap my head around the architecture components of the android platform, according to the official guide:
In my app I currently need to store a list of strings (names) and access it in multiple places (activities as well as services). 2 possible approaches come to my mind:
1) store them comma-separated in the shared preferences.
2) create an entity and room-table with the name as only column.
I would prefer the first approach since I only need the names as one single string to perform a contains()-operation. using a room database seems to be more of a hassle for this purpose.
My concrete Question is: is it okay to store the appcontext in the repository-class (which is a singleton) or am I breaking any conventions/architectural rules? Or would it be better to actually use room for this?
If you want to use the component architecture, and your repository needs to communicate with data sources that need a context, like room or SharedPreferences .. you'll need to extend your ViewModel from AndroidViewModel that will provide you a context that you can pass to your repository to use it to access the Room database or the SharedPreferences. there is no problem using a context in the repository, even if it is singleton, you already need it to access Room.
I have a question about getting data from server.
I get general data in mainActivity of my app and I want to use it across all activities. I was thinking about using database to get my data once, save it in database and get it where I want from database. But now I'm thinking about using a Singleton class that I can use it to save data once amd get that data in every activity. Is it possible and is it a good idea?
Update :
Data Type is list of objects, So SharedPrefrences is not a good choice
and I want to save them temporally until application is running.
You can save the data in any of the following sources
Shared Preferences
SqlLite Database
Android Room or any other ORM
Files (specially for images)
Based on your data type, you can decide one among these
Have you seen the Android Event Bus? It makes communications between activities fun! Your main activity "posts" the data object once it is available. Other activities "subscribe" to receive the posted data.
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.
I'm implementing a home screen app widget. I was wondering which is better to store/read data: SharedPreferences or a SQLite database? The data is accessed from an AppWidgetProvider (similar to a BroadcastReceiver), and any given instance of the widget displays different data based on appWidgetId. Is one way or the other frowned upon?
It really depends on your use case. Preferences are meant to be a simple, lightweight mechanism to store key-value type of data while an SQLite database provides you with a whole framework for storing and retrieving relational data (queries, transactions, etc.).
This article gives an overview of both and also covers custom files and network as alternative ways to persist data.