Develop Reference

The most efficient way to implement a database using custom data + google fitness api

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

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.

How to Properly Structure my Android App, Classes, Views, Databases, Made Simple?

I'm having a hell of time grasping the best way to "package" my Android app into logical components, my objective is to make an app that is easy to update and add new features to.
I believe a "modular" approach would work best, one where my data is represented as Data Classes, my DB has it's own DB Helper Class which handles all DB interaction and finally View "Controller" Activity Classes which interface the DB Helper, Data Classes and Views all together.
This being said, I need some high-level rules in order to structure my programming, I find if I don't have rules, I end up with sloppy code and massive rewrites as the code gets too complex.
All things considered, are these rules a good foundation for a SQL backed App?
My theoretical Android rules:
The DB Helper Class should contain all DB logic. This means, the DB Helper will contain the code to open and close the DB, as well as the code for inserting, updating and deleting all records. The DB Helper will return data not as cursors, but as Data Class objects that I create, each Data Class will have a constructor which takes the cursor and uses it to populate the values of the Class.
Data Classes will allow DB records to be represented as objects and not just cursors. As the DB Helper will only be returning objects I will have to create adapters for items such as ListView's to render my object's data as opposed to the cursor (I'm a bit fishy on this point, not sure if this is a good idea or not). All business logic, so all calculations to be done on the data contained in the Data Class, will be done in the Data Class itself. I envision my Data Classes having typical getters and setters as well as "calculate" methods, these calculate methods will take vars from the Data Class and do some meaningful business logic on them, returning the result (is this a good idea?).
View Controller Activity Classes will literally tie the DB Helper's methods to the Data Classes and update the Views with the resulting information. This Activity Class will be quite normal, it will initialize the layout and widgets, it will use the life-cycle methods to perform various queries on the DB through the DB Helper at the appropriate times, and it will have simple update methods which update widgets using the Data Class object they're fed.
I am finding I have no troubles with Android except for struggling with issues of design such as these. I am tired of my applications becoming too complex, and I need a simple system to ensure things stay manageable and extensible.
If you struggled like me, please, please, please, push me in the right direction for structuring an App. It's all that's holding me back from making what I hope are amazing apps for everyone's enjoyment.

The biggest thing you need to consider when designing your app is: who is going to maintain it? If you are going to be the only one who is doing maintanence on your app, then do whatever works best for you. However, if others are going to be maintaining this app, then yes, you will want to keep similar things together. It sounds like you have a pretty good plan. Make sure you use comments and if you like, you can include a "readme.txt" that will allow others to see what is going on and for you to explain your design logic. To keep things from becoming too complex, you can use packages to store similar classes.
Ultimately there is no single right answer to your question.

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.