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).
Related
At the moment, I have a little JavaFX app that generates reports and statistics from the data on a remote MySQL-Server. I use EclipseLink for persistence. Since the access is read-only and the data doesn´t always need to be fresh, I thought I could speed things up by using an embedded DB (H2) that can be synchronized to the remote server when and if the user wishes to. The problem is, I don´t have a clue how to go about it.
What I came up with so far, is to execute mysqldump, make a dump of the remote server and execute the resulting SQL script locally. This is surely far from elegant, so: Is there a patent solution for this task?
Well, 50 tables possible have a considerable amount of relations, this can be tricky... As far as I know there is nothing that automate this for you or something like that. Very possible that you will have to create your own logic to that. When I did something like what are you trying to do I used the logic of "last update", like, the local data have the timestamp of the time it was last synced with the remote, and the remote data have the timestamp of the last time the data was updated there (himself on the table, or even a relation to it like a One-To-One). Having that data, every time the local user enter a part of the system that can be outdated, the client connect to the server and check if the last update timestamp is bigger that the local synced timestamp, if so, it updates the full object and relation. I consumed some time to develop but at the end worked like a charm. There may be some other way to do it, but this was the way I found at the time. Hope it helps you with your problem.
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?
I'm having two main code design problems in my app.
My app mainly consists in sending ssh commands to a remote host.
Right now I have a separated thread (singleton) which gets messages through the handler which specifies which is the next command to be sent, or the username/password/ip (kind of messy but works...).
This approach works good for unidirectional commands, but I'm planning to make it bidirectional which I don't know how to implement. As far as I know Android doesn't allow to change UI elements by another thread so a listener pattern wouldn't be it.
Also, I just read that we shouldn't save things in the application object, which is also what I'm doing by saving whether my app is running full or lite mode... I don't know where should I save it in order to not make it obviously hackable (sqlite-SharedPrefs are easily editable...)
Only a general hint: There is Activity.runOnUiThread() to execute code (later) on main thread.
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.