Hey Mark! How are you doing?

hello!

I'm doing OK, and you?

I'm doing fine, thanks!

how can I help you today?

I am here to continue the discussion we had last week, not sure how much you remember about the QuestionAnswer Horizontal recycler view..

OK, I have the transcript up from that chat

I heeded your advice on removing the inner recycler view, and made it work with a ScrollView and LinearLayout..

hopefully, you are happy with the result!

Yes, but it did bring up some problems with it. Which is why I am here to take a bird's eye view on the approach again. You mentioned in the last chat, and I am quoting you, "off the cuff, I am not a huge fan of the horizontal RecyclerView as the outer container -- I would prefer the questions be individual fragments with traditional navigation"

May I ask if you are referring to a ViewPager in this case, when you say traditional navigation?

were*

that is one possibility

particularly if you really really really want the horizontal swiping bit

what I suspect that I meant at the time was just plain old FragmentTransactions

"traditional navigation" means using the BACK button (or up affordance in a toolbar) for traversing backwards, rather than swiping

Yes, that part is a dealbreaker, the horizontal swiping gives the user the ability to swipe back and change an existing answer choice..

Ah, I see

to me, with swiping, you are implicitly saying that you want users to go back and change an existing answer choice -- with BACK navigation, you are saying that the users *can* go back and change an existing answer choice, without an implication that it is something that you want to happen

I do not know enough about your app, its audience, and its intended use to know how important for users it is to go back and change answers

I guess I wanted to see my options for achieving that desired behavior, without adding much complexity, now I am not sure what benefit Viewpager+Fragments give me over the Horizontal Recycler view and scroll view

Makes sense

let me take a question from ansh, and I will return to you shortly

ansh: hi! welcome to the chat! how can I help you today?

Hello everyone.Hi mark sir

I don't have many doubts, mainly checking how this chat thing work. I was recently working with camera Api and i had a small question about that

I can try to help, though the camera APIs are very complicated, and I stopped working with them directly a few years ago

oh alright

So if i want to use system camera to get a picture, i can totally get it without declaring any camera permission or a file provider, right? but all i would get is the blurred, thumbnail version

oh, by ACTION_IMAGE_CAPTURE?

then yes, you do not need permission

yes

if you want a full-size image, FileProvider is definitely the best solution -- otherwise, as you noted, you will get a thumbnail

how blurry that thumbnail is will depend on the camera app, the user, and whether their camera lens is smeared :-)

yes about that. I will also have to provide a write permission?

if you are using FileProvider, in the ACTION_IMAGE_CAPTURE Intent, you will need to add FLAG_GRANT_WRITE_URI_PERMISSION

this sample app shows how to do it: https://github.com/commonsguy/cw-omnibus/tree/F...

it is covered in *The Busy Coder's Guide to Android Development*

from what i understood from the docs and the book, i have to first create a temporary file , pass its uri as an extra and when the cameraActivity captures the image, it writes the content to that file, and my activity gets a trigger in onActivityresult, right?

you do not need to create a file, in terms of actually creating something on the filesystem

in Java, creating a File object does not create the actual file

but otherwise your description is fairly accurate

oh ok. So the system is not actually creating the file, just the file object

so my problem is mainly with the result part

your app is creating the File object, which you use with FileProvider to figure out a Uri that will point to the same location -- we pass Uri values, not File objects, to other apps with ACTION_IMAGE_CAPTURE

yes precisly, i just understood that a few minutes before coming here ^_^!

When we got the trigger in the onActivity result, we do not have to check for extras this time, and check back on the content uri we previously passed into the calling intent , right?

correct, or the File object, if you held onto it

in my sample, I pass the Uri along to another app in an ACTION_VIEW Intent, but you could load the image itself using Picasso, Glide, or another image loading library

yes,and There can also be a scenario where the image we recieved is very large. So that calls for a compression algo

oh, right! i vould have used that!

well, the image will already be compressed -- most camera apps save JPEG images

you may need to crop the image or scale it down, but that is not compression

let me take another question from Anshul, and I will be back with you in a little bit

Anshul: back to you! do you have another question?

i was mainly getting confused at the decoding part... on the developers site, they have a special section on decoding the bitmap and i was not getting that. I forgot i could use these libraries too haha

(yes, I strongly recommend an image-loading library)

(Thankyou. I am almost done. I also found a small error i believe in the official android docs. where should i report that?)

ansh: search https://issuetracker.google.com to see if it has already been reported, and if not, click the "Create Issue" button there

I am now realizing that the question is more abstract that I thought in my head, but I just want to know benefits of switching over to Viewpager+Fragments over the current setup of horizontal recycler view, there are still parts in my current setup where I am hazy on the details, like how would I save the selected answer state and populate it again if user swipes back, I think Viewpager+Fragment provide better functionality for that, but I am not sure. Thoughts?

Oh ansh: You probably already know this, but there's a new CameraX library in Jetpack! Might be worth checking out

IMHO, working with RecyclerView items that have user-modifiable widgets (EditText, CheckBox, RadioButton, etc.) can get tricky when items get recycled

anshul: yes I have heard. would be soon checking that. thanks

the fragments+ViewPager approach IMHO has a cleaner setup for that sort of state mangement

but there are plenty of people who have user-modifiable widgets in RecyclerView items, so you can make it work

you might also wish to peek at ViewPager2, which I have not had a chance to examine yet, but is supposed to be a ViewPager-ish setup on a RecyclerView base

I see, thanks, I want to give it a try. For the radiobuttons setup though, how do I populate them according to the number of items present in List<Answer>? Is for loop the only option to add radio buttons dynamically?

in our last chat, you indicated that there was a fixed maximum number of answers -- in that case, I would just have all of them in the layout and toggle the visibility of the views for the unused answer "slots"

IIRC, you were using data binding, so you would data bind not only the text in the RadioButton but its visibility, based on whether that answer is needed for this question

Yes, that is correct, so each item in List<Answer> would populate 1 Radio button, until there are no more items, and the rest of radio buttons have Visibility.GONE

yes

okay, thanks, Mark!

OK, we are running out of chat time, so if either of you have any more questions, go ahead!

No questions from my side, sir. have a Good Day!

you too!

We actually have night here , hehe.

I am good Mark, thanks! Have a good day!

you too! (or night, or other suitable day-unit!)

:D