I'd like some help with data management theory for Android games. I'm developing a role playing game and I'd like the character to be customisable with different outfits: hats, power armour weapons, etc. The player can buy these from a shop and then choose to wear them or change outfit but keep the item in a 'wardrobe ' to wear a different time.
So far, most of my data has been saved via SharedPreferences. However I know this is unsustainable for 100 different types items the player can buy and then save to wear on a different occasion.
Through research, I am beginning to believe SQLite would be best in Android Studio. Would anyone agree with this or have a better suggestion?
I understand SQLite would allow me to have the data pre-loaded with a 'not bought' status. When 'bought' this status would change and the player could 'wear' or 'not wear' the clothing.
If SQLite is best, how do I go about it best? Also, does SQLite take a long time to load and therefore slow the opening of an activity down? Could you combine SQLite with SharedPreferences to remember the latest selected outfit?
Finally, is SQLite what other apps use to store data (especially if built through Android Studio)? How do games such as Clash of Clans or Tapped Out save such data as owned items or location on a grid?
Thank you for even partial support or theory.
TL;DR Yes, SQLite is fine.
Let me answer this question from Clean Code perspective.
Answer below could be too complicated for the beginners, but I hope it will be helpful in the long term.
I think your actual question is - how do I save the stuff which I need later on? Well, in most cases it doesn't really matter how you will store the data as long as you can reliably read it back later on. So, instead of worrying about "should I use X?", I would instead start with defining the interface of the class which will solve your problem.
For instance, let's call it PlayerItemsRepository and it be responsible for saving your stuff and reading it back. How? I don't know yet, we can figure it out later on.
public interface PlayerItemsRepository {
void saveItems(List<Item> items);
List<Item> readItems();
}
OK, now we can integrate SQLite? Let's wait with that for a little - it's a bit of a boilerplate code to work with SQLite, so how about we will create some simple implementation of this interface which would just serialize the list and save it to file (assuming your Item is Serializable). Or if we are too lazy even for that, how about we'll just convert our List<Item> to JSON and save it to SharedPreferences (with something like Gson library which is stupid-simple to use)?
Now, if you're saving just 100 items (which is a rather small amount) I am pretty sure all those "easy" solutions will just work fine and you will be able to just forget about the whole story.
If you will start to run into necessity to have some sort of relational model, or performance of serialization is not acceptable to you, or you need a faster and more complicated search mechanics - then you might consider switching to SQlite. It is pretty common for Android applications, although (as I mentioned before) API is somewhat cumbersome and requires you to write quite some boilerplate - which is in the end require you to spend more time on it and it might be not worth the time for a small data set.
Related
I am building an app as part of a project and I am stuck at the moment.
Background: My team is making a "Time-Wasting" App, and the user can press buttons such as "study" to track their time spent on activities - so there will be lots of integers values in the growing ArrayList.
Task:
Store a growing Arraylist(integers) in the app store and retrieve the values for calculation and graph display purposes.
Problem:
I have looked so far how do to this, but I am a bit stuck. Do I use SharedPreferences, the internal app storage or something else. Also, I have a hard time finding code that I could look at and follow what it is doing.
I need:
An efficient way to store the ArrayList (integers) in a storage place and retrieve it for my app. Any suggestions what would be best and where would I find the code for that?
I looked for about 2 weeks through videos and a through stack overflow but I am still stuck and not closer to how I should store this data type in my app.
Thanks, any help much appreciated :)
My opinion avoid the array list and use a database.
It will allow your app to grow including storing extra information along with the time waster including when they chose to do it, how long , etc.
I recommend Room Database it is an ORM for Sqlite it is super easy to use and there is plenty of documentation on implementation as it's apart of the Android Jet Pack.
If you are really stuck on using a list you can use SharedPreferences it doesn't handle ordered lists but you can store your list as a json string.
I am currently learning android programming and creating an app that will store some integers representing user choices (values inserted several times a day, must be displayed in the results activity) and steps data collected Google Fit HISTORY Android APIs, also displayed in the results activity. I am looking for the most efficient way to store this data. I know that it might be possible to insert the custom data types in the GOOGLE fit database. However, I am not sure if it is a good idea if the app mostly works offline, and it needs to immediately represent only a small set of results, for example, the values inserted in the last 2 weeks, with step counts. On the other hand, I am not sure if it is ok to have two databases storing the data.
My apologies if the question sounds a bit too amateur, I am doing my best to find an optimal solution in terms of performance.
Thank you for your answers.
So, to give you my opinion and answer (mainly opinion)
Android has 3 ways (mainly) for storing data:
Files
Online database/API
Local database
for this specific scenario you have listed, wanting the data to be available offline, you should probably be looking at using Room: https://developer.android.com/training/data-storage/room, as it supports storing primitive types without having to write any type converters, you can store models and custom data as well, it uses very basic SQL (because it's a wrapper for the older Sqlite database methods) and is part of android (not an external 3rd party library). Room also requires most operations to be done off of threads, instead of main threads and this will improve your performance as well (also has support for livedata/rxjava to observe straight onto any changes as they happen)
However, as I told this user here:
Should i store one arrayList per file or should i store all my arrayList in the same file?
When starting out, don't worry about the best way for doing something, instead, try something out and learn from it, worrying about the best solution now is rather pointless, either way, happy learning and coding :P
My app needs to store data on the phone, but I'm not sure what's the more efficient method. I don't need to search through the data or anything like that. I just need to be able to save the app's current state when it closes and restore when it's back up. There is between 1mb and 10mb worth of data that will need saving.
There are basically a bunch of custom classes with data in them, and right now I have them as Serializable, and just save each class to a file. Is there any reason for me to change that to store it in SQLite?
If you where to use sqlite you could save as you go, and know that whats in the DB is pretty much uptodate if the app/activity holding the data is suddenly killed by the os. Other that that I cant see and obvious reason to use sqlite for your use-case.
Also for the sql approach you have a clear cut way to change the structure of your domain objects at a later time and to migrate the data from a old to a new version of your database. This can be done using serialized objects as-well, but then the objects needs to be duplicated, both new and old at the same time. And that to me sounds very very scary and messy, especially considering that you might need to go from version x to y, so you might end up with some pretty tricky problems if you ever need to update the domain objects.
And I can honestly not see any benefits of using the flat-file/serialized approach.
You mention in your question that the data is only meant to save the state of the app, therefore my initial response would be to keep it on the devices especially since you mention that the file size would not be much more than 10MB, which is quite reasonable.
So my answer to you would be to keep it as is on the device. If your usage of the information changes in the future, you should then reconsider this approach, but for now it's totally logical.
If you're only saving serialized classes, you could use an ORM mapper as discussed in this thread . This saves you the inconvenience of writing your own mapper and is easily extendable to new classes. Also, if your requirements change, you COULD lookup data.
The only reasons for changing your system to SQLite would be more comfort and maybe a more foolproof system. E.g. now you have to check if the file exists, parse the contents etc. and if you'd use SQLite, you don't have to verify the integrity of the data and Android also helps you a little. And you could use the data for other causes, like displaying them in a ListView.
I am writing a social networking android application. I have create a .Net webservice with a database on Microsoft Azure, and I plan to call that web service to get data from the cloud and display it to the user. Similar to Facebook.
Now, I have two approaches in mind, and I'm not sure which one to implement. The approaches follow:
"Every time an activity loads, call the web service and reload all the data." This, of course, is the easiest approach, but is it right? I mean, I have around 30 activities, and half of them load data, while the other half post. As far as I see, this approach can be a problem, because it might slow down the application. It can also increase my cloud bill with so many requests. And I don't know if it's right to reload everytime.
"Call the webservice every 10 minutes, and store all the data in a SQLite database, and only update the data if it's been over 10 minutes, or possibly even have a refresh button." This approach is probably the better one, but I'm not sure if it is even worth writing so much code.
I need you advice in deciding on the right technique. Number 2 looks good, but what if there is something I don't know, and I'm writing all that extra code for no reason.
Please help me out here. If there is even a better approach, please do tell me.
It really depends on the sort of data, what sort of latency is required for the data and the quantity of data. Also the size of the project and benefit you will get from implementation as complexity will be increased. For a more precise answer provide further information.
Local caching can be a very good idea in this sort of situation. It is fairly common practice and there are multiple mechanisms which could be used. Depending on the format of data retrieved from your web service, you can store in a
Database, when data needs to processed (searched, queried etc) or there is a lot of data.
File(s), sometimes useful if you are working with formatted data such as xml or json as you can maintain the structure. You can use the native android caching to assist in managing the storage.
Preferences, when data is simple types (and strings) and there isn't much of it.
Local caching will reduce bandwidth consumption (will end up saving the user money which is always popular) and if implemented correctly memory and processing consumption. Possibly most important (depending on the data) it could allow for the effective use of the application when the user doesn't have connectivity.
By the way 30 activities sounds like a lot, you should really look at reducing that by sharing functionality across activities, this should improve navigation, code bulk and memory foot print.
UPDATE from comments
From the limited information available about your project I would suggest using the database as your data store (if any) as you don't want to be caching complete SOAP messages in files, and the quantity 40+ records may make preference storage difficult to manage.
However, as I have mentioned previously you need to consider complexity. When using the database you will have to create a method of construction (perhaps some sort of ORM) separate to your de-serialisation of SOAP objects because technically you will 2 separate persisted data formats.
I am not able to get a definitive answer because there is still very limited information but you need to evaluate the cost of adding such a feature to your project and the benefits you will receive.
I few other things worth mentioning when considering this sort of caching.
How you will manage the cache, it's size and data integrity.
When will you cache, as soon as you have de-serialised your SOAP objects? when you have finished with the data? etc..
How will decide when to use the cache and when to hit the network?
I have an Android app that needs to work offline and requires a lot of static data.
Currently I'm using a JSON file in the /res/raw and loading it with the Jackson parser into my POJO scheme. It works really well since I have an external program that will be generating this data and once in a while when there is a change I'll just publish new version to the Market so I don't have to deal with running an update server and so on.
However, right now my JSON file is about 2.5MB with limited dataset for testing, in the end it'll be about 5-10MB.
The issue is that it already takes about 3-5 seconds to parse the file and this needs to be done every time the application is restarted.
So, what are my options here? I could put the data to a sqlite database, but that would require rewriting the external application and changing the data structure quite a bit. But then I could only query the things I need at the moment and not loading the entire thing at once.
Is there some easier/better way? Also, is there a good way to publish the app with the sqlite database? All the articles I've found talk about creating the database for user data at first startup, but this is not user data and I need it to be deployed from the Market.
JSON feels like the wrong approach for this - it's a good way to encode data to transfer, but that's pretty much it.
It'd be nice to have a bit more info on what exactly your app does, but I'm struggling to imagine a use-case where having several MB of POJOs in memory is an efficient solution. I think it'd be much better to use SQLite, and this is why:
I could put the data to a sqlite database, but that would require rewriting the external application and changing the data structure quite a bit.
You can still use your other program's JSON output, but instead of loading everything into POJOs with Jackson, you could populate the database on first app launch. This way, the app boot time is negligible if the dataset is unchanged.
If you still want to work with POJOs in the rest of your app, it'd be trivial to write a query that retrieved data from the database, and created objects in the same manner as Jackson.
But then I could only query the things I need at the moment and not loading the entire thing at once.
What're you doing that requires access to all the data at once? Searching or ordering a set of objects is always going to be slower than a SQL query to achieve the same thing.
Also, is there a good way to publish the app with the sqlite database?
You can definitely ship your app with a database, though I've not done so personally. This is a relevant question:
By Default load some data into our database sqlite
Hope that's of some help.
There's an excellent API called JExcel (just google it) that works with .xls spreadsheets. If you're not going to be doing any selecting and just loading data from a source, I like to use JExcel because it's more manageable from a desktop and produces easier-to-read code.
Not sure of any performance differences, however. Just throwing in my 2 cents :p