Develop Reference

How to prevent multiple databases from being created within Android app?

I'm relatively new to Android programming and I have little to no experience with SQL and its interaction with Java altogether, but I couldn't find the answer I was looking for either in tutorials or Google's developer pages.
I'm wondering how I can create a database in Android to store a variety of String and int variables without creating duplicate databases. I understand the schema and contract class concept presented by the development page, but I don't understand how I am supposed to call a class method so that only a single database is created (preferably at first app launch) without several instances being created.
My main question: What sort of setup is recommended to create a database that can be referenced from other classes, exists from the very first launch of the app, and remains private (although to be honest it's not a huge priority)?

but I don't understand how I am supposed to call a class method so
that only a single database is created (preferably at first app
launch)
In Android, database is created only once and then whenever you will try to perform CRUD operations and selects statements, always you will have only one database created. It's same for table(s) in database. Once table(s) are created, they won't be created again (so be careful if you'll add new columns to table during implementation if table was created before without new columns1). Moreover if user explicitly will delete application data - only in this case, database and table(s) will be created again because they were deleted.
What sort of setup is recommended to create a database that can be
referenced from other classes, exists from the very first launch of
the app
In the moment when you'll call for example getWriteableDatabase() or getReadableDatabase() database and table(s) will be created - only at this time! Only once. No more (except1. After that, whenever you'll try to attempt to read or write from / to database your database will be opened with specific permissions (read-write or read-only - it depends how which method you called) and you can perform actions.
without several instances being created.
Database is only one - it's not duplicated (physically), absolutely but when application logic is not designated correctly, there may appear multiple instances of database and this fact is not very good and usually a nightmare of many beginners with Android and SQLite.
But solution exists and it's not hard to implement -> Singleton. Design pattern Singleton is "pretty cool tool" for our goal - ensure that only one instance of database will be ever created.
Here is implementation of Singleton itself:
public class DataSource extends SQLiteOpenHelper {
private static DataSource instance;
public static final DataSource getInstance(Context c) {
if (instance == null) {
instance = new DataSource(c);
}
return instance;
}
}
1 If you added new columns to table at the time when database and table were created before (how i mentioned above the're created only once) it may cause application exception so exactly here you have to clear application data or implement onUpgrade() method.

Try using an ORM like ActiveAndroid. While not recommended for extremely complex apps, using an ORM will make using and managing a database much easier for someone without much database experience (and can make your code more readable as well).

When I did my first SQLite DB in Android, I used this site to get me trough the basics.
To answer your question, take a look at the DatabaseHelper Class. You will see that you have to specify a DB name (filename).
private static final String DATABASE_NAME = "commments.db";
Android will automatically create the DB if it's not existent (newly installed app) and will reuse it if it's there. As long as you use always the same file (and don't mess up the tables), your DB will remain intact.
Also, for security, the DB is stored in the app's data. Not accessible with a file browser (unless you are rooted). You can download the DB via adb if you really need to. There is tons of documentation on how to gets apps private data.
Hope this helps!

Thermostat to DB, OOP Design

I am attempting my first Java project (just started learning it/OOP). I have built a thermostat circuit that I can get the temperature from using a driver, and am now in the process of designing a Java program that interfaces with the thermostat and inserts the data into a mysql DB.
I'm attempting to do this properly, and so have come up with a basic UML diagram of my classes/objects and how they interact.
I plan on using a database interface class which will extend a database connection class. This database interface will insert into the DB, and the database connection constructor will create the database connection.
I will also have a thermostat class which interfaces with the thermostat itself, it will have 2 private variables, temperature and humidity. It will have the method update temp, which will update the private variables. The get temp method will be provide the interface to these private variables.
Finally the control class is composed of the thermostat and database interface classes, and will call the methods of both classes to get the temp/humidity data into the database.
UML diagram:
Do you have any thoughts? I don't know how good this design is. Is the controller interacting with the other classes in the correct way?
Thank you for your time.
X.

First, for someone that just "just started learning it/OOP" it look pretty good!
One thing that jumps out as me: It works, but seems idiomatically wrong (we don't usually do it that way) is having your DAO (data access object, "Database Interface") extend the class that creates the connection. Instead is should use this class-- or better, the result of this class, a connection.
Why? As you write more DAO classes (in this project, or others) you'll probably find that these are two separate concerns:
(1) code that deals with the temp/humidity table and related SQL and, temperature specific logic and exceptions.
(2) code that is responsible for connecting to a database and creating connection objects.
If you have a databaseInterface.setConnection(Connection c) method, you'll find that your databaseInterface class is more reusable. You can set connections from various sources, create multiple instances with different connections, inject mock connections in your test cases, etc.
These are ideas that I have learned over years and usually apply to projects with tens to hundreds of data access classes. Its not a terribly significant in a small project, but is a possible improvement nonetheless.
EDIT: Possible Controller constructor:
// My hardware interface
private Thermostat thermostat;
// My temperature DB tables interface
private TemperatureDAO temperatureDAO;
public Controller() {
thermostat = new Thermostat();
temperatureDAO = new TemperatureDAO();
// As the controller, I get to decide what connection the application uses.
temperatureDAO.setConnection(new ConnectionProvider().getConnection());
}
In this code the controller is dictating which DB connection is used, not each individual DAO.

Java design: Component, Model, Function

I have three types of objects:
Components: identified by a package and a name
Models: identified by a package and a name
Functions: identified by a name
The relationships are defined as follows:
A Component can have zero or more Model(s) [0..*]
A Model can have zero or more Function(s) [0..*]
A Function can be in one or more Model(s) [1..*]
A Model can be in zero or more Component(s) [0..*]
The natural design would be to have Component to have a set of references to Model(s) and Model to have a set references to Function. With this design I can easily navigate relationships in a top-down fashion (and easily answer queries like: "What Function(s) are contained in this Model?".
The problem is that I need more flexibility.
I would like to have something that's easily navigable to answer these kind of queries:
Given a Function name, in which Models and in turn in which Components is this Function referenced?
Given a Model package+name, in which Components is that Model referenced?
Are there Models not referenced by any Component?
I've thought of having Component, Model and Function as simple POJOs and to keep track of references between them with multiple HashMaps (HashMap<Component, Model>, Hashmap<Model, Component>, HashMap<Model, Function>, HashMap<Function, Model>) but this seems inefficient to me.
Can you suggest me something better designed?

The logical data structure to represent your problem domain is a graph, but doing so literally will not provide you the "efficient" means of answering the queries you cite as examples. It would help to know whether these queries are merely examples you've thought of out of what you imagine to be a larger set, or whether they constitute a complete specification of the requirements.
I suspect you won't like this answer, but what I think you would benefit from most here is a relational database. You can embed one that holds all the data in memory if you prefer to avoid some of the normal complication with using such a database. SQLite
is one relational database to consider, but there are many others available for use in Java.
I reach that conclusion based on your phrasing. You mention navigating the graph edges (or the aggregating relationships between the entities) in both directions. That's trivial to express in a relational model of the problem, but becomes very difficult when you use in-memory structures like the maps you propose; the former has no implied directionality to the foreign references among relations, whereas the latter can only represent unidirectional references from one entity to another.
In the relational model, you're able to express facts as follows:
There are entities called Components, that have these properties.
There are entities called Models, that have these other properties.
There are links between Components and Models, where every Model is "reachable from" any number of Components, and every Component "can reach" any number of Models. (Note that I did not write "contained within" or "owns" or any other relationship that suggests exclusivity.)
The relational model allows one to evaluate queries against these relations without any bias as to which way the links "point." Of course, the links are assertions with some meaning—likely directional, making the logical graph a directed rather than an undirected graph—specific to your problem domain, but it's your application that understands that meaning, not the database or the relational model that governs its operation.
Beyond the logical model, answering your queries as efficiently as possible will require you to specify that the database maintain some non-constraint-based indices. Some of the records can be looked up efficiently without you asking for anything special beyond integrity constraints, as the database will likely build indices on its own to aid in efficient enforcement of the stated constraints. But while it may be able to tell you quickly whether there are already any pairings between a given Component and a Model, it won't be ready to answer which Components, if any, reference a particular Model.
Requesting that the database maintain such indices is akin to you maintaining some of the in-memory maps that you proposed originally, but there's a difference in the design approaches: In your design, some of the potential queries that will emerge can't be answered at all, because the relationships won't be captured in a way that they can be navigated, even inefficiently. With the database, though, adapting to new queries is usually a matter of defining additional indices to help speed up queries over data that is already there. In other words, the database can still answer your nascent queries; it just may have to struggle in embarrassing ways to do so. Not until you define the proper indices will it then be ready to handle those queries as efficiently as the others you've anticipated.
I'll make one more point here. Using a relational database here may be overkill technically, but it is the right didactic choice. It's the kind of solution that your problem deserves. You can build something more narrow, more tailored, that provides a small subset of the database's capabilities and meets your needs, but in doing so, I think you're missing out on the larger design lesson here. You will have used your problem to learn something about how to implement a database, rather than learning about how to employ a database to model your problem. Making the latter both possible and easy is the reason the industry has made such database technology available.

The data structure that will allow you to track all of the relationships you describe in a single collection is a MultiMap. There is a discussion of Java MultiMaps in the Map Interface section of the Java Tutorials (you will have to scroll down to the MultiMaps section or follow the link and search the page for MultiMap; there is no direct anchor to that section of the tutorial). There are available implementations of MultiMap for Java:
The Apache Commons Collections: org.apache.commons.collections.MultiMap
The Google Collections Library: com.google.common.collect.MultMap
Using a MultiMap, you can create a mapping for your object types that can contain or aggregate the others:
//Associate multiple Models to one Component:
multiMap.put( componentD, modelN );
multiMap.put( componentD, modelO );
multiMap.put( componentD, modelP );
//Associate multiple Models to a Component (some different, some the same)
multiMap.put( componentE, modelQ );
multiMap.put( componentE, modelR );
multiMap.put( componentE, modelN ); //also associated with componentD
//And associate multiple Functions to one Model:
multiMap.put( modelQ, functionG );
multiMap.put( modelQ, functionH );
multiMap.put( modelQ, functionI );
You may later retrieve the Collection that is associated to any mapped key. Here is an example using the Apache Commons Collections MultiHashMapapi-doc:
Collection modelFunctions = multiMap.get( modelQ );
This approach will make it easy to traverse top-down from Component to Model to Function. But you can also make it easy to perform bottom-up traversal if you add both ends of each relationship to the MultiMap. For example, to establish the relationship between a Model and a Function, you could:
multiMap.put( modelR, functionJ );
multiMap.put( functionJ, modelR );
Because both relationships have been mapped, you can easily retrieve all of the Functions contained within a Model (as in the example above) or just as easily retrieve all of the Models that contain a Function:
Collection functionModels = multiMap.get( functionJ );
Of course this also means that if you want to break a relationship you must remember to remove both mappings from the MultiMap, but that is fairly straightforward. I hope this helps you -

Another option would be to abstract from creation and quering thus having possibility to easily optimize / extend certain implementation when it becomes bottleneck in terms of performance / ease of use.
Such interface would look like the following:
public interface IEntityManager {
// methods for retrieving entities by plain queries
Component getComponent(String package, String componentName);
Model getModel(String package, String modelName);
Function getFunction(String name);
// more specific queries
List<Component> getComponents(Function function);
List<Model> getModels(Function function);
// even more specific queries ...
}
In this way one can use this interface in the production code while providing arbitrary implementations with desired level of performance.
Now, concerning concrete implementation - there is slight difference depending on whether all Component, Model and Function instances and their relationships:
are created somewhere at the beginning of application (e.g. at the beginning of main method for desktop app or in the ServletContextListener.contextInitialised of web app) and are not changed during application execution
are created / removed / updated during application execution
Let's start from 1st case because it's simpler: one should make sure that all Component, Model and Function instances (and relationships between them) are known to instance of IEntityManager which is shared between logic using these entities. One of the most straightforward ways to achieve this is to put entity classes into the same Java package as IEntityManager implementation and make their constructors package-private thus moving creation logic to concrete IEntityManager implementation:
package com.company.entities;
public class Component {
public final String package;
public final String name;
Component(String package, String name) {
this.package = package;
this.name = name;
}
// ...
}
// similar Model and Function class declarations
public class EntityManager implements IEntityManager {
private final Map<Pair<String, String>, Component> components = new HashMap<Pair<String, String>, Component>();
private final Map<Pair<String, String>, Model> models = new HashMap<Pair<String, String>, Model>();
private final Map<String, Function> functions = new HashMap<String, Function>();
// variation of factory-method
public Component addComponent(String package, String name) {
// only this EntityManager can create instances
// so one can be sure all instances are tracked by it
final Component newComponent = new Component(package, name);
components.put(new Pair(package, name), newComponent);
}
// ... addModel, addFunction methods
public void addFunctionToModel(Function function, Model model) {
// here one should store 'somehow' information that function is related to model
}
public void addModelToComponent(Model model, Component component) {
// here one should store 'somehow' information that model is related to component
}
// ... other methods
}
Please note, that in the 1st case (all entities are created at the beginning of application) one can also use Builder pattern to create instance of EntityManager class - this will clearly abstract creation logic from usage. In the 2nd case, however, one should have methods like addComponent, addModelToComponent in the class (for multi-threaded usage of single instance of EntityManager one should consider making methods modifying it's state thread-safe).
And finally, concerning how exactly one should store relationships between entities: there is no silver bullet for efficient storing / retrieving entities with such relationships. I would say, that if one has not more than 1000 entities with not so many relationships - search in HashMap<String, Function> will be quite fast and shouldn't be a bottleneck. And if it becomes bottleneck, one should inspect thoroughly which kind of queries are used more often and which are used rarely and based on that observations tune the EntityManager inner implementation - hence the suggestion to abstract everything behing IEntityManager interface.
Concerning instance of EntityManager in application - obviously, there should be only one instance of it (unless one has very special case). One can achieve this using Singleton pattern (less preferred solution, though it may work fine for some time), or simply instantiating EntityManager at the beginning of application and passing explicit instances to classes / methods which need it (more preferred solution).
Hope this helps ...

hierarchical nested data structure in db4o (or any other oodb)

Really my question is, if I were to use a nested data structure in oodb would I be placing instance of classes within other instances in the db, or is there some sort of relational mapping that would be required.
I've been interested in OODB (Object Oriented Databases) for a year or so now. I'm a web/application developer in essence and for a while now have been noticing the severe limitations both in terms of complexity and performance of representing complex hierarchical structures such as a website hierarchy in relational models such as MS T-SQL and MySQL.
To present a quick java (pseudo-code) example:-
CLASS/DB TYPE:
public class PageObject{
public String title = "";
public String shortname = "";
public boolean published = false;
public PageObject[] pages = null;
public PageObject() {}
}
So if we started with this class, which would be capable of holding other instances of the same class in the pages array (or vector, or collection or whatever) we could eventually end up with the possiblity of having a site layout as such:-
Home
First Home Child
1
2
3
Second Home Child
Third Home Child
Looking at this we can see that the Home item would have 3 items stored in it's pages collection, with the First Home Child item within this collection having a further 3 items in its own pages collection.
If we were to then store this structure in DB4O (or any other OODB) would this present problems in terms of performance, in that any calls for top level objects such as the homepage would also return ALL items beneath them, assuming the database grows significantly?
This question might appear quite subjective, for which I apologise in advance, but I just can't seem to wrench my head out of the relational model so am having real problems even trying to plan out any kind of data model, before I progress into further work in code.
Any clarity anyone can shed on this would be absolutely appreciated at this stage! Cheers in advance for any thoughts!

This is where OODBs are precisely a fit, when you're dealing with complex object hierarchies where tables and joins feel overkill.
db4o (and other oodbs such as Versan't VOD) do not need to use joins (as in an rdbms) and deal with the relationship between objects transparently (as defined in your object model). In essence your object model ends up being your data model or schema. These oodbms systems usually perform better than rdbms when dealing with nested structures and can even handle cyclic references.
In order to avoid loading/storing more objects than expected oodbms can work with arbitrary levels of object activation (or update) depth (for example in your example you can tell the db to only retrieve/update first level home childs). Alternatively you can configure them to wok in transparent persistence mode (as Sam suggests) where the db only retrieves or updates what you access on demand (ie. as you navigate your object tree).
More info (db4o):
http://developer.db4o.com/Documentation/Reference/db4o-8.0/java/reference/Content/basics/activation.htm
HTH
Best!
German

If your hierarchy is truly a tree, wouldn't it be better to model this using a parent relationship (sorry, I can't bring myself to use a class named PageObject):
class Page {
Page parent = null
}
? You could then find the roots by searching for all Page's that have a null Parent.
In general, you should also learn about transparent activation.
Another way that is 'semi-relational' is to define Page objects with no containment information and containment relationship objects:
class Page
class Contains {
Page container
Page contained
}
Here, pulling a Contains object out of the database at worst pulls out two Pages. You need to manage Page deletions carefully though.
PS: pardon my abbreviated Java, I'm getting too used to Scala.

Robust way to save/load objects with dependencies?

I'm writing an Android game in Java and I need a robust way to save and load application state quickly. The question seems to apply to most OO languages.
To understand what I need to save: I'm using a Strategy pattern to control my game entities. The idea is I have a very general Entity class which e.g. stores the location of a bullet/player/enemy and I then attach a Behaviour class that tells the entity how to act:
class Entiy { float x; float y; Behavior b; }
abstract class Behavior { void update(Entity e); {}
// Move about at a constant speed
class MoveBehavior extends Behavior { float speed; void update ... }
// Chase after another entity
class ChaseBehavior extends Behavior { Entity target; void update ... }
// Perform two behaviours in sequence
class CombineBehavior extends Behavior { Behaviour a, b; void update ... }
Essentially, Entity objects are easy to save but Behaviour objects can have a semi-complex graph of dependencies between other Entity objects and other Behaviour objects. I also have cases where a Behaviour object is shared between entities. I'm willing to change my design to make saving/loading state easier, but the above design works really well for structuring the game.
Anyway, the options I've considered are:
Use Java serialization. This is meant to be really slow in Android (I'll profile it sometime). I'm worried about robustness when changes are made between versions however.
Use something like JSON or XML. I'm not sure how I would cope with storing the dependencies between objects however. Would I have to give each object a unique ID and then use these IDs on loading to link the right objects together? I thought I could e.g. change the ChaseBehaviour to store a ID to an entity, instead of a reference, that would be used to look up the Entity before performing the behaviour.
I'd rather avoid having to write lots of loading/saving code myself as I find it really easy to make mistakes (e.g. forgetting to save something, reading things out in the wrong order).
Can anyone give me any tips on good formats to save to or class designs that make saving state easier?

You should definitely check serialization before using it. I don't know how it stands on Android, but for Java code, it's a known and efficient way to save objects graphs. Anyway, you can also take a look at replies to this question, which considers saving an object graph using XML.

You haven't said why you want to save/load state. If you want to protect against shutdown,
you might want to look at using Bundle and PathClassLoader along with onSaveInstanceState and onRestoreInstanceState/onCreate.