Assigned
Status Update
No update yet.
Comments
ra...@google.com
I see same issue and have been debugging it.
NOTE: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.
My current workaround is to provide my own DialogFragment.show() method, like below:
public int show(FragmentTransaction transaction, String tag) {
return show(transaction, tag, false);
}
public int show(FragmentTransaction transaction, String tag, boolean allowStateLoss) {
transaction.add(this, tag);
mRemoved = false;
mBackStackId = allowStateLoss ? transaction.commitAllowingStateLoss() : transaction.commit();
return mBackStackId;
}
NOTE: It DOES NOT happen if not using support package, but use android level 14/15 library. I believe Honeycomb works well too.
My current workaround is to provide my own DialogFragment.show() method, like below:
public int show(FragmentTransaction transaction, String tag) {
return show(transaction, tag, false);
}
public int show(FragmentTransaction transaction, String tag, boolean allowStateLoss) {
transaction.add(this, tag);
mRemoved = false;
mBackStackId = allowStateLoss ? transaction.commitAllowingStateLoss() : transaction.commit();
return mBackStackId;
}
ra...@google.com
[Comment deleted]
te...@fujifilm.com
But Google pls fix this issue, as the expected behaviors must be consistent with ICS DialogFragment + FragmentManager and support package DialogFragment + FragmentManager.
It happens with both Support Package v4 r6 and v13 r6.
It happens with both Support Package v4 r6 and v13 r6.
ra...@google.com
I have this problem too.
As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.
As a workaround I use a boolean in the onActivityResult to mark the desired dialog and show the dialog in the onResume.
te...@fujifilm.com
This is definitely not a bug. There are times when onActivityResult() can be called before the Activity has restored its saved state... committing fragment transactions in these situations will simply not be remembered as a result (see this blog post: http://www.androiddesignpatterns.com/2013/08/fragment-transaction-commit-state-loss.html ).
Try moving your commits into "onPostResume()" instead as described here:http://stackoverflow.com/questions/16265733/failure-delivering-result-onactivityforresult/18345899#18345899
Try moving your commits into "onPostResume()" instead as described here:
te...@fujifilm.com
Adding a "super.onActivityResult(requestCode, resultCode, data)" call at the beginning of the method seems to fix the problem. I'm surprised than almost nobody came up with such a simple solution.
Description
We have received inquiries from customers saying that when a smartphone (Android) and INSTAX mini Link3 (Printer for smartphones) are connected via Bluetooth, they are connected under the name “LE_ATH-SQ1TW2”, which has nothing to do with Link3. (See attached image)
I have a question about the Bluetooth connection between Link3 and an Android smartphone.
[Question]
Is there any information about a problem with the connection being made under the name “LE_ATH-SQ1TW2”?
[memo]
① “LE_ATH-SQ1TW2” seems to be an Audio-Technica earphone, but we have also received inquiries from customers who do not have the corresponding earphones.
② It seems that there are several reports of similar phenomena