Develop Reference

Can I use two different data storage in one project?

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

Getting data once and use it in all activities

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.

Android MVP Architecture - SharedPreference is consider as Model?

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!

Should I use Android SharedPreferences or SQLite for persistence in my app?

When a user logs in to an app I'm developing, the back-end sends back information about the user. I want to persist the information so it can be used in other activities and when there is no network access.
The two main persistence options I'm aware of for Android are SharedPrefereces and SQLite, and I'm trying to determine which would be more appropriate for my use case. There are three requirements:
The data to store are mostly a small number of primitive data types or simple reference types, but an array or an object of a derived type may also need to be stored.
Reading and writing the data should be as simple as possible.
Data that is written must be available on any subsequent read.
Here is my attempt to compare SharedPreferences and SQLite along these dimensions. (Note that there are other questions on StackOverflow that ask for comparisons of SharedPreferences and SQLite -- "Pros and Cons of SQLite and Shared Preferences", "Saving data on Android : File Storage vs SQLite Database vs Shared Preferences" -- but the answers do not address all three dimensions.)
SharedPreferences
Works most naturally with primitive and simple reference types, but GSON can be used to store data of any type.
Data can be written and read from the UI thread.
Due to a race condition, there is no guarantee that data written to SharedPreferences will be available on any subsequent read.
SQLite
Can be used in a natural way to store structured data of any degree of complexity.
Data should be written and read in a thread separate from the UI thread.
Using a singleton DatabaseHelper guarantees that data written to the database will be available on any subsequent read.
If my assessment is correct, it looks like the SharedPreferences race condition means I have to use SQLite instead to satisfy the requirements even though doing so is more involved. But is my assessment correct?

You said :
a small number of primitive data types or simple reference types
Then definitely SharedPreferences is preferred. If you can image to have a lot of similar rows of data which are all unique rows then use SQLite. You have three requirements and none of them need to store big amount of similar, nevertheless unique, data.
On the other hand:
an array or an object of a derived type may also need to be stored.
i would suggest to store these data in private text files and with every app launch try to decode the data (if it exists).

How to write to and read data from Android's ApplicationContext?

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.