Creating android financial manager application with using of SQLite.
My question is how to deal with the database in terms of object oriented programming?
Say I want to write information about a purchase into the database.
Should I:
1) Get user information from EditTexts, put it into an object say "Purchase", which contains fields: productName, ammount, price...
And only than put information from the object into the database?
2) Or put data from EditTexts directly straight into the database?
3) Another way?
I've used many different frameworks available out there, from SQLite to ORMLite. But, in terms of speed, there is no alternative to Realm.io. You can basically create your data models and define them as Realm Objects. Then the rest is easy, you can read, write and query among the data models you created.
If you want to know, what is a better way to use SQLite, than you can check this article
Option 1. Create objects that does represents your data.
Create your Database Class to use the objects instead of methods with multiple arguments.
I would make a container class that you use as a way of keeping the code clean.
Related
I am currently developing a health app on android.
There would be a need to store personal data like gender, height and settings for app.
I plan to create a table with different columns.
My question is about creating the table with default values and editing the database.
My first thought is to create table and add a row with default values in onCreate().
But it seems to be wrong usage of onCreate() as i see multiple examples that only db.execSQL(SQL_CREATE_ENTRIES) is onCreate().
Second thought is to make use of DEFAULT in SQL but still i have to find somewhere to run add row.
What's the good practice to do so?
About editing those data, i put multiple public get and set function in sqliteopenhelper class.
Is it right to do so?
As multiple tables are created, the sqliteopenhelper class seems to be a bit messy since there are a lot of functions.
Welcome to any suggestions and criticism.
Thanks all.
Does your data really need an entire SQL Database? From your question I understand that you store data (gender, height) for a single user. If it so, you can use Android's SharedPreferences. SharedPreferences are a simple Key-Value store system where you have functions for both setting and getting you values based on a key (similar to a single SQL Table with two columns, key and value).
Hey so I am new to using sql dbs, (mongodb / nosql fan here)... and I am trying to create an app on Android and store the information usually stored in a db for a website on the device, from what I understand I should use SQLite? (any objections let me know). When wanting to show info on a website would I be calling a get or can I just make the query calls right on the activity screen?
Lastly, this is an example of the information, and I wanted to know how I would store this as I heard that it only accepts integers, strings, and doubles?
Here is the db info needed to be stored:
Stored: {
id: 2322d2ej2j2k, (unique)
name: Animals, (unique)
languages: [english, spanish],
order: [a, b, c, d, e, f, ...],
words: [{english: hello, spanish: hola}, {english: thanks, spanish: gracias}, ...],
date_created: new Date()
}
Also, for the order of letters, I want to be able to say that the order can be for letters in other languages too.
I'm unsure what you mean with "wanting to show info on a wesbite would I be calling a get", as the SQLite database would be stored in a sandboxed location belonging to your app, you wouldn't be making HTTP requests but talking directly to the database.
I can suggest looking into : android.database.sqlite.SQLiteOpenHelper and extend it to create a wrapper for android.database.sqlite.SQLiteDatabase for the most common CRUD operations.
While it's true that SQLite is more limited in data types (and querying operations) as full-on SQL, I find it more than adequate for most data operations. For complex Objects / nested values (like the "words"-property you describe in your question) I'd serialize these types of data into a String/JSON and reassemble it back into an actual Java Array/Object when reading it back from the database.
I prefer to think of records as entities in this sense and create a Model (extending your SQLiteOpenHelper implementation) which wraps the QSL CRUD functions to work with Java Objects and convert these to and from the data types supported by the SQLite database (i.e. create an abstraction layer such as "saveRecord" which accepts a Java value Object described the properties you posted in your question, but internally converts it to a more friendly format for storage, likewise a "getRecord" which returns a Java value Object created from the stored data).
I'm working on an Android app for homework management. I'm a senior in college, so my experience on larger projects is very limited, but I'd like to design all parts of this app well instead of just throwing something together. This includes the way data is stored.
We have two main objects/entities: Task and Subject. Even if someone uses the app for the whole time they're in college and never deletes anything, I'm guessing there would be a maximum of a few thousand tasks and a couple hundred subjects (not all subjects would be shown at once). The initial version of the app won't sync data with a server, but this is a definite possibility in the future, so I'd like to design with that in mind. We might also have an option for users to send tasks to each other.
Here are my questions:
Would a SQLite database be the best option for storing the amount of data we're likely to have, or would something like serializing it to XML or JSON then loading it into memory when the app starts work?
I'm used to thinking in terms of objects. This means that if I use a database and it has a Task table and a Subject table, my first instinct is to convert each database table row into a corresponding object for viewing/editing. (The objects' setters would contain validation logic.) Is this a good/helpful/necessary way to think? If not, what is the alternative?
Thanks for your help!
This question is broad so may comments below may not be 100% correct as I don't have all the information about your system.
SQLite is better suited for storing thousands of records than files (be it JSON or XML). This is especially true if your data is not static, i.e. will be changed during the usage of your app (which is the case for you, I believe). You can take advantage of existing functionality for records inserts, updates, deletions, using indexes, etc.
Yes, you generally create objects similar to your database. But you don't usually need to convert each and every record from the database into your objects. You usually query the database for a limited number of objects, depending on what you want to show in the UI. Of course, if you need to show all, let's say, tasks, you need to get them all.
1. Would a SQLite database be the best option for storing the amount of data we're likely to have, or would something like serializing it to XML or JSON then loading it into memory when the app starts work?
Yes SQlite will be the option for you.It will give you a structured format and in future if you want to access data from remote end the same structure of tables can be used without much change in the code.
2. I'm used to thinking in terms of objects. This means that if I use a database and it has a Task table and a Subject table, my first instinct is to convert each database table row into a corresponding object for viewing/editing. (The objects' setters would contain validation logic.) Is this a good/helpful/necessary way to think? If not, what is the alternative?
you can simply execute queries to manipulate data.
But dont forget to encryt your database if you storing it in mobile itself.
In my app I need a central storage object that will be accessed from different parts of the application (like a singleton data holder).
AFAIK the clean way to implement singletons in Android is to use the ApplicationContext.
How can I
put data (like instance of List<MyPieceOfInformation>) in the ApplicationContext and
get them out of it
?
Is it correct that the only way to store more or less complex data in Android is to use the built-in SQLite database?
you can use mysql and others as well.
it is all depends if you want to save the data in local or external.
as external, for example, you can use mysql and web server, then communicate using json.
for saving List, you can use static.
In my app I need a central storage object that will be accessed from different parts of the application (like a singleton data holder).
Then use a singleton.
AFAIK the clean way to implement singletons in Android is to use the ApplicationContext.
First, there is nothing in Android named ApplicationContext. You probably mean Application.
Second, in the opinion of many experts (myself included), a custom Application is less "clean" than regular singletons.
Is it correct that the only way to store more or less complex data in Android is to use the built-in SQLite database?
Comparing a singleton to a database is like comparing an apple and an asteroid, on the grounds that both are made of matter and, in English, begin with the letter "a".
A database is persistent. You use a database when you want to save data persistently.
A singleton is not persistent. You use a singleton for transient data, such as a cache of data that is backed by a database.
I'm new to both db4o and Lucene.
Currently I'm using db4o to persist my data on an Android app. I need the capability to perform quick searches, as well as provide suggestions to the user (e.g., auto complete suggestions).
An SO poster mentioned using Lucene to index data and db4o to store it.
Has anyone implemented this approach ? If yes, I would appreciate if they share the overall approach? What are the alternatives?
I used Lucene to extract keywords from items to be stored in the database and store what I call 'keyword extension' objects that point to the corresponding domain objects. This made the domain objects findable by keyword (also allowing for stemming), and separated the keywords concerns. The database was built from a large static dataset (the USDA food nutrient database), so I didn't need to worry about changes during runtime. Thus this solution is limited in its current form ...
The first part of the solution was to write a small chunk of code that takes some text and extracts both the keywords and corresponding stems (using Lucene's 'Snowball' stemming) into a map. You use this to extract the keywords/stems from some domain objects that you are storing in the database. I kept the original keywords around so that I could create some sort of statistics on the searches made.
The second part was to construct objects I called 'keyword extensions' that store the stems as an array and the corresponding keywords as another array and have a pointer to the corresponding domain objects that had the keywords (I used arrays because they work more easily with DB4O). I also subclassed my KeywordExtension class to correspond to the particular domain objects's type - so for example I was storing a 'Nutrient' domain object and a corresponding 'NutrientKeywordExtension' object.
The third part is to collect the user's entered search text, again use the stemmer to extract the stems, and search for the NutrientKeywordExtension objects with those stems. You can then grab the Nutrient objects that those extensions point to, and finally present them as search results.
As I said, my database was static - it's created the first time the application runs. In a dynamic database, you would need to worry about keeping the nutrients and corresponding keyword extensions in sync. One solution would be to merge the nutrient and nutrient keyword extension into one class if you don't mind having that stuff inside your domain objects (I don't like this). Otherwise, you need to account for keyword extensions every time your create/edit/delete your domain objects.
I hope this limited example helps.