I have a database from where i need to extract quite a lot of data.
Now i get that data when required, i.e. I have made a class that handles database interactions and whenever an activity requires data it will call that class for the data. So at a time an Activity only has the bare minimum amount of data in memory (i.e. the data that it is using). But everytime i change an activity i have to perform database access to fetch data for the new activity.
Method 2
As opposed to this i have this other alternative, in which i make an application object and then perform database access in the beginning and then store all the data that i would require (in all the activities) in the application object. Whenever i need the data, i refer to the application object. The downside of this that i will be holding too much extra data that i am not using at a given instant.
Which of the above 2 approaches is better?
Thank you in advance.
It depends on your requirements and their priorities. If the time required for solution 2 is too long for you to accept then optimize (e.g. by using method 2, but in general I would advise against storing potentially all of your database in memory ... assuming the amount of memory will suffice).
Did you try solution 1. If the problem is only to read the data from database, it should not take too long to load the data for one activity. If complex calculations are involved you might be pressed to optimize. But don't optimize just in case!
I prefer the first approach because making a call to database is not costly until and unless it is being accessed by multiple applications.
Related
I see that Firebase website has a lot of documentation to help us optimize the usage of resources, however, I have not found a detailed example of the resources used.
This could be useful to me to understand how to build my applications and to better choose the strategy in terms of performance and cost.
TAKING ANDROID AS EXAMPLE
I understand that when i do a:
query.addListenerForSingleValueEvent(...);
all the reference is "queried" to the database so that is a single query but takes down all the object.
if i do:
query.addValueEventListener(...);
the connection is kept open, but will it keep making connections on time intervals?
Or maybe is considered like a single connection in terms of billing?
And after a change on the database, will it query all the object down again?
In general how much is heavier and expensive to make a single request vs using the realtime-db feature of listening to a reference?
Maybe there is a section in the docs that explain this but I didn't found it.
query.addListenerForSingleValueEvent(...);
all the reference queried" to the database so that is a single
query but takes down all the object.
It will listen once to the objects within inside the child you are querying, not all of the objects inside the database.
query.addValueEventListener(...);
the connection is kept open, but will it keep making connections on
time intervals?
It has no intervals, instead it listens whenever a change is made into your database, lets say you change certain value from your database and that will trigger your addValueEventListener. This will only consume resources when some value changes into your database, so the usage will be a variant with your database usage, instead , addListenerForSingleValue will fire just once to query your data and we can assure that it will consume less network resources than a listener that is always listen to some changes to bring into your app
Check this usefull link : https://www.firebase.com/docs/java-api/javadoc/com/firebase/client/ValueEventListener.html
Currently I'am developing app which having a bad API. I have a situation where I have to use data received from network call in a activity, which is 2 steps away from the activity where I made the network call. In other word all the data necessary fill 3 activities comes on this one network call.
So I pass necessary data between activities using Intent Extra. It is not easy to maintain and It takes noticeable time to switch between activities.
I know one possible solution is to store data in database. and access those data from different activities. It feels like a bad practice because no use of those data after user pass 3rd screen.
Is there any better technique to handle this?
You can put all your network logic in the separate class, cache data in some variable and use it in your activities (you can use singleton class or injecting by dagger).
Also you can read about Clean Architecture and get some good practices from it.
If you don't want use anything from above, you can remove data from database after using and not store it forever. Or you can use SharedPreferences if your data is not complex.
I want to keep some objects in memory for operations in all the activities of my app and I also want to store those objects when the app closes. Which is the most efficient way of doing this ? Some possibilities that I can think of are:
1) Keeping local copies of objects in all the activities, serialize them and pass them through intent.
2) Keep local copies of objects in all the activities, serialize them and do file read and write on activity resume and pause respectively.
3) Make them static variables but I don't know when to do the file read/write operations in that case? This approach may leak memory.
4) Use Application object and define my objects as variables in that object. Since it has a definite life cycle like activity, I can do read/write accordingly.
I recommend your approach number 2. The reason is that there is no such thing as "the app closes". Android tries to keep it in memory until the memory is needed for other purposes. The process of your app is then simply killed, you don't get any callbacks called.
Singletons or the Application object can be used to cache the objects if you are careful to load and store them as necessary. However, this also means, that the memory used for them is only reclaimed if the app process terminates.
It depends on your data. All approaches are good in some cases.
I think you have 2 options:
keep data in sqlite. It is easier then files and faster. When activity starts request required data from db and show it. (use files if you really want)
create a singletone class to store data. Data will be loaded in memory and you can access it very fast. When data changes save it to sqlite or file. google "share data between activities"
Of late I have been into an issue which has been really difficult to sort out.
I have an Activity A which has a view pager with fragments. I am loading data from server and feeding into the views. The data received from server is stored in a singleton class which can be accessed across the application. Now user moves to another activiy B which uses the server data through singleton class.
Now when user presses home and launches variety of application, my app gets killed in background. When I relaunch the application, OS try to load activity B again with its saved state(I am not doing anything in onSaveInstance), but the data in singleton class is already lost and app crashes. The thing is I cannot get the server data again in this activity. Should I save the entire data in onSaveInstance of this activity? Is it not encouraged to use singleton class to store all your data?
What is the ideal way to handle situation like this?Any help is appreciated.
How sensitive is the data? In Android is is not recommended to use a skeleton to move your data around(Passing it through intent? Static(please say no)). Ether way was commented you should probably store the data to main memory. Android provides a few options besides actually writing it to a file. Depending on how much data and its structure there are a few options.
ContentProvider & ContentResolver, Basic Overview. I would not recommend this unless you plan on making the data accessible to other applications.
SQLite. Good if you have preexisting sql knowledge or large amounts of data where a relation db is needed.
SharedPreferences. As its name implies is generally used for storing user presence data, but it can also be used to store any data. I would not recommended it where there is a lot or complex data is needed to be stored.
File. Good old java file classes, no explanation needed.
With our data I would recommend creating a DataStore managing class which handles the io to any of the above methods, so when referencing the data you simply pull from that class.
To avoid such situations, you should relate to these:
App crashes when restoring from background after a long time
http://www.developerphil.com/dont-store-data-in-the-application-object/
I have a small app that records messages and stores them in an object which implements Parcelable. In the app I have a LOT of messages (about 2000) and it takes a considerable amount of time passing between Activities through intent.putParcelableArrayListExtra
Is this not the correct usage of Intents+Parcelable? I've been really wanting to avoid SQLite, but I suppose I'll get my hands dirty if its absolutely necessary.
You should definitely persist your messages in a database. If you want to avoid all the SQLite hassle check db4o, painless object persistence in your apps using an OODB.