Internal storage in non-context area - android

I think it's just a basic question but I used to face the problem from different view. It concerns internal storage or any other method of saving data under android dev.
As far I used to dance with qt cpp/c#/dx9 gaming/etc, but what hit me at android development is that context and disinformation. As usual I wanted to decouple the code a bit, this time I decided to swap fragments in one activity, which got me pain in the ass in form of back button control.
Then I thought to myself, let the model control data retrival and save (viewmodel whatever), and i hit the shit. I've lost the context, so I can't simply get current dir, file locations from .io without passing activity/fragment to model class.
Anyone could tell me what are the methods of retriving data (as dummy content is made, but there is static crap) ? Let it be sync or async, anyway, I want my model to play here and there, what I see is that I hit the wall of missing context because of decoupling. I think I started the wrong way but i can't find the right track.
The main figure here is that I want to use internal storage and sync it with external DB later. The good example of what i'm going to achieve is to render the recycler view and give the app the way to swap it with another view, so i need one clean data model.

Well yeah, I've seen repos as a form of data retrival. I'll retrack the idea and thank you for answer. As we call model (c++ struct) as data only then in fact, data shouldn't load itself, I just wanted to make a shortcut as it's just basic model. On the other end, many web frameworks tend to use models as data factories/loaders, here's my wild concern.

Related

The most effective way to load and use objects from an xml-file

I am looking for the smartest (and most effective) way to implement the following project:
I want to develop an app that accesses to about 100 different sport exercises. The exercises are available in an xml-file. The access to the exercises can be in different ways on different activities:
show all
show only exercises of a special category
mark as favorite and show favorites
show details of an exercise
sort
etc.
Loading the xml-file and creating the exercise-objects is already working and its not problem. But I think about the most effective way to implement things like that. Thinking about RAM and performance...
Parsing the xml-file once the app is started, creating the 100 objects and dealing with them during the app is running (of course ensure to reload the data if the objects where cleaned up by the garbage collector in the meantime). Is this possible and recommended? How can such a central point, where I can pick up the objects in all activities, look like? Can I find an example anywhere?
Parsing the xml-file every time an activity (that is using the exercises in any way) is created?
completely different way?
Maybe someone can give me a keyword.
What I understand from your question is you want to parse XML as app starts every time and generate 100s of Object that time, which you want to use in all other activity.
You can extend Application class for accessing same object for more than one activity. Take look at this question
Application is base class of your app and it is the first one to call. So, you can call your service here and also setter/getter of your objects here. By which you can access it in all activities.
Learn more about Application
Also, you can use SharedPreference or SQLite to store your data in database.
It is just my suggestion If possible can you please make change that XML into JSON format, so in that case you can be able to use the GSON Converter and libraries to get rid of the performance issues.

Gaming Databases Theory

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.

What's the better method to store Android app's data -- in SQLite or on the file system?

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.

Caching images in android?

I'm currently building an android application, and I'm making some HttpRequests to grab images from an API. Right now I'm just storing them in an object container, and then storing them in ArrayLists, but I want to store it into a temporary cache for the application so that when I quit out of that particular activity and go back into the launcher activity, when I go back into that activity, I won't have to make another httprequest for the image.
However, I don't know where to start, what to read up on, or anything regarding temporary storage. I've only used SharedPreferences, and passing extras along intents. Can anyone point me to any good places to get started with, either documentation or sample code?
edit: I forgot to mention that I'd like the data to be deleted when I quit out of the application. I'm not too sure what caching even means, so I don't know if this happens by default when people talk about "caching"
You could refer to Android - How do I do a lazy load of images in ListView.
There are a cache example in Fedor's LazyList.zip from the answers.
The Activity class has some great information on cache directories and the Lifecycle. If your cache is more than a couple megabytes you should consider using external storage.

Implementing Serializable in Android

I want to save my Android game state so the user can pick up and play from where he/she left off.
I have been reading about the serializable interface, but have some questions.
Aside from background rendering and a few other things my game is performed from one class.
Let me explain what that means. I have a class A, and all the different elements of the game are stored in various arraylists and such, in A. SO I have dozens of instances of classes B,C,D,E... all being called and updated (when the screen updates) from class A.
My problem is I am unsure what needs to be serializable. Every class B,C,D.. (i.e. every class? or just A? I don't see why serializing A and then saving the output in SQLite DB wouldnt store all the data.
Just as a suggestion, you may also want to look at Berkeley DB Java Edition, specifically at the DPL (Data Persistence Layer) API. Like SQLite, it's a transactionally protected, recoverable, fast, small footprint database library. However, the DPL allows you to directly persist your classes, making it a much easier choice for Java application developers.
Here's a technical white paper describing the API and how to use it.
if you want to serialize some object. then look at this link use other object in place of hashmmap object that has been specified in this link.

Categories

Resources