CODEWITHSUNDEEP
android
Joel Robinson-Johnson
Joel Robinson-Johnson

Reputation: 939

Image Loaded by glide appears then quickly disappears

I'm coding an app that takes a photo then performs a fragment transaction after saving the photo to memory to replace the original fragment (which shows a textureview and a recyclerview with the pictures currently on the phone) with a fragment that should show the recently captured image along with two editTexts. The fragment transaction commits, the new image is shown momentarily, the editTexts are not rendered on the screen at this time. The image then disappears and the two editText are rendered. I logged the file name in both fragment to see the file name was transfered from one fragment to the next, according to what I see in logcat the information was transferred. I also looked for an error message in the logcat pertaining to the glide api. I didn't see anything relating to images or glide. The code used to make the fragment transaction and load the image in the new fragment are shown below.

The code to show the image

 @Override
public void onCreate(@Nullable Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    filePath =  getArguments().getString("filepath");
    Log.i("file name 2", filePath);
}

@Nullable
@Override
public View onCreateView(LayoutInflater inflater, @Nullable ViewGroup container, @Nullable Bundle savedInstanceState) {
    View root = inflater.inflate(R.layout.dialog_new_image_post_submit, container, false);
    imageSubmission = root.findViewById(R.id.imagePost);
    tagline = root.findViewById(R.id.image_tagline);
    genre = root.findViewById(R.id.genre);
    if (!getArguments().getString("filepath").equals(null)) {
        Glide.with(this)
                .load(new File(filePath))
                .into(imageSubmission);
        Log.i("file name 3", filePath);
        Toast.makeText(getActivity(), filePath, Toast.LENGTH_SHORT).show();
    }
    return root;
}

The code to transfer the file name between fragments

public void continueToSubmit(String filename){
    Bundle bundle = new Bundle();
    bundle.putString("filepath", filename);
    Log.i("file name 1", filename);
    NewImageSubmission nis = new NewImageSubmission();
    nis.setArguments(bundle);
    getParentFragment().getChildFragmentManager()
            .beginTransaction().replace(R.id.dialog_frame_layout, nis)
            .commit();
}

The app already has the permission to read and write to files. I'm not sure why my image isn't persisting. I should also note that the xml originally used to define the layout had a constraint layout as the parent view group, when the vertical constraints on the image view are set to wrap contents (vs fixed or match contraints) the image shows, but the image covers the editText directly below it, otherwise the image doesn't show. In theory, there should have been an 8dp difference between the bottom of the image view and the top of the editText. I ended up switching the constraint layout for a vertical linear layout, hoping that would fixed things, but it didn't.

An Update

I realized the captured image appearing momentarily has nothing to do with the fragment transaction. When a picture was taken, the texture view seems to show a brief snapshot while the recyclerview disappears. When I comment out the fragment transaction, the recyclerview disappears momentarily and then reappears showing the new picture. The textureview goes back to showing the preview. So, why doesn't the image show on the next fragment when it has already been established that the file path was transferred from one fragment to the next? Could it have something to do with the file?

An Update

if statement showing log statement if file didn't exist showed no log statement. Adding a request listener to the glide object and creating log statements for failure showed nothing in the console.

Upvotes: 2

Views: 882

Answers (1)

Joel Robinson-Johnson
Joel Robinson-Johnson

Reputation: 939

In order to get the image to show in the imageview and not have the imageview obscure the edittext directly under it, I had to set height/width in terms of dp (as opposed to using match_parent or wrap_contents) while the view is a child of a constraint layout. Having the view as a child of a vertical linear layout where the height is set to 0dp and the weight is set to 1 while the height of the two edittext is set to wrap_contents didn't work for me.

Upvotes: 1

Related Questions