2

I've been struggling with something recently and I can't move forward until it is properly handled. Here is my problem:

Description

I've been using a bluetooth inside my activity for a while now. I use it to communicate some data to a remote device. This communication is the most important part of my project since it sends and receives actions which modifies the user interface and possibly changes the configuration. I keep a UI-less fragment to contain the adapter. The adapter is created once when the fragment is itself created. Afterward, the fragment bypass the adapter creation if it already has an instance of it.

I do something like this:

BluetoothFragment.java:

public void onCreate(Bundle savedInstanceState) {

    Log.i(TAG, "Created");
    setRetainInstance(true);

    if(adapter == null) {
        Log.e(TAG, "Creating a new bluetooth adapter");
        adapter = new KBluetooth(new Messenger(mHandler));
    }

    super.onCreate(savedInstanceState);
}

@Override
public void onAttach(Activity activity) {
    super.onAttach(activity);

    // Checks if the attaching activity implements KBluetoothCallback
    try {
        mHandler.setCallback((KBluetoothActivities) activity);
    }
    catch(ClassCastException castExc) {
        throw new ClassCastException(activity.toString() + " must implement KBluetoothCallback");
    }
}

Why I use this kind of implementation? because I don't want the Bluetooth adapter to reinitialize after a configuration change. Everything works fine until I press home button and come back to the activity. From that point, the fragment recreate a new adapter which means the adapter was null when the onCreate was run. I know it because I receive an error message in the log before creating the adapter.

My conclusion:

So here is my conclusion: even though the fragment is destroyed on a configuration change, my adapter is kept alive and instantiated but when the user press home, the fragment garbage every variables it contains. Am I right on that?

Question:

I need to keep a grip over the Bluetooth adapter even though the user is off the app. Anybody knows why this happens, or is there a user friendly way to avoid that kind of situation? In the case it isn't possible for me to avoid the data being destroyed when home is press, is there a way to distinguish between home and orientation change so I can safely disconnect the Bluetooth?

Note that the user can still back press and end the Bluetooth connection there, which is fine to me because he specifically said "I don't want this app running anymore".

Thank you in advance for your help. If you need more specifications, error messages or other stuff, feel free to ask.

  • Thanks for one of the most detailed questions I've read in a long time. I can probably give you an answer but it will require a bit of back-and-forth to work out your exact scenario. Are you contactable? Hangouts or #android-dev IRC on freenode perhaps? – Simon Oct 29 '14 at 21:03
  • @Simon It might not be possible since it is a work process and is maintained inside a restricted perimeter. But if you could redirect me to a ressource that could help, I would be very happy. What is your idea? what could help me retain instance of object over fragment destruction? or check if home is pressed? Thank you for your futur help. – Michael Fournier Oct 30 '14 at 12:21

1 Answers1

2

After a deep look inside the fragment lifecycle and how the app was managed in the background, I've come to this: how in the nine hells is a home button supposed to kill the application and fragment within it. Shouldn't the os keep it alive for futur use? Here is what I found.

Answer:

The fact that app was killed on home press rang me a bell. It is not supposed to be that way. After a while, I just realized there is an option in the developer settings where it specify to kill activity right when the user leave it, which we are when we press home button. I just turned it off.

Still there is something wrong with this option. Wierdly, the fragment in which my adapter lived was still alive when I looked up for it in the activity creation, even though my app was "killed".

Anyway thank you all.