Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
So far I've made dozens of apps which use database. I did not go too deep into database logic and how to structure it, but made it as simple as possible and by the rules.
For example, my database logic usually consists of one database class which extends SQLiteOpenHelper. Then I make CRUD methods for each table. Each time I have to deal with a database, I make a special AsyncTask and within it deal with the database. And this is it.
Talking to some developers, I was told that my logic structure should be more complex, more OOP. I tried finding samples on the net but they all were directed towards explaining how to deal with the database. I even reviewed some open source projects but they had the logic similar to mine.
Can you help me? How should I make database logic more OOP? I guess they mentioned that I should be able to reuse this logic in the future, changing only the lowest part which deals with a specific database and its tables.
This is a slightly subjective question, so here's a subjective answer. There is not one correct way to do it imho, I can only speak about how I personally like to work (the big project version, for small projects there's another story). For you or your team it might be different.
For the reference, I work mostly agile, e.g. requirements can change. APIs within the code can change (and do that quite often). This - of course - influences what I consider as useful and what I consider as not useful for my personal work.
Also, I like to work without big frameworks, whereever possible. That's why there is no framework in the model explained below.
I divide database work into three parts to work with: (quite some similatities with the MVC pattern)
The actual database backend (which can execute SQL). Can contain own code for cross-platform work.
The storage class(es), that takes care of storing application-specific information. Each piece of information can be read and set from storage classes, (example: interface AddressBook provides access to elements of the type interface Contact, which have getters and setters for some stuff. The implementation translates that to a single table in the backend).
The application code, which performs actual work and is splitted up further depending on the application (example: stuff providing an address book GUI, etc.).
Why do I split that way? Well, one reason is the ease to switch to a new storage or database backend. If I discover that there could be more preformance when restructuring tables so that new requirements can be met, I update the storage classes. That way I do not have to touch any application logic (example: adding a 1:n table for email addresses to the address book. The new table and its relations do not affect any code within the application, it can recive a list of email addresses from a contact, and add or remove them with ease).
One other reason is that the application code is easy to read (as it consists of, well, application code), while storage code is also easy to read (as it only takes care of storing, caching and similar stuff).
The third reason is that in the case I wish to add another storage mechanism (for example when switching to a platform with a built-in database backend or when adding optional web services) - I can use all OOP mechanisms on the three layers; multiple storages for example can coexist within the same application, so that the user could choose between storing data locally (storage with database backend) or in the cloud.
I hope this answer gave you a little insight of some possibilities with OOP in database-related parts of your application. Again, this is not the one correct way to do it, just one I found working quite well.
Try ORMLite
Object Relational Mapping Lite (ORM Lite) provides some lightweight functionality for persisting Java objects to SQL databases while avoiding the complexity and overhead of more standard ORM packages. It supports a number of SQL databases using JDBC and also supports Sqlite with native calls to Android OS database APIs.
http://ormlite.com/sqlite_java_android_orm.shtml
http://sourabhsaldi.blogspot.in/2012/10/ormlite-tutorial.html
Related
I want to develop a Nutrition Recommender Smart Phone App. Details of project are following.
This app will:
•
guide patients about the choices of food and diet plan according to
their health issues.
provide a list of dieting plans
recommend healthy food choices for men, women, toddlers, kids etc.
according to their age, weight and health condition
• have the calorie calculator
have some good articles about diet and foods
inform people about the nutrition importance of different
vegetables, fruits, beverages, grains, oils, dairy etc.
share some innovative ideas about breakfast, lunch and dinner.
But I don’t know how to design database to implement above functionality. Can someone guide me how many tables should I create and what tables relationship exist?.
Introduction
First of all, this is very basic what you wrote us. You should start specifiing those things and get more into details. For example for a diet plan you can think about the properties such plan could have. Properties are e.g. the length of the plan, the nutrition you need and maybe some sport-excercises. Just some samples. Then you may split up the nutrition in one table and so on. Now you can think about if you want to do all the database stuff on your own, or use a framework. Actually the whole database stuff seen in MySQL and so on is done on a webserver, because of security leaks on the client (decompiling, traffic reading, ...). If you want to save data on the local storage or in a local db (SQLite would be you choice) then you should also think about if you want to use an API for that (e.g. RoomAPI by Android Jetpack)
General thing
You should get your self a clear mind which architecture you want to use. You can store data on a webserver and transfer the data via web-interfaces e.g. REST with JSON or XML. You can also store data on the local device in a file or in a database (which is basically also a file with specific interface requirements). You have to decide and consider you require the exchange on multiple devices or just for one device on it's own.
Planning your structures
After you know which architecture you want to use, you can start planning. First of all I would suggest you to get an abstract view of your project. That means just writing down what you want to have and then start writing down the corresponding properties. For a diet-plan this may be the name of the plan, the length, required nutrition and so on... After that you may know, oh okay, I also need a table with the food and you will see (automatically) that there will be a connection. If you see the connection just draw a line connecting those. In an ideal situation you already know the relation of this connection (One to many, Many to one, Many to Many, One to One, see this stackoverflow article: Difference Between One-to-Many, Many-to-One and Many-to-Many?).
Implementing your structures
Anything I do is handcrafted
In the case you want to do all on your own you may use a gui tool for databases to design your database. You can also use commands to do that, what need much more effort. You can decide on your own and on your knowledge.
Pro for gui
Easy to use
Fast creation of the tables
Contra for gui
May use some cryptic names for indexes and keys
"May don't let you look behind the scenes"
I rely on APIs
You can also rely on APIs. That means often, that you can program the class according to your plan, then annotate it and the connections/relations would be managed by the api. Such abstraction-layer is Room for Android or Doctrine for PHP, those are just samples and there are much more.
Conclusion
How you get the data into the database and out of the database is your thing. You could rely on easy use of APIs or get your things done by yourself. It should be a little guide for you to understand database design.
P.S.: If someone has things to edit, do that! I would appreciate that!
Cheers Tarik.
My goal is to collect health and family related data through interview some patients. So I'll provide every information about every view or question in database. like view type (radio button,edit text ,spinner...), data type (text or number), data length, whether it has any media (image, audio, video) regarding this question. Questions might have a dependency (visibility or value) on other question. I have tried so far and what I got that for small number of questions its okay. But when its about 100 or 150 or more questions, performance is not good. Since I am running lots of sql query and refreshing view manually. I mean on event (onSelect, onChange, onChecked.....) I am saving data to db, changing other question's visibility, value. So far lots of requirement have been added to my app. Can you suggest me about coding structure , library so that I can improve the performance? What are the things that should be used in this app? I have attached some pictures so that you can get a idea.
View Demo https://i.stack.imgur.com/ZCGuz.png
Dependency https://i.stack.imgur.com/j2nzj.png
Required field validation https://i.stack.imgur.com/tFuOH.png
You could use Google Firebase services. There are some huge advantages compared to sql especially with app development. It's optimized for many queries and therefore it's speed is impressive. You can just a Firebase account and use it(Although with limited resources). I would really that you add the firebase library to your project. Also with sensible health and personal data should stay private and as far as I know there are literally always security issues with Apache2 or nginx or php or mysql/mariadb so just do it the easy more reliable and more secure way. I hope I helped you out. :)
I am creating an android application, which i have load URL in to webView.
What exactly i want
I want to store website data which entered by users and store it in to Database.
The answer to this is it depends on your requirements. All have their benefits and trade offs around speed of different operations and simplicity.
I suggest you do some reading before making a choice. An article like this one will be a good start.
https://notes.devlabs.bg/realm-objectbox-or-room-which-one-is-for-you-3a552234fd6e
Personally I've been using Realm for over 2 years and it is fast for stuff like querying, however there are some technical caveats so make sure you read the documentation before you commit to it. I'm saying this because I didn't read it all, and although I don't regret using Realm, there is certainly some things that would have been useful to know before committing to it.
If Realm does interest you take a look at this documentation.
https://realm.io/docs/java/latest/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have just started with the android development and I am trying to develop my first application, which I am actually going to publish. I have a programming background in Java and knowledge of some patterns however I have no idea which patterns I should stick with while developing android apps. Also where to put Threads. I am developing an app, which constantly loads data from a remote database through PHP scripts and displays them on UI. I divided an app to few layers - Presentation layer, Domain Layer/Service Layer and Data Source Layer. Between them I create facades to access the services of the layer bellow. I dont really know if I should stick with this structure or completely rebuild this app according to some other patters. Its better to find it out at the beginning of the development than to be forced to rebuild entire application later on. So if somebody could provide me with some links about architectural patterns which I can use or write something short about it here, I would really appreciate it!
In my opinion the single responsibility principle and separating whole application into different layers (such as MVC pattern but Android is not fully compatible with formal MVC) is a good practice in Android development.Now I will talk about major layers in the following:
Representation layer :
For instance Android framework offers a very straightforward XML representation for Presentation layer,In regard to this XML representation, you should not create the user interface stuff in code. Instead, you must do it by XML.
Application Logic layer:
For application logic layer it is good to accomplish it in code, not anywhere else, For example there is a android:onclick="function_name" attribute in Android XML(for assigning an onClickListener to a View) But as MVC pattern the View/representation layer MUST be fully separated from Controller/logic layer.
Data source layer :
Finally you can have a data source layer which its responsibility is to providing data, persisting data, and all data related stuff. In Android you would put some things in this layer such as dealing with SQLite, ContentProviders, SharedPreferences etc
Result:
I think it's better to pick a main architecture pattern and design your application in high abstraction level according to your picked pattern and then implements its sub-layers. my favorite approach for architectural design and implementation is something sounds like top-down approach, in this strategy you would design your application in top to bottom manner / more abstract to less abstract / less detail to more detail
I divided an app to few layers - Presentation layer, Domain Layer/Service Layer and Data Source Layer.
Alternatively you could divide the app vertically by its features. So you get a package for each feature or activity, perhaps with subpackages. A good rule of thumb is: a package should not contain more logic, than you (or someone else) can easily understand. This technique has some advantages. First, your packages do not become bigger and bigger when you add more features to your app. Second, it becomes easier to maintain dependencies between different features. Perhaps your IDE can generate a dependency matrix of your packages.
Also where to put Threads. I am developing an app, which constantly loads data from a remote database through PHP scripts and displays them on UI.
Android has the concept of Loaders and AsyncTasks. They help you to seperate long running tasks from the UI. There is an example using the Loader-API on the Android developer website.
You might want to put your network communication in a Service instead of AsyncTask or Thread.
Your architecture sounds like some form of MVC which is good in my opinion.
I think the Activity is a good starting point for you. Learn it's lifecycle and how to present your data to the user. You can also read more about threads and connectivity to see for yourself how it's done in android.
I'm reading the official documentation from android's content providers and I've seen this:
Decide if you need a content provider.
You need to build a content
provider if you want to provide one or more of the following features:
You want to offer complex data or files to other applications.
You want to allow users to copy complex data from your app into other
apps.
You want to provide custom search suggestions using the search
framework.
You don't need a provider to use an SQLite database if the
use is entirely within your own application.
I'm developing an app that syncs data on background when the position changes through an IntentService.
What I've seen is that with ContentProvider you could observe when data changes which I really want without user noticing it. It changes in IntentService and MainActivity observes this changes and when it's notificated, layout content change
Is it a great idea to use a ContentProvider although they don't even mention this?
Thanks
Personally, I have been using ContentProviders in all my projects for the last year and a half. They provide good, database independent, data abstraction to access your data. They are very flexible, I even had a play project where one URI pointed to a SharedPreference while all others where for accessing database tables. ContentProviders also allow you to use already built framework infrastructure such as CursorLoaders, for example. Implementing your own from interfaces and abstract classes is not that hard, but it may be time consuming and error prone, being able to just leverage work that's already been tried and tested is a great advantage.
By the way, I remember the same exact question on a post in google+ about 2 weeks ago where Cyril Mottier gave a very good answer. You can read it here.