Develop Reference

How Can I Create a Database Accessed By windows and Android

I have been looking and searching for this whole day, so i want to create a database which can be accessed by both computer and smartphone, is there a way to do it, and how ?
Sorry For Beginner Question, Thanks in Advance

Ok, the first thing you should do is to define the type of database
that you want. You can build SQL or No-SQL database. For the most
part I would suggest no-sql so something like MongoDB could do, but you can always do mySQL. As
for accessing that db with anything actually, you need application
layer around it. You see, database acts as just a huge data
container thus it should not be used for any other logic.
Now, lets talk about application layer. To be more precise - about posting/updating/retrieving data from db. You should research something about RESTApi or GraphQL concepts as they are used to make communication between your app and your db which is hosted on a server (I deliberately did not talk about how you can build an app because I assumed you already know this one).
THE POINT: The most important concept to wrap your head around is how you can access the db you make not the type or tech used to build it. (Even though this is important too)
Good luck!

The better way to do this its creating a web service, so your app will talk to this web service, the web service will talk to your database and retrieve the results to your app (this can be done using HTTP protocol's APIs like Volley for android) and its a secure way to do it.
You can connect your application direct to your database granting external access, but this is a specif configuration according to your database (mysql, ms sql, etc.) and its not recommended.
You can think in the same way to the computer(s) that will access your database, except if this computer(s) is in the same network which the computer that your database is hosted in, in this last case, the program in this computer (which will access the database) can access it directly (you need to setup the database to permit this and this setting is diferent according to your database).

approach for synching android app database with server db?

I'm developing an Android app as a "proof of concept" for our company. If they like it and think it's worth investing, then we'll move on to bigger things. I'm trying to figure out the best/most practical approach for this.....the basics of the app will connect to our DB and display information regarding a specific customer. For now, let's say we will only pull data from 3-4 tables (but there could be 10+ in the future). If the app doesn't have an internet connection then it should use the local DB. What is the best approach for this? Here's what I was thinking and would like some input/suggestions if possible:
1.) app runs checks internet connection. If exists, check db version (how, through a web service?)..if server db is newer, get latest data. If no internet, use local db.
2.) app parses data and displays it.
If this is correct, then there could be no modifications to the web service that would add fields to a result without changing the app as well. Is there a way for an app to parse fields regardless of how many fields there are?
I've read and walked through the tutorial on google with databases and such (Notepad tutorial) but it seems like the column names are all hard-coded in the parsing class, which I was hoping to avoid.
Sorry if this is confusing but I know I need my app to use a local db to read data, I also know that the app must get data from the server when it can (via onCreate or a refresh button) and copy it locally....Copying it locally is the part I'm having trouble understanding I guess....is there no way of saying "go out and get this result and display it", knowing that those results could mean 5 fields the first time or 1 the next.
Any help/guidance is greatly appreciated!

You probably want to use a SQLLite DB to store your data locally, a ContentProvider to provide CRUD access to the db, and a SyncAdapter to sync with your server when possible. The Sync Adapter also writes to the DB via the ContentProvider. See the SampleSyncAdapter sample in the SDK for an example of how this works. You will be implementing your own ContentProvider, but the sample just uses Android's supplied Contacts ContentProvider.
http://developer.android.com/resources/samples/SampleSyncAdapter/index.html

SQLite or something else?

I am trying to decide on what data storage methods to implement. Here is the situation. Whatever method I choose, it is going to be updated once week (can I update a SQLite db without putting out an update in the market?). The user cannot add or remove items from this ListActivity, they can only pick the ones they want. This data method should be able to remember the selected items during any given week. Let me know what method you would use and why. Thanks so much in advance.

A webservice would allow you to update the data whenever you want without having to push updates to the market. And updating your app in the market doesn't guarantee that users will apply the update. Ofcourse the downside here is that your users would need to be connected to the internet while using the app.

Moving your database to remote server will give you freedom to manipulate data without actual application being updated, thus no need to update on the market. If it is a matter of access to internet, you can still use this practice, just more work has to be done (adding Broadcasters that will listen to connectivity than update the local database with global one on your server, or something similar).

If you want to update the data on the device once a week, then you will need to use the local SQLite database and interact with a web service that provides the updates. You will not need to go through the market to do this. However, if you need to update the structure of the database (add, remove, or change columns or tables for example), then you will need to update your app on the market.
I highly recommend watching the Google IO 2010 talk Developing Android REST client applications. The speaker is the author original author of the Twitter app for Android, and talks about the design patterns and best practices that he uses.

problem to understand content provider

dear i am confused the use of content provider in android applications.i go through various sides and read it but i am still confused about content provider ..can any one explain it in some simple way ,how to use it?
Content providers store and retrieve data and make it accessible to all applications....whats that means?
can it means any package name or in same pakage name...
if i am making another app of diffrent package name then that c.p. is available also in that package?

OK, first of all, a content provider will be used if and only if you want to use the same data through several applications. You can still use it if you want to implement it in your application.
Now, by definition a ContentProvider "Content providers manage access to a structured set of data. They encapsulate the data, and provide mechanisms for defining data security." (According to Android Developer Guides)
So in other words, it's like a new layer of abstraction that you are adding to your data, assigning a new man-in-the-middle that will request everything you ask it to do (read, write, update your database, files, or webservices). And this man-in-the-middle is not only available for you, it's also available for other apps if you set the tag android:exported to true in the <provider> in your manifest file.
A ContentProvider needs you to implement:
A contract: Basically a class with public static variables with your tables names and the fields of info for those tables.
A data model: Normally a database in SQLite but you can implement it also with third party libraries like SugarORM, GreenDao, Retrofit, local files, etc).
Your custom ContentProvider: Extend ContentProvider and inside here set the calls to your data model.
This is a good tutorial on how to make your own ContentProvider:
http://www.grokkingandroid.com/android-tutorial-writing-your-own-content-provider/
There are also a few libraries that will help you create a ContentProvider automatically (I find it amazing because it takes you like 10 min to set up everything, instead of creating your own ContentProvider from scratch which could take you days).
My personal favorite is Schematic:
https://github.com/SimonVT/schematic
I hope it helps. Kind regards!

