I understand, at least on paper, the basic difference between the Content Provider and just directly accessing the SQLiteDatabase. I have a functioning prototype for my application, and currently it is just directly hitting the database. I don't really have any experience using the Content Provider pattern, but I have found out that I will need to share some data with another application.
I will only be sharing about 2 out of a dozen or so tables, so I was wondering if I should be just completely redoing the data layer to follow the Content Provider pattern, or just expose only those tables via a Content Provider for the sake of the other application and still directly access the database in the primary application.
One of the issues I ran into with my prototype was that I have some fairly complex transactions, and the code I wrote to get that working is not designed particularly well and isn't reusable at all. As I add more functionality to this app, I'm going to need a better designed data access layer, before I set off writing my own, does anyone know of any good resources with design patterns for this type of thing already? Also, if I need to go the Content Provider route, am I going to have solid control over the database transactions?
I don't think you should have a problem just making a content provider with the functionality you need that sits on top of your direct database code. A content provider is really just an abstraction for accessing structured data that happens to look very much like SQLite. :) If various internal parts of the app directly access the same database as the provider, as long as the code of the two plays together nicely, it should be fine.
I actually am not a fan of being absolute about "thou must always use content providers." If you don't need a content provider, don't use one; just do direct SQLite if it is easier. If you need a content provider for some specific interaction with other apps, feel free to write one just for that without making it a big complicated thing that supports all of the stuff your app does internally with the database. If this is easier, great. It also makes it much less likely for you unintentionally to expose private data from your app to others.
Don't quote me on this, but I'm pretty sure a content provider is a way to abstract the way you are providing data to an object. This way, your object can just communicate with the provider, and doesn't care about the implementation i.e. how/where the data is stored. Perhaps you might want to provide some other way to store your data in the future, and using the content provider paradigm will save you tons of rework, since it's just interface based communication.
I would use the Android design patterns everywhere I could. To be honest, looking at it now I really should be doing this in my project.
Related
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
I am new to Android Application Development and a new member at stackoverflow. I am currently trying to design a recipe application. I have decided upon the features of the app and the scope it will cover. The scope is very vast for me in terms of covering all the recipes from all over the world. I am to deal with a lot of data in this process.
I am currently trying to figure a good and efficient way of handling the data in my app. So far, as per what I have read in different forums, I believe that I have two options in terms of a database choice : 1) SQLite 2) Database on remote server (MySql/Postgre)
Following are some of the thoughts that have been going on in my mind when it comes to taking a decision between the two :
1) SQLite : This could be a good option but would be slow as it would need to access the file system. I could eliminate the slowness by performing DB data fetch tasks in the AsyncTask. But then there could be a limitation of the storage on different phones. Also I believe using SQLite would be easier as compared to using a remote DB.
2) Remote Database : The issue that I can see here is the slowness with multiple DB requests coming at the same time. Can I use threads here in some way to queue multiple requests and handle them one by one ? Is there an efficient way to do this.
Also I have one more question in terms of the formatting of my data once I pull it out from the above DB's. Is there a way I could preserve the formatting of my data ?
I would be more than thankful if someone could share their knowledgeable and expert comments on the above scenario. Also this is not a homework for me and I am not looking for any ready made code solutions. I am just looking for hints/suggestions that would help me clear my thoughts and help me take a decision. I have been looking for this for sometime now but was not able to find concrete information. I hope I will get some good advice here from the experienced people who might have encountered similar situation.
Thanks for reading this long post.
What about combining both approaches?
A local SQLite database that has the least recently used receipes so you don't need network all the time. Network is way slower than accessing the filesystem.
Some remote database accessed via some HTTP interface where you can read / write the whole database. And if you want users to be able to add receipes for other users to see you'll need an external database anyways.
SQLite : This could be a good option but would be slow as it would need to access the file system.
Accessing a local database is pretty fast, 5ms or so if it's just a simple read only query on a small database.
But then there could be a limitation of the storage on different phones
Depends on your definition of huge database. It is okay if it is only 2MB which would be enough to store lots of text-only receipes.
Also I believe using SQLite would be easier as compared to using a remote DB.
Yes, Android has a nice built-in SQLite API but no remote database API. And you don't need to setup a database server & interface.
The issue that I can see here is the slowness with multiple DB requests coming at the same time.
A decent database server can handle thousands of requests. Depends on your server hardware & software. https://dba.stackexchange.com/ should have more info on that. Required performance depends on how much users you have / expect.
I'd suggest a simple REST interface to your database since it's pretty lightweight but does not expose your database directly to the web. There are tons of tutorials and books about creating such interfaces to databases. There are even hosted database services like nextDb that do most of the work for you.
Is there a way I could preserve the formatting of my data ?
You could store HTML formatted data in your database and display it in a WebView or a TextView (via Html#fromHtml()) - both can display formatted text.
Databases don't care what type of text you store, for transfer over the internets you may need to encode the text so it does not interfere with the transport formatting (XML, JSON, ...).
A simple way is to integrate Parse into your app. They have a nice framework that easily integrates into iOS and Android. Their plan is freemium, so you'll be able to use up to 1 million API request for no charge, and then its 7 cents for every request after that.
You'll have 1gb to store all your data sets / images, etc.
I don't use parse for everything, but I HIGHLY recommended it for large data schemes because they do all the scaling for you. Check out the API, I think it would be worth your time.
I just started to work on a few of my own projects, and I'm using Parse again. I have to say it's improved a lot over the last 6-8 months. Especially with the Twitter and Facebook integration.
The key issue here is the size of the data - any significant database of recipes would be too large to store on the phone imho,thus you seem stuck with the remote database solution.
As opposed to trying access the remote database from android I suggest you use a a go between web application that will process requests from the application and return JSON objects that you need.
It totally depends on your software requirements. If you need to deal with a small amount of data then you may choose SQLite, but for a huge amount to data better use a remote DB.
SQLite: It works fine with little amount of data & I experienced it response time is good.
Remote DB: I think you may use small server side app to submit the data to your client app. It will solve/reduce your thread related issues/complexities.
I want to share data across multiple applications, instead of having a ContentResolver->ContentProvider mechanism, I can just define a client library which talks to the process which does the SQLite DB operations right?
What does the ContentProvider brings in here which we cannot achieve by having a Process expose the data?
You can find answer Exact Difference between “Content-Provider” and “SQLite Database”.
But I like to explain this..
What does the ContentProvider brings in here which we cannot achieve by have a Process expose the data?
There is one particular SQLite limitation you should be aware of and that is that SQLite is single-user only. What this really means is that you will need to guard your database from being accessed from multiple threads at the same time. This is generally not a problem in a content provider, since they almost always have a single-threaded implementation.
Also It's good practice to provide the extra level of abstraction over your data to make it easier to change internally. What if you decide to change the underlying database structure at a later time? If you use a ContentProvider you can contain all the structural changes within it, where as if you don't use one, you are forced to change all areas of the code that are affected by the structural changes. Besides, it's nice to be able to re-use the same standard API for accessing data rather than littering your code with low-level access to the database.
You can check the thread below:
Exact Difference between "Content-Provider" and "SQLite Database"
I am writing a social networking android application. I have create a .Net webservice with a database on Microsoft Azure, and I plan to call that web service to get data from the cloud and display it to the user. Similar to Facebook.
Now, I have two approaches in mind, and I'm not sure which one to implement. The approaches follow:
"Every time an activity loads, call the web service and reload all the data." This, of course, is the easiest approach, but is it right? I mean, I have around 30 activities, and half of them load data, while the other half post. As far as I see, this approach can be a problem, because it might slow down the application. It can also increase my cloud bill with so many requests. And I don't know if it's right to reload everytime.
"Call the webservice every 10 minutes, and store all the data in a SQLite database, and only update the data if it's been over 10 minutes, or possibly even have a refresh button." This approach is probably the better one, but I'm not sure if it is even worth writing so much code.
I need you advice in deciding on the right technique. Number 2 looks good, but what if there is something I don't know, and I'm writing all that extra code for no reason.
Please help me out here. If there is even a better approach, please do tell me.
It really depends on the sort of data, what sort of latency is required for the data and the quantity of data. Also the size of the project and benefit you will get from implementation as complexity will be increased. For a more precise answer provide further information.
Local caching can be a very good idea in this sort of situation. It is fairly common practice and there are multiple mechanisms which could be used. Depending on the format of data retrieved from your web service, you can store in a
Database, when data needs to processed (searched, queried etc) or there is a lot of data.
File(s), sometimes useful if you are working with formatted data such as xml or json as you can maintain the structure. You can use the native android caching to assist in managing the storage.
Preferences, when data is simple types (and strings) and there isn't much of it.
Local caching will reduce bandwidth consumption (will end up saving the user money which is always popular) and if implemented correctly memory and processing consumption. Possibly most important (depending on the data) it could allow for the effective use of the application when the user doesn't have connectivity.
By the way 30 activities sounds like a lot, you should really look at reducing that by sharing functionality across activities, this should improve navigation, code bulk and memory foot print.
UPDATE from comments
From the limited information available about your project I would suggest using the database as your data store (if any) as you don't want to be caching complete SOAP messages in files, and the quantity 40+ records may make preference storage difficult to manage.
However, as I have mentioned previously you need to consider complexity. When using the database you will have to create a method of construction (perhaps some sort of ORM) separate to your de-serialisation of SOAP objects because technically you will 2 separate persisted data formats.
I am not able to get a definitive answer because there is still very limited information but you need to evaluate the cost of adding such a feature to your project and the benefits you will receive.
I few other things worth mentioning when considering this sort of caching.
How you will manage the cache, it's size and data integrity.
When will you cache, as soon as you have de-serialised your SOAP objects? when you have finished with the data? etc..
How will decide when to use the cache and when to hit the network?
I'm a bit confused in the question, if it's better to use ContentProvider or Database. Or it makes no difference if I don't want to share any data with other applications.
If I've understood it right, content providers based on SQLite DBs and it's also possible that content of them is only accessable for my application.
Can you give some explanations?
Thank you very much,
Mur
There certainly are worthwhile problems for which a provider is a solution, particularly for cross-app data publishing. For example, you need to use a content provider to supply search suggestions to a Quick Search Box.
However, for internal use within an application, I am not a fan. The benefits IMHO are outweighed by the costs (e.g., reduced flexibility, additional overhead).
If you do implement a content provider, bear in mind that they are accessible by other applications by default. You need to include android:exported="false" in the <provider> element to make them private to your app.
Using a content provider will give you a more modular design, and make your life easier if you at some point in future would like to reach the data from other applications.
If you are certain that the data will only ever be needed from one application, you might as well operate directly on the database.
There is one particular SQLite limitation you should be aware of and that is that SQLite is single-user only. What this really means is that you will need to guard your database from being accessed from multiple threads at the same time. This is generally not a problem in a content provider, since they almost always have a single-threaded implementation.
Reasons to use content provider are here.
In summary:
Easily change the underlying data source (you can change your db from Sqlite to Mongo or to a JSON file without any app changes)
Leverage functionality of some Android Classes (SyncAdapter, Loaders, CursorAdapter) - These classes require content provider and you cant use them if you dont have one
Allow many apps to access, use and modify a single data securely. (which is really the main reason for using it)