Upload remote images with Base64 or URL?

Asked

Viewed 864 times

0

What’s the best way to upload remote images to Android? How these great apps optimize these images?

In a country where mobile Internet is one of the worst in the world, there is a need not to leave the app user waiting too long until an image fully loads.

My initial idea was that when the application downloaded the data from the server, the content that had image, this image would not come as a URL but with its content encoded with Base64, so the user would not have to wait any second to view.

Or is it not our fault the Internet is slow and send a URL anyway?

[EDITED]

Below @Maniero asked how to upload a remote image with Base64

Answer:

With an HTTP request. On the PHP server I prepare the database data, and send back a JSON file containing data, example:

Example for a party/event app

Data from the last parties

{
    "event_name": "Nome do evento",
    "images": ["ImageURL 1", "ImageURL 2"]
}

<img src="URL">

Example with Base64, with encoded image bits

{
    "event_name": "Nome do evento",
    "images": [{
        "type": "gif", 
        "data": "SW1hZ2VVUkwgMQ=="
        }, 
        {
        "type": "png", 
        "data": "SW1hZ2VVUkwgMQ=="
        }]
}

We won it with this?

We eliminate the need to overload the server, since the already encoded image will be stored on the server, which clears PHP from coding every time.

<img src="data:image/type;base64,........">
java android

  • "It’s not our fault the Internet is slow", we really are not to blame, but the client of the application will certainly not like to wait... In this regard the question that remains is: It is important that the client does not wait for the images?

  • I don’t know if I understand, but I can try to answer. Is there a more concrete example?

  • A concrete example would be an event app that needs to display party photos, these photos are stored on the server. The development of the application itself is not a problem, but how to display images as quickly as possible yes, this is worrying me.

  • As a concrete example was waiting as you are doing. Also because the question is confused. It doesn’t make much sense to compare URL with Base64. These are orthogonal concepts. Maybe you should edit the question to explain what this means. How could you access a remote image without a URL? And why do you see the need to use Base64 and why do you think it could bring some advantage?

  • @bigown see in the example above how the data is loaded and what its advantages.

  • This is a native Android app or a web app that just happens to be used on Android?

  • @Bigown Is a mobile app that will have your data received and treated with Java (Android) and Objective-C (iOS)

  • @Daniela Take a look at [tour]. You can accept an answer if it solved your problem. You can vote for all the posts on the site as well. Did any help you more? You need something to be improved?

Show 3 more comments

1 answer

4

No image comes by a URL or with Base64. The concepts there are confused.

URL is an address and Base64 is a form of data representation. There is no dichotomy in between them.

If you are going to access remotely you will need a URL to access. I don’t know any other way to access.

If you want to know if you should bring the image in binary form or with Base64, you should bring it in binary form whenever possible. Base64 will make the data volume even bigger. Base64 is used when a binary data would create some problem for transmission or storage. And larger volumes increase load time.

If you want to know if the image should be embedded in some other data, I don’t see this as a great advantage in most cases, especially if you have to encode in Base64. Even more if you bring data that will not be used.

Decreasing the number of requests can bring some advantage or disadvantage depending on the case. If you have many elements to load it can be more interesting to load them separately, so you load them progressively. Trying to load everything as if it were an element may even be slightly faster but will create the feeling of delay.

User feeling is more important than actual speeds. Loading images asynchronously give the illusion of more speed. Loading the images individually is already an asynchronicity technique.

Even today it is common to use a technique to only upload an image when it is actually displayed. This is good on the one hand and bad on the other. The middle is to display the first images as soon as possible and leave the others that will only be displayed if the person navigates through the gallery after finishing the ones that will be shown immediately. So you control the total flow a little bit more.

According to the editing it seems that the question is whether to load the image embedded in a page or come through JSON. The second form is more asynchronous that brings the advantages I described above. Bring it by JSON, maybe even on-demand can create an illusion of more speed depending on how it is developed. The first way, if you have many images built in the HTML will be huge and take a long time to load.

If you can do neither perhaps it is better. Because both use Base64 it will increase the volume of traffic data. Unless compression is used in the transmission. This is not always available and considerably increases the server load.

But maybe the problem is not this because the example uses HTML and other information indicate that the application is native. With conflicting information I’m not sure I can answer better than this.

In this OS question have examples to load the images efficiently but do not know if this contributes to answer anything. I would just go this way. And there is this tutorial with other techniques. The official documentation talks about it. There are components who do the "dirty work" for you.

Completion

The fastest is to have the smallest image possible by discarding the use of Base64. To give the feeling of faster is to load the images slowly.

Browser other questions tagged java android

You are not signed in. Login or sign up in order to post.