Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow users to add more attachments to report a bug #22

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

hplin
Copy link

@hplin hplin commented Apr 10, 2018

screen_1523389478
screen_1523388220
screen_1523388210
screen_1523388204
screen_1523388199

@kkoser kkoser self-assigned this Apr 10, 2018
@drewhannay
Copy link
Contributor

@hplin Can you check the lint failures that Travis is seeing? It'd be good to get a passing CI build before going through this change thoroughly

@hplin
Copy link
Author

hplin commented Apr 11, 2018

Hi @drewhannay
This is due to the i18n "missing translation" issue. I am working with @kkoser to kick off translation server to provide other strings for different locales.

Copy link
Contributor

@kkoser kkoser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks ok to me, I'm not a fan of the way we use the attachment views to hold the uri data - seems like using a proper collection view with an adapter would make this cleaner. Let me know what you think.

Lets make sure to get the translation stuff figured out before we push this

@@ -121,23 +239,95 @@ public boolean onMenuItemClick(MenuItem item) {
};
}

private ArrayList<Uri> getAttachments() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we need access to the attachments, it probably makes more sense to store them as a property of this fragment so that we don't need to traverse the whole view heirarchy just to find them

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will change it to use ListView and your concern should be addressed.

return false;
}

return true;
}

private static class AttachmentViewHolder {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lets move this into its own class, seems like there's enough code here to warrant that

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK

Intent intent = new Intent(ACTION_END_FEEDBACK_FLOW);

intent.putExtra(SCREENSHOT_URI, imageUri);
intent.putExtra(TITLE, getString(getTitleResId(feedbackType)));
intent.putExtra(MESSAGE, userMessage);
intent.putExtra(USER_DATA, userData);
if (attachments != null && !attachments.isEmpty()) {
intent.putParcelableArrayListExtra(EXTRA_ATTACHMENTS, attachments);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason we need to define EXTRA_ATTACHMENTS in both the fragment and the activity?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I just follow the same logic. When delegate tried to get the bundled values, it can use the constants defined in the same class.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea makes sense, i guess these are two different semantic bundles. Sounds good!

}

private void removeAttachment(@NonNull Uri fileUri) {
for (int i = 0, count = attachmentsView.getChildCount(); i < count; i++) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may want to consider using an adapter here, since this seems like it would lend itself to some kind of list or grid...

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about that but in that case we need to use ListView (for RecyclerView we need to add the dependencies). In most of the cases, users won't add too many attachments or remove them so I think it might be fine to add/remove views from a view group.
Maybe it is easier to use a ListView in this case, I can change it later.

/**
* @return true if more attachments are allowed to be attached to the reports
*/
public boolean isAddAttachmentFeatureEnabled() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets call this something like "shouldAllowAdditionalAttachments" or something, to make it a bit more expressive of what this method indicates

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK

/**
* Make the file uri persistent
*/
static void persistFilePermissions(@NonNull Context context, @NonNull Uri uri, @Nullable Intent data) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure i understand why we need this, can you explain a bit?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we don't need this for external shared documents. This is only for if we want to share the internal files.
I will remove it

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you mean by "internal files" - this only supports files on the local disk right?

@hplin
Copy link
Author

hplin commented Apr 24, 2018

@kkoser i18n strings are completely in

Base automatically changed from master to main March 1, 2021 18:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants