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

前端 未结 2 406
名媛妹妹
名媛妹妹 2020-12-21 03:40

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 platfo

相关标签:
2条回答
  • 2020-12-21 04:00

    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.

    0 讨论(0)
  • 2020-12-21 04:13

    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!

    0 讨论(0)
提交回复
热议问题