I was browsing around and I found different ways on how you should implement the database:
This says it should be open the whole time, while
This says it should be opened and closed only when data is being read/written.
which had me thinking, which is really the correct way, when applied to SQLite database running on Android? Should one have the database open during the whole lifetime of the app, or should it only be opened/closed when data is read/written?
What are the advantages and disadvantages of each of these two approaches?
Related
I have 2 SQLite databases in my android project, 1 is used to store profile details of users and another one stores book appointments. Currently the two do not link but work fine. I might sound a bit stupid, but is it possible to connect the two so when some clicks on the booked appointment of a certain user it will go to their profile. I cannot see a way how this can be possible and after spending quite a well I've not been proven right.
If it is possible, could I please get some pointers as how to go about doing it. I have unique id's in both that increment, and potentially the names would be same in both but I have no measures to check for links etc.
Sorry if I have not made myself clear, I am quite loss with this and having spent several days, the only way I can think of doing it is redesigning the whole thing and instead of having seperate databases, have one for both but only shoot off relevant content to the activities required i.e. profile details to one and appointments to another. Not sure whether this will work as well and I have already spent very long designing what I have!
I I suggest to export table(s) from one database to another one. it is easy and compared to what you are trying to do, is like a piece of cake. you can do this in SQL Server(i assumed it is your database) without have to code. but i stand correct if you need some of your data, you must do it with queries.
I'm not new to Java or databases, but I am new to Android app development. I have an app idea and have started to put it together. It's a very simple game that I would eventually like to have multiplayer capabilities.
The part of this process that I am pretty clueless about is the backend portion of the application. I need a database that will store things like usernames and passwords, scores, and things of that sort. I will also need to store things that I will need for the game in here. The application will rely very much on the database and it is important that any device has access to it and they are all looking at the same data.
If I've done my research right, this means that a simple SQL Lite database on the device itself isn't going to help me. Ideally, I would use SQL Server and create the database, as that's what I use for other projects... but I have no idea if this is possible or ideal.
I really just need somebody to steer me in the right direction here. I want something simple that can be accessed easily by any device at any time.
You'll want to write a server application which the various clients connect to. This server would be responsible for processing information given to it by clients and returning appropriate data back.
Exposing the database directly would be unwise; it would allow inventive players to cheat your system (or worse!) because they would have unfettered access to anything your application does. Your own server application can ensure that only reasonable access to the data store is permitted.
As for how you implement it, there are any number of choices. Web services are popular these days (in which case ASP.NET is the likely fit with SQL Server), but you can implement your own, non-HTTP, game protocol if you'd like.
You could access remote SQL database from Adnroid app using JDBC.
I've provided example here: How to save image files to mysql with sql code and how to display them with java?
The only difference I've encountered using JDBC in desktop and android apps that in Android You have to perform JDBC operations in a separate thread, like any other network operation in Android.
I have developed an Java Swing Application with MS-SQL Server database and now i want to provide backup and restore option in my java swing application that is on click of a button it should backup the database and restore the database any possibilities of how can i do it through java. please help
Two ways to do that. Backup and restore are just sql commands so you'd do them just the same as as you'd do any other bit of sql, e.g. a sql insert statement, unfortunately you need to know a fair bit about the the system to just do them, and you'll get no progress indicator. Using SQLSMO is another possibility, not sure about hitting a .net dll from java though. You could use SQLDMO (pre.net), but you'll need to install the backwards compatibility tools, and you'll give yourself an upgrade headache as DMO (while it seems to work) is not supported from SQL2012. Both have an event you can tick a progress bar on, course if the back up is fairly quick you could get away with not bothering with that.
However, some more to think about. You can backup while the system is running, but then you'd don't have a clear point where the system was at when you did.
Restore requires exclusive access and a high level of privilege, so it's not something you hand out and you need to get everybody off the databases.
And last but far from least it would be very bad, if you inadvertently restored a version of the database that no longer matched the application....
Personally I'd say the people who were authorised to do this should be able to do it without your tool. Dumbing it down, means a lot of code to make sure they don't restore a sql2000 back up from the trial you put out eight versions ago.
We did something similar back up restore code is a bout 2% of the application. For instance we do a pre-backup check, using dbcc et al, to make sure they aren't successfully backing up a corrupt db...
You can write a simple script to backup your database and invoke it from java.
You really need to put a little effort in here.
Since you can connect to the database server already and send it SQL commands, read this for backing up using TSQL.
For database restore, read this.
You need to have the appropriate permissions and access to the hardware for this to work.
I searched in google and stackoverflow for my problem, but couldn't find a good solution. Below is the description,
Our Java web application displays search results from our local database and external webservice API calls. So, the search logic should combine these results and display it in the result page. The problem is, the external API calls return the results slower than our local DB calls. Performance is crucial for our search results and the results should be live i.e. we should not cache or persist the external results in our local DB. Right now, we are spanning two threads, one for the DB call and another one for the exteral API, and combine these results and display it on the screen. But it kills the performance of our application, particularly when we call more than one external APIs.
Is there any architectural solution for this problem?
Any help would be greatly appreciated.
Thanks.
You cannot display data before you have it.
1) You can display your local data and as they come, add via ajax other data.
2) And if there are repeated questions, you could cache external answers for short time (and display them with warning that they are old and that they will be replaced by fresh answer) and as soon as fresh anwer arrive, push new answer.
With at least 1), system will be responsive, with 2) usable answer can be available imediately, even if its not current.
btw, if external source take long to answer, are you sure that their answer is not stale (eg. if they gather some data and wait for rest, then what they gathered so far can go stale)? So maybe (and maybe not) short term persisting is not as bad as you think.
I am creating an android app that is basically a listing of information on Mushrooms. I get this information from an sqlite database. I have a global singleton with a services class inside it in which I use to access my db. Almost every activity accesses the db. Is it better to leave my db open all the time or open and close it as I need the data?
If the best practice is to leave it open all the time, where do I need to make sure to close it and what is the worst case scenario if I left it open when the activity was destroyed?
Your best option here is to refactor so that your application accesses the database via a ContentProvider. Your ContentProvider implementation is the only thing with a handle to the database open.
This gives you several advantages:
only one thing has the database open, so your problem just goes away.
lots of standard support classes to automate stuff like database management.
better integration with the standard Android list-management views, which are all designed to work automatically with cursors provided by ContentProviders.
All your data can be addressed by URI (typically of the form 'content://com.fnord.mushroom/mushroom/43'), which means that other applications can access your data too.
Using a ContentProvider, it's possible to glue three or four standard classes together to produce a browser interface to your database and never actually have to write any real logic.
On the negative side, ContentProviders only really support access via a limited interface --- in SQL terms, you get INSERT, SELECT, UPDATE and DELETE with no nested clauses. If you're doing complicated SQL stuff it can be a bit painful to route requests from your app to the ContentProvider and back again. However, most people don't need to do this (and if you do, custom intents are the way to go).
I would open the db as needed. That way you know for sure the connection is closed once the particular activity that opened it is finished. Although Android has built in checks to make sure it closes upon application termination, it doesnt hurt to be on the safe side. I'm also guessing having it open all the time could cause leaks or something.
Based on my past experience in Java I would say it is better to close the connection, it probably doesn't matter in a small Android application, but if you have 10 applications running and all of them access the database, you have 10 pending connections. Start a few more and sooner or later another application will have to wait because the SQL server can't handle any more requests.
I guess you could think of it as a file on your computer. You read data from it, and then close it when your done. Why keep a file open in your application?
Now I'm very new to Android programming so I haven't got around to implement database calls. But when I faced the same problem in a Java application a few years ago I implemented a database object, in which I had the connection to the database. "Everyone else" (the classes) had to call the database object (singleton or final methods) to get data, sort of like stored procedures but in the application instead.
Because of this I knew when the calls where made and when they stopped. I then put in a timeout, so as if nothing happened in a few minutes, I would close the connection to the db. (This also took care of some timeout exceptions because the timeout of the connection would never happen.) When a new call entered, I could easily start a new connection and use the new db connection.
Basically I abstracted away SQL calls by having methods as public Fungus[] getAllFungus() and public Fungus[] getFilteredFungus(string where).