Develop Reference

OrmLite inside an Android Module

I'm trying to put all the DatabaseRequests inside a module in Android to centralize all the acces to DDBB in the same place.
I'm wondering if I'm making any mistake doing that. The apps works in the right way but I'm concerned about best practices doing that.
I have an static class called DatabaseRequest where all the requests are inside, for instance:
public static void insertUser(Context context, User user) {
DataBaseHelper mDataBaseHelper = OpenHelperManager.getHelper(context, DataBaseHelper.class);
try {
Dao<User, Integer> dao = mDataBaseHelper.getUserDao();
dao.createOrUpdate(user);
} catch (SQLException e) {
e.printStackTrace();
} finally {
if (mDataBaseHelper != null) {
OpenHelperManager.releaseHelper();
}
}
}
The context param is the context of the activity that's making the request.
Is there any performance issue related with this code?
Thanks in advance ;)

No, as Gray (ORMlite creator) said in this post:
is it ok to create ORMLite database helper in Application class?
What is most important with your code is that it guarantees a single
databaseHelper instance. Each instance has it's own connection to the
database and problems happen when there are more than one (1)
connection opened to the database in a program. Sqlite handles
multiple threads using the same connection at the same time but it
doesn't handle multiple connections well and data inconsistencies may
occur.
And in your case you may have multiple connections at one time.
I can preset you my approach on how I'm using ORMlite, I have one singleton class public class DbHelper extends OrmLiteSqliteOpenHelper which takes care of creating database connection and holds all Dao fields. You will have database upgrade code there and some other stuff so consider making facade classes. In my case each facade holds one Dao object for one model class, where i keep logic for complex item retrieving (and for simple cases i just delegate it to Dao object.

Use Android Annotations with Parceler

I'm using Android Annotations in my Android Project. As implementing Parcelable is a lot of work I want to use Parceler and the #Parcel annotation.
The problem is that if I want to use the #FragmentArg annotation by Android Annotations it doesn't (for obvious reasons) recognize that the class will be generated with the Parcelable interface implemented.
I now have two questions:
Where does Parceler put the generated classes so that I could work with these? On parceler.org it is stated: "To use the generated code, you may reference the generated class directly, or via the Parcels utility class"
Is there another way to use Parceler or any library which generates the Parcelable boilerplate code with Android Annotations?
Until now my code for the Fragment looks like:
#EFragment(R.layout.fragment_faq)
public class FaqFragment extends ListFragment {
#FragmentArg
ArrayList<FaqItemImpl> faqItems;
// ...
}
The generated POJO class is annotated with #Parcel:
#Parcel
public class FaqItemImpl implements FaqItem {
protected String iconURL;
protected String title;
protected String question;
protected String answer;
protected ArrayList<FaqItemImpl> faqChildren;
// ...
}
In the generated FaqFragment_ the interesting part is:
// ...
public FaqFragment_.FragmentBuilder_ faqItems(ArrayList<FaqItemImpl> faqItems) {
args.putSerializable(FAQ_ITEMS_ARG, faqItems);
return this;
}
// ...
As you can see the generated class treads the POJO as Serializable...

One approach you can use is to let AA handle the hand-off of the Parcelable and let Parceler perform the serialization/deserialization. One nice feature about Parceler is it will handle collection serialization for you, so AA should just have to deal with a single Parcelable. This would effectively avoid any reference to generated code, besides AA's underscore class of course.
Here's what I mean:
#EFragment(R.layout.fragment_faq)
public class FaqFragment extends ListFragment {
#FragmentArg
Parcelable faqParcelable;
public void useFaq(){
List<FaqItemImpl> faqItems = Parcels.unwrap(faqParcelable);
// ...
}
}
Then when you're ready to build FaqFragment, you would just have to have Parceler wrap your List:
FaqFragment_.builder()
.faqParcelable(Parcels.wrap(faqItems))
.build();
Yes, this approach is not as nice as AA making the wrap/unwrap call for you, but it should work.
Edit:
Working with the Android Annotation team we've added Parceler support to #Extra, #FragmentArg and #SavedInstanceState annotated fields. This means the OP's desired functionality is in place. This should work:
#EFragment(R.layout.fragment_faq)
public class FaqFragment extends ListFragment {
#FragmentArg
ArrayList<FaqItemImpl> faqItems;
// ...
}

Unfortunetaly you cannot use #Parcelable objects with #FragmentArg (or other AA bundle injection annotations). Since you are using FaqItemImpl which itself does not implement Parcelable, AA cannot know how to deal with it. An (ugly) solution would be using the generated class:
#FragmentArg
ArrayList<FaqItemImpl.Parcelable> faqItems;
Actually there was an attempt to integrate parceler into AndroidAnnotations but was rejected due to some reasons.
There are plans to add Parcelable boilerplate generator into AA directly, unfortunetaly it needs more initial work.

How to redefine library functionality in project?

