Logic code reuse between apps for Android and other platforms: To ContentProvider or not to ContentProvider?

I'm developing an app which I want to make available both for Android and Blackberry (possibly to JavaME in the future). The business logic will be common to all the platforms - and hence, so will the corresponding layer in code.

But I also have a data layer - which will obviously be different to the various platforms. My approach to this is to have a bean and an abstract DataStore class. If I were using Android's NotePad sample, it would look like this:

Note Bean:

public class Note {
    private long id;
    private String title;
    private String note;
    private long created;
    private long modified;

    //Appropriate constructors
    //Getters and Setters
}

DataStore Interface:

public interface NoteDataStore {
    public boolean deleteNote(long noteId);
    public boolean addNote(Note note);
    public List<Note> listNotes();
    public boolean editNote(long noteId, Note note);
    public List<Note> search(String searchString);
}

Every platform would implement the datastore interface and perform the persistent data access as appropriate. The Android implementation, for example, would use SQLite classes for this purpose.

This way, the higher level "layers" would be common between all the platforms - as long as they do not use any platform-specific features.

Question:

Doesn't the functionality of the DataStore above (partially) overlap with that of the ContentProvider in Android? I thought of various approaches to make this "cleaner" but I'm not convinced with any of them:

• Have my ContentProvider also implement the DataStore interface. But, doesn't this clutter the ContentProvider, not to mention "mix up" the responsibilities?

• Implement SQLite access in the ContentProvider - and then have the DataStore implementation "call" the ContentProvider under the covers. But, what about the overhead of an additional layer? Plus, I would still need to use the ContentProvider directly, for example to use the Android Search Framework. Isn't that like duplicating the same functionality in multiple layers?

• Inverse of the above approach - i.e, implement the SQLite in the DataStore layer; and then have the ContentProvider call to it under the covers. I cannot think of how this is any diffe开发者_StackOverflow中文版rent from the previous approach.

Bottom line is - if it wasn't for ContentProvider - just the DataStore layer would work fine and this design would make the business logic reusable across platforms. The only reason I cannot entirely discard the ContentProviders is certain components of the Android system expect you to expose data as a ContentProvider (Search, for example).

I would appreciate any tips on how you have handled this in your apps. Thanks in advance.

EDIT:

Not many responses so far. Any tips at all on code reuse between various platforms? Or perhaps, I need to re-phrase my question? (I'm sorry - I'm new at SO. Not sure what the protocol is for "reminders").

The business logic will be common to all the platforms - and hence, so will the corresponding layer in code.

The vast majority of your code will be different between Android and your other versions. Blackberry and J2ME share a few dozen classes with Android, mostly in java.io and java.util. Even your "business logic" will need classes outside of the intersection of the three class libraries, most likely.

Hence, I wouldn't worry one lick about trying to have a common code base. Common design, sure. Interchangeable data models, sure. Actual literal code, not worth worrying about, IMHO.

Doesn't the functionality of the DataStore above (partially) overlap with that of the ContentProvider in Android?

The APIs overlap in terms of actions. That's about it.

The only reason I cannot entirely discard the ContentProviders is certain components of the Android system expect you to expose data as a ContentProvider (Search, for example).

True, but in those cases, "the Android system" will not be supporting your data model, anyway. Search, for example, requires a fairly specific ContentProvider implementation, not just any old one.

This question has now moved beyond the ContentProvider point and into more general territory. I did implement what I had posted about in the original question using the second bullet point - i.e,

Implement SQLite access in the ContentProvider - and then have the DataStore implementation "call" the ContentProvider under the covers

However, as I proceed, I see more such challenges in trying to keep the code common. A few examples:

1. java.util.List not available on Blackberry and JavaME platforms. The only work-around is to use arrays or Vectors. How much of a hit is it to use Vectors in Android?

2. Libraries for binding POJOs to XML/JSON do not work well on JavaME/BB platforms. Some of these libraries make use of reflection (GSON), while most of them use annotations, or at least java.util.List. None of which are available on JavaME. Hence, it is best to write the XML/JSON parsing/framing logic for these platforms by hand. That begs the question - once the effort has been put in to write such a parser, why not reuse it on Android as well?

3. JavaME/BB do not support Generics. While this is not much of a "problem" as such (since all my code is internal - not an API), I will either see too many warnings in Eclipse, or have too many @SuppressWarnings("rawtypes") in my code!

Well, well. Looks like what I set out to achieve and assumed to be a simple task is much more complicated after all!