how to use it?
you actually don't use it directly, but via the content resolver (which will, according to the URI you give it, query the right ContentProvider) :
getContentResolver().query("content://com.myapp.myprovider/data/", ...);
will find your content provider if that one is registered to handle URIs that match "content://com.myapp.myprovider/data/"
if i am making another app of diffrent
package name then that c.p. is
available also in that package?
If you decide to publish the content provider, it is available outside of your application (this is a setting in the manifest).
what is the major benifit of using c.p.?
It is a common design pattern in Android to offer access to data. Major benefit is that you can abstract access to your data and decide whether to open it to other applications or not. For instance, without content providers, you could not access the media stored on the phone or the contacts of the phone.

Since a package is meant as a unique identifier for an application, how can you create an app with the same package name? If this was your question, I think I've answered it. If you don't understand something else - feel free to ask. Good luck!
P.S. Consider accepting some answers, your accept ratio is low.

When to use a Content Provider

I understand that Content Providers are made to allow publicly sharing data between applications. However, I'm wondering if anyone has thoughts about making a Content Provider to use just within your own app. Would there be any advantages to doing this? Any disadvantages?
In the past I've just implemented the SQliteOpenHelper to access data from my database, but I'm considering creating a Content Provider. I feel like the URI approach to requesting data is clear and concise. On the other hand, will using a Content Provider just for my application be redundant ( since within it I will have a SQliteOpenHelper class ) and more work than I need?

I would argue it is definitely a good idea to use a ContentProvider even if you don't intend to make it public.
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.
Also, there is always the chance that you might want to expose your data in the future. If you don't use a ContentProvider up front, it will be much harder to retrofit it in at a later date.
Then, there's the other parts of the Android where ContentProvider's are required/recommended such as when using SyncAdapters and if you want an App Widget that involves data access for instance.
In summary, there is very little overhead involved in writing a ContentProvider up front (once you have learned the API which is a good idea anyway) so it makes sense to do so, even for private data.

If you are not planning to share data, don't think about Content Providers. They are powerful but hard to write and it will be just silly to implement them if you are going to use them internally.
However, I'm wondering if anyone has thoughts about making a Content Provider to use just within your own app.
Of course... for instance, for an old TODO list app I wrote, I had to write a content provider to allow other apps retrieve and access the tasks states. It was part of the requirements, but more than that it made sense and made the app nicer.

Take a look at the MOTODEV Studio for Eclipse. It is a development environment that extends Eclipse. They have a tool where you can automatically generate a content provider for a database. If a content provider makes it easier to access your data and it doesn't have a significant impact on performance go ahead and use it. In most scenarios this will be the case.

In short,Content Providers helps in managing your data effectively. I would suggest to use them for the following reasons.
It acts as an abstraction layer between your UI and database. You can implement data validation in ContentProviders to validate the data entered by the user. It also lets you to modify the structure of the database without touching the UI and other parts.
They play along nicely with other android framework classes like SyncAdapter. For eg., you can automatically refresh a list, when a value in a database changes using ContentProviders along with CursorLoader. Without ContentProviders you have to implement a lot of functionalities like these on your own.
We can safely expose our private data to other apps. Using ContentProviders will allow us to share our data easily and safely with other apps.
So even if you don't need any of these functionalities now, you might need them in future and its good to go the extra mile and implement them right now.

I agree ContentProviders are a little difficult to grasp but they are definitely helpful, even if you want to use them internally for you own app. The best thing about it is that you can customize the contentproviders for suitable URIs.
Here's a scenario where you may have 5 tables in your database, but you need to join a few of them in certain orders before using them. And make a content URI for each of these joins. You could then each use these URIs as a table :)
I suggest you go ahead with Content Provider, you'll be amazed to see how powerful it is.

In my view point, the content-provider comes with plenty of advantages leave alone just sharing data with other apps. If you need to synchronize with the server using a Sync-Adapter, use google cloud messaging, auto update the UI when the underlying data in the DB changes using Loaders, implement search, use widgets... then the content provider is for you.
I prefer you follow the guideline on because one day you may need to implement some of the above features attached to the content-provider
By the way, you can quickly build you database and CP in less than 5 minutes using content provider generator

As said in documentation:
Creating a Content provider
You don't need a provider to use an SQLite database if the use is
entirely within your own application.
So why bother developing this overhead? You want easier and faster development, right? So one layer of abstraction (SQLiteOpenHelper descendent) is enough.
See Occam's Razor
Do not make an entities without very good reason.

Using a Content Provider can help in an additional level of abstraction - Putting it within your own application make add a significant development time to your project. However if you are using it to share data, application settings or configurations across multiple applications then the Content Provider is your choice.
Watch your security levels and I would recommend using SQLcipher to encrypt data-at-reset (DAR) if your Content Provider is writing to SQLite. (I've used a content provider in a few solutions and provided the ability to take a live "snap shot" of the operational values for debugging and testing.)

Do not use content provider if do not wish to share data with other apps. Use simple sqlitedatabase to perform database operations. Be careful while using content providers for storing confidential data because your confidential information may be accessed by other apps