Open-event-droidgen: No images are being loaded except for in the spashscreen

[mahikaw]

Actual Behaviour
The speaker images and the logo aren't being loaded.

Expected Behaviour
Since the images are there in the JSON files, they should load in the app too.

Screenshots of the issue

Where-ever possible add a screenshot of the issue.

Would you like to work on the issue?

Yes.

Target Milestone to solve the issue

Till which milestone will you be fixing the issue?
https://github.com/fossasia/open-event-android/milestone/26

[mahikaw]

Same is happening with other standard FOSSASIA samples as well. For instance, the sponsors images aren't loading apart from speakers and logos.

[iamareebjamal]

Can you see if the image requests are being made in Stetho please?

You could also log the image URL picasso is trying to load to see if there is error is in parsing or something else

[mahikaw]

Sure, @iamareebjamal. I'm testing and creating issues as of now. Then I will get to solving them and so I will look into Stetho :)

[Shailesh351]

I think reason behind this is images are not cached and may be internet is not working on device

[mahikaw]

Oh, in that case @shailesh351 , could you please check out some of the apks? the zips are available in the open-event repo. Specifically, FOSSASIA 2014 and 2016

[iamareebjamal]

@mahikaw Just confirm if your internet is working and image must load. If not, we can say that that's not the case

[mahikaw]

@iamareebjamal According to me the net is working. As I mentioned earlier to @Shailesh351 it will be nice if someone can confirm. Specifically 2016 and 2014 samples.

[iamareebjamal]

@mahikaw Is it related to the naming error of image folder?

[mahikaw]

@iamareebjamal no. That is different. I am looking into this issue right now. :)

[Shailesh351]

@iamareebjamal @mahikaw issue is there i am also facing it.

[Shailesh351]

@mahikaw Problem is that in samples images are stored in images/speakers folder which are not added in assets folder while generating app.
And url for speaker's image is like /images/speakers/HongPhucDang_1.jpg which is not valid url. So picasso is not making network call for it and image is not loaded

Same for sponsors

[iamareebjamal]

Yeah I guessed so @Shailesh351

[arp95]

@Shailesh351 @iamareebjamal actually the images arent rendered from images folder. we are providing a url using google storage api to render the image.

[iamareebjamal]

Yes, but the sample events didn't have those links making it load nothing. This is an issue, the images must be loaded into apk drawable-nodpi so that they can be referenced from the app

[iamareebjamal]

Or every sample must conform to a full link description of those images so they can be loaded fro, git server, but it not a flexible solution, more so a hack

[arp95]

see the current process should be fine because of the following reasons:

1: If we include the speaker images into the drawable folder we are increasing the apk size which we dont want. By default the server provides an storage api with the help of which we can load speaker images using Picasso.

2: As by default when we create an event we get a json response like that. i think its not an issue.
Now coming over to the smaple part which we have to create we can do a temporary solution which can be used for development right now.

[iamareebjamal]

@arp95 Is there a use case where the JSON payload provided by user will only contain local image links and not URLs

I think so, and then our fix won't work.

What I'm trying to say is why adding local photos to samples if they won't be used?

[arp95]

@iamareebjamal
sorry for misunderstanding you earlier. yes this is what i am trying to say, why add local images if not used at all.

[iamareebjamal]

@niranjan94 Is there any plan for the use of images? Because local paths won't get resolved in the app

[niranjan94]

@iamareebjamal the generator can upload the images from the zip to a cloud storage server and replace local paths with a remote URI.
Or the app could be modified to accept either asset locations or remote URL. In that case, we could keep the images in the assets folder. Picasso accepts URI in the form of file:///android_asset/image.png right ? Would that work ?

[arp95]

@niranjan94 we are trying to use the uri '/images/speakers/abc.png/' but that doesnt work
in fact when we try to see the image path it comes out to be a storage api link? is that correct?

[iamareebjamal]

@niranjan94 Yes the second option is viable but it will greatly increase the size of application ~ 22 MB or more for a medium event with about 30 speakers

@arp95 I think samples or any JSON payload isn't connected to storage API because it can be generated from any open event server, not necessarily eventyay

[arp95]

@niranjan94 when we create an event on eventyay and export the json from that we get the speaker photo in storage api form right?
If yes then our main question is why use local images and how to make our samples render image.

[niranjan94]

@arp95 this same discussion took place before too. The main thing is, we want the user to have to ability to either have images in the zip itself or add images as a URL. We want the user to be able to create Open Event compatible zips without using a server instance. We're trying to make a Universal Open Event format.

[arp95]

@iamareebjamal can you sepcify the uri which will work? have tried many but none loads the image.

[arp95]

@iamareebjamal you mean i can use any storage link for samples right? drive etc?

[niranjan94]

@arp95 yes. as long as it is a direct link to the resource

[iamareebjamal]

@arp95 If the user chooses to use local images, we should let them as they will know that the apk size will increase, or is there is any way we can upload the images while generating @niranjan94 ?

[arp95]

so this means we have to change the generator code to provide a way to store speaker images in the apk, right?

[niranjan94]

We can technically upload. But the generator shouldn't be doing that. All it's supposed to do is get the input from user and generate it. If user gives a zip with images, they should be part of the apk. If user gives a zip with URL then use the URL.

[iamareebjamal]

@arp95 Yes, that's correct

[iamareebjamal]

This issue is essentially #1610 @arp95

Should this one be closed @mahikaw ?

[arp95]

@iamareebjamal yes you are right. this can be closed.