CODEWITHSUNDEEP
javaandroiddatabasesqlitestoring-data
mancuss
mancuss

Reputation: 375

Best option for storing data in running application in android [before SQLite]

I'm new to the android development, and programming in general.

I'm developing app to create football statistics for each player, and in the long run I'm using SQLite to store data. However I was wondering if there is a way and if it will make sense, to store data during the run of my application without inserting it to the db, every time user is trying to add new statistics.

Also I'm wondering if there is a point in doing that, my biggest concern is that inserting data to a db all the time will slow down my app, and I would appreciate what more experienced developers do know, and think about this 'issue'

I was trying to research the topic, however all I got was storing data in db, and using SharedPreferences and I don't think that's what I'm looking for, however I can be wrong.

please help.

Upvotes: 0

Views: 209

Answers (4)

zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

Reputation: 5759

If you use implement Loader callbacks it should not slow your application down. Have a look at the Loader classes. They are available through the Android compatibility library.

Upvotes: 0

Barak
Barak

Reputation: 16393

Honestly, I would put it in the DB immediately. With the way android works, if your user navigates to another app (or possibly even receives a phone call) the data they have already entered could be lost.

It is possible to cover that contingency obviously (saving in onPause, etc.), but I've always felt it was safer to get the data into permanent storage as soon as possible. (Note this is a hotly debated topic, I'm merely stating my preference).

Saving to the DB immediately doesn't affect app speed (depending on how much of what type of data you are inserting) so much as battery life. Accessing permanent storage takes more in terms of power as there are several more steps the processor needs to take.

If you do all your DB activities in a thread other than the UI thread the transactions will be almost completely unnoticable in terms of app speed.

Upvotes: 0

SargeATM
SargeATM

Reputation: 2841

I can't speak to android directly but I have faced similar design issues on iPhone and desktop applications.

It depends on the specifics of the application as to what would be the best way. If your app is mostly about entering plays and saving statistics, I would keep a small set of the latest statistics in memory enough to populate the user interface and then create a "data manager" running on a background thread whose sole purpose was to insert these newly added statistics to the database.

Upvotes: 0

barry
barry

Reputation: 4147

SQlite is what you're looking for. SharedPreferences are for just that - preferences, not large amounts of stats.

Put your database code in a separate thread and you won't notice any slow down in your app. Ask back here for help on this.

Upvotes: 1

Related Questions