I have library project that implements most of application functionality, it's like a template of application. Every project that uses this library can redefine some resources, themes and so on. Main case is colors and urls to get information, that this applicatoin would show. But to redefine some code is more problematic. For example there is view that displays information from xml, but xml is different and I need to parse it differently. My current realization is like this.
public class MyView extends LinearLayout {
public setData(XmlData xml) {
//call to helpers static method to get parsed data from xml
ArrayList<Item> items = ParseHelper.getItems(xml);
}
}
So what I need is only change some logic inside ParseHelper. Now I see only one way, to redefine layout.xml to change MyView to ProjectMyView in which I'll change method setData to use another ParseHelper. But it's not good.
Maybe there is some patterns or another ways to solve this?
I think another way to use different classes from library or project is to use reflaction. For example packages in project is differs only by name (com.library.helpers and com.project.helpers) and check for class in project, if exists use it, if no use from library. But I think it will use many resources.
Can anyone share their experience?

You can make MyView as abstract, and let setData as an unimplemented method and forcing all subclasses to implement this method like this:
public abstract class MyAbstractView extends LinearLayout {
public abstract setData(XmlData xml);
}
Them, you library has an class that extends MyAbstractView with the most usual implementation like this:
public class MyView extends MyAbstractView {
public setData(XmlData xml) {
//call to helpers static method to get parsed data from xml
ArrayList<Item> items = ParseHelper.getItems(xml);
}
}
For those which want a different implementation, they just need to also extend MyAbstractView.
Finally, the caller or these objects just need to do something like this:
public void init(MyAbstractView arg, XmlData xml) {
arg.setData(xml);
}

How to extend two library class in java class android [duplicate]

This question already has answers here:
Extending from two classes
(13 answers)
Closed 9 years ago.
I want to extend two library class files in a java class.How to do this.

You have not given more details about the question.
You can only extend a single class. And implement interfaces from many sources.
Extending multiple classes is not available.
You can use nested classes or inner classes
class A extends B {
private class C extends D {
// A , B , C , D accessible here
}
}
Why Use Nested Classes?
Compelling reasons for using nested classes include the following:
It is a way of logically grouping classes that are only used in one place: If a class is useful to only one other class, then it is logical to embed it in that class and keep the two together. Nesting such "helper classes" makes their package more streamlined.
It increases encapsulation: Consider two top-level classes, A and B, where B needs access to members of A that would otherwise be declared private. By hiding class B within class A, A's members can be declared private and B can access them. In addition, B itself can be hidden from the outside world.
It can lead to more readable and maintainable code: Nesting small classes within top-level classes places the code closer to where it is used.
when to use nested classes
You can find more solutions on this link
Edit
This is an answer to you comment. You want to call method of outer class in inner class. This is an example.
class Outer {
void show() {
System.out.println("inside outter show");
}
class Inner{
void show() {
Outer.this.show(); //this is calling Outer class method into Inner class
Example e = new Example(); //create object of another class
e.show(); //call to method
System.out.println("inside inner show");
}
}
public static void main(String[] args) {
Outer o = new Outer();
Inner i = o.new Inner(); //create an object of Inner class
i.show(); //this is calling Inner class method from outside method
}
}
class Example
{
void show()
{
System.out.println("inside example show");
}
}
Output:
inside outter show
inside example show
inside inner show

Unfortunately in JAVA you can only extend a single class that means each Class can only extend one class. you can implement many interfaces but not extend.
however there are ways in which you can sort of surpass it, you can just make the libs public and then include them so you could create an instance and use their functions, you can create an inner class and use it for whatever purposes you need...
you can also create a chain of extension like:
public class A extends Activity
public class B extends A
so B will extend both...sort of
its hared to give you a working solution when we dont exactly know the issue,do you mean adding support libs? adding SDK? or really extending two classes (which is impossible straight forward).
#Aniket gave you an example of how to work around it so to speak...
hope I helped
sorry for the bad news:)

AdapterView<ListAdapter>.AdapterDataSetObserver is not resolvable to a type from an AdapterView<ListAdapter> subclass

I'm implementing AdapterView<ListAdapter> to produce an AbsListView-like class I can use with a CursorAdapter in a layout. I'm implementing this because I want to use the handy automatic data update behaviour CursorAdapter gives you; additionally, I can reuse the same adapter in a more conventional ListView elsewhere in my app.
I'm basing my class heavily on the Android source for AbsListView.
I'm having trouble with this though: in my own class, also extending AdapterView<ListAdapter>, I put this code:
class AdapterDataSetObserver extends AdapterView<ListAdapter>.AdapterDataSetObserver {
#Override
public void onChanged() {
super.onChanged();
//my update code here
}
#Override
public void onInvalidated() {
super.onInvalidated();
//my shutdown code here
}
}
Eclipse says "AdapterView.AdapterDataSetObserver cannot be resolved to a type".
I can't see that this is controlled by an import, and clearly since ListView can override this class, I would expect to be able to as well. Why isn't it visible?

The AdapterView.AdapterDataSetObserver is package private according to the javadoc. See the link here: http://www.androidjavadoc.com/1.0_r1_src/android/widget/AdapterView.html .
Thus it will not be visible outside of the package.