I am creating an Application in Android that uses a SQLite database. So far i have 3 table, one of which is used to link the first two tables together with foreign keys.
I have been reading a lot online about CursorLoaders, Content Providers, AsyncTask, URI's.... etc. A content provider seems like over-kill for my application, I do not intend to share this SQLite data with other applications.
My question: Is it a good idea in Android to create an object model of each row of Data from the database? My application wouldn't realistically have more than 500 objects from these databases, but is this good design/approach?
More Details: If I were to go down the Object route, I would use these objects and map them to Listviews mostly. Some of these objects may contain arraylists of other objects, Say for instance mapping these kinds of objects to expandable listviews. I tried this approach and it worked really well, I am just unsure of making all of these objects is wasting resources, slowing things down, or will it become a problem later if I decide to expand the application? What if i had 5000 Objects? Just unsure if it's a valid programming approach.
Related
I am reading up on Room and the way it handles relationships between entities is both understandable, but confusing. I cannot wrap my head around what a "proper" data model should be to make Room happy. The problem is that all the examples I have found show how to handle a simple relationship, but don't address nesting, or entities that contain references to multiple other entities.
Going back to the beginning, my question is how should I model my data to make using Room as easy as possible?
Is it possible to have the data model framework-agnostic? That's something that feels correct to me. A framework should not dictate the way entities are modeled. I want to be able to traverse the data model as I would if there was no database at all.
Assuming I have a deep-ish hierarchy, for example: a Game has multiple Players and multiple Rounds. A Round has multiple Turns. A Turn can have multiple Steps. How do I model this according to Room? Reading about #Relation, it would suggest there should be "wrapper" POJOs. But would that mean that here I would have to create classes TurnWithSteps, RoundWithTurnWithSteps, and GameWithRoundWithTurnWithSteps?
This also seems to imply that whenever working with the entities in code, I have to decide which "view" of that entity to use. So I cannot simply work with Game and use it as if it was a true, nicely modeled class?
I'm developing an android app that uses various Lists of Java Modelled entities and FileInputStream and FileOutputStream to store and load these.
The average complexity of my dataManager is 4*O(n^3) for update all entries of 4 different data sets at the same time, where every operation requires 3 nested for on an ArrayList because an Object Palace contains a List of Apartament and an Object Apartament contains a list of People
Could I have noticeable slow down in the app due to my approach?
what is the efficience If I use SQLite to perform the same operations?
In my opinion SQL would offer some advantages.
In terms of efficiency, I can't tell you which one is better (file vs database) without discussing the amount of data you're holding. 2 or 3 records is a very different story than 10,000 records (without even considering the nested levels).
If you're using a file, you have to load everything manually into memory to access your objects, and this means (most of the time) loading the file completely, and saving it completely again.
A database would allow you to fetch only the information that you currently need, and it also allows you to only save the data that has been modified.
Long story short: I'm working on refactoring an old Android project of mine. Previously, it was using serialization, which was painfully slow and, from what I'm reading, a pretty lousy idea in general for Android apps. I'm looking for another way to persist both user-specific data as well and read-only data for the application.
There is going to be a good deal of data on both sides and I'm not sure if there's a "good" way to store it. Basically, the app is a small RPG. There are a number of "maps" that are represented as 2D arrays of Tiles. Each Tile will have a number of attributes, some simple primitives or enums, others additional objects, such as Events, which will also potentially contain various objects, etc. With 400 Tiles in a 20x20 map alone, there's a LOT of data to store. In addition to storing that data, it would need to store a lot of user-specific data, such as which Tiles have been visited, which Events have been successfully run, etc.
I've been examining methods of saving this data out and I just can't seem to settle on something. I guess it boils down to XML or JSON vs SQLite. XML or JSON would be more flexible in terms of future changes, which is good as I want flexibility in the data, ie, adding new attributes to existing objects, adding new objects as the need arises, etc. SQLite isn't as easily malleable as you have to change up the schema, perhaps adjust queries and indexes, etc, but I haven't really used SQLite in the past, so maybe there are some features that help to simplify that process. However, I would also like fast random access to data to avoid loading everything into memory at once if it can be helped. For example, when moving from one map to another, I'd much rather load the next map only when needed rather than having everything held in memory, which is where SQLite would shine as I'd be able to directly query the data rather than traversing a JSON/XML file to find potentially scattered data, ie, we load the map, but Events and objects contained in the Events may not be unique to that map and could easily lie elsewhere in the file or in another file entirely. However, normalizing the data in SQLite would mean a lot of tables and quite a bit of deconstructing/reconstructing of objects.
Writing user data would only occur when the user manually saves the game, so write performance is not a big issue.
I sometimes have a tendency to overanalyze and get hung up on stuff like this. Maybe neither case is necessarily "wrong" and I'm worrying about things that are infinitesimal. Maybe there are other cases that I haven't considered. I've used Hibernate and have considered something like ORMLite to handle a lot of the database nitty-gritty, but that would require a lot of retrofitting, likely much more than what I would need to do for other options.
I'd suggest you use SQLite. I think it makes the most sense considering the amount of data you're trying to store.
As far as your concerns with it not being as flexible, I would argue that point. Just use a ContentProvider. ContentProviders make it pretty easy to update the db schema and queries without affecting your existing functionality. If you use a ContentProvider, you could even swap out persistent data strategies in the future as well as use different ones simultaneously.
http://developer.android.com/guide/topics/providers/content-providers.html
I'm writing an application which needs to store data. A single pack of data is about 4 classes with many dependencies between them. For example, class A has a list of objects B and B has a list of objects C and few more dependencies...
And I wonder what would be better. Keep them in SQLite db or serialize each pack separately and store them in serialized files?
For me the only right solution would be to save the data inside a database especially if there are any dependencies. For beginners it might be hard at the beginning to get into database creation. but after you have created a database in the right form you just have to insert the data and you won't have any problems in the future if you want to change something or expand your app. With simple serialisation the logic has to be solved inside the app and might cause more problems especially if you have any dependencies.
If you need a good tutorial for saving data you should look at this tutorial
http://thenewboston.org/watch.php?cat=6&number=111
For other different solutions for saving data there are also some tutorials on the website, Nr. 108 - 110 of Android programming
IT depends on the usage of the data. You may do well choosing JSON/GSON serialization and avoid the overhead of doing ORM over SQLite. (Overhead meaning additional coding to marshall to/from the db) However, if your data is subject to growth or something that would be better managed by a db (a lot of non-sequential or random access across a larger data set) then go for SQLite and ORM. In the end it comes down to what type of data you are trying to manage. Again if your data set is something that could grow and involves a lot of random access it may be worth using SQLite.
I'm writing an application that communicates with a web API, which responds with JSON. Currently, I'm translating the JSON objects to Java objects using gson (which is awesome, by the way).
Now, I want to store some of these objects in an SQLite database. However, they have lots of properties that would never be used in queries (i.e. I won't be ORDERing, WHEREing, or anything like that with those properties), so I feel it's unnecessary to create columns for all of them. What I'm thinking of doing is:
Only have columns for the essential data that will be used when querying the database
Have one TEXT or BLOB column (which one do you recommend?) that stores the actual JSON, so I can recreate my Java object from it and access all the data.
This would both make my life easier and streamline my code (I would not have to write very different code when dealing with data from the API vs. data from the database).
However, although I see no downsides, it feels a bit fishy.
What kind of trouble do you think I would run into if I use this technique?
The main thing I wouldn't like about it is relying on the structure of the stored/retrieved JSON to be valid, since it's completely out of the hands of the database. Not that you can't take precautions against possible issues, but if the JSON is somehow truncated or otherwise compromised in a way that trips up the parser, you're then missing the entire object instead of just one invalid or truncated property. If that's an acceptable risk, then it's probably a reasonable technique.