6 Replies Latest reply on May 9, 2016 12:32 AM by baublysb

    The loss of a piece of code

    baublysb Level 1

      On the desktop I keep a picture in the Local Storage in Base64 (Figure 1), then I pull it out and displayed (Figure 2) - everything is OK.

      When this application builds in PhoneGap, then I see what type of images are not saved and the picture, respectively, does not appear (a lost fragment is highlighted in Figure 3).

      If I manually add the missing piece

      image/png;

      the picture is normally displayed.

      What makes Phonegap with JS, it occurs - is unclear because Project Code for Android is not available.

      Why is this happening and how to solve the problem?

        • 1. Re: The loss of a piece of code
          kerrishotts Adobe Community Professional

          I'm not sure exactly what the problem is, but a few thoughts:

          • Are you saying that when the image doesn't appear, the string starts with "data:base64,"?
            • If yes, I see no mechanism for this actually occurring short of some code within your app that's stripping this portion. If no, please show what the string looks like when the image doesn't load.
          • I'd advise against storing anything important in localStorage. localStorage is not persistent and can be cleared by the operating system.
          • I'd advise against base64 in general. I'd suggest using the file system. (You can display images using "cdvfile://localhost/persistent/path/to/image.png"). Base64 will always take up more space, and localStorage is already extremely limited (5mb).
          • You mention that the project code for android is not available -- if you don't have any access to the source, you're going to be a bit stuck (especially if this means you also don't have access to the signing keystore). If you have the APK, You should be able to extract the "www" portion from the APK (rename to .zip, then unzip), and then create a new project for the contents.
          1 person found this helpful
          • 2. Re: The loss of a piece of code
            baublysb Level 1

            Thanks for the reply, kerrishotts!

            Are you saying that when the image doesn't appear, the string starts with "data:base64,"? If yes, I see no mechanism for this actually occurring short of some code within your app that's stripping this portion.

            Yes, in line base64 "data:image/jpeg;base64,/9j/4AAQSkZJRg ......." missing piece of code "image/jpeg;", ie line looks like this: "data:base64,/9j/4AAQSkZJRg .......".

            Here is a fragment - "actually occurring short of some code within your app that's stripping this portion" - I'm not really well understood. GoogleTranslator and MicrosoftTranslator translated me something funny Please tell me the same thing in other words.

             

            I'd advise against storing anything important in localStorage. localStorage is not persistent and can be cleared by the operating system.

            However, this mechanism is used, and I want to understand why it does not work properly in this case.

            You said that the Local Storage can be cleared by the operating system.

            It is interesting in any case Android can clear the Local Storage?

             

            I'd advise against base64 in general. I'd suggest using the file system. (You can display images using "cdvfile://localhost/persistent/path/to/image.png"). Base64 will always take up more space, and localStorage is already extremely limited (5mb).

            You are against base64 and storage of information in the file system. I agree with you that the information in base64 larger 30 percent but storage Local Storage is a platform-independent solutions.

             

            If you have the APK, You should be able to extract the "www" portion from the APK (rename to .zip, then unzip), and then create a new project for the contents.

            Indeed, apk-file is opened using 7zip, thank you!

            Nevertheless, I all the same do not understand why the type of image disappears from the base64-line

             

            Here is the address of the project.

            You can download a project, open the index.html on your computer, download any picture and by clicking on the link to view the contents of the page index3.html ImageEntryName recording. You will see that line starts with "data: image".

            If you install on your android file PGBuildApp-release (10).apk and do the same operation, you will see that line starts with "data: base64".

            • 3. Re: The loss of a piece of code
              kerrishotts Adobe Community Professional

              Yes, in line base64 "data:image/jpeg;base64,/9j/4AAQSkZJRg ......." missing piece of code "image/jpeg;", ie line looks like this: "data:base64,/9j/4AAQSkZJRg .......".

              Here is a fragment - "actually occurring short of some code within your app that's stripping this portion" - I'm not really well understood. GoogleTranslator and MicrosoftTranslator translated me something funny  Please tell me the same thing in other words.

               

              I was just trying to think of any reason why the mimetype might be missing, and was coming to the conclusion that your code must be stripping it out somehow.

               

              BUT, I've read up on it a bit more, and it turns out that the mimetype can be missing if the browser is unable to determine the type of file being imported. This seems to be a browser-specific issue on some devices, and so my suggestion is that you start using the Crosswalk Plugin (https://www.npmjs.com/package/cordova-plugin-crosswalk-webview) when you build your app to see if that alleviates the problem.

               

              [Or use an alternative plugin that allows the user to select images and send them to the app. The Camera plugin (https://www.npmjs.com/package/cordova-plugin-camera) and Image Picker plugin (https://www.npmjs.com/package/cordova-plugin-imagepicker) might be useful to you.]

               

              Unfortunately, there seems to be no real alternative that I can see if the browser insists on not determining the file type. You could make an assumption or inspect the initial contents of the file, but that's probably not ideal.

               

              However, this mechanism is used, and I want to understand why it does not work properly in this case.

              You said that the Local Storage can be cleared by the operating system.

              It is interesting in any case Android can clear the Local Storage?

              Your particular problem isn't something specific to LocalStorage -- you'd have the issue using any storage mechanism.

               

              Here's the thing, though, `localStorage` is not persistent, and the OS is free to nuke it whenever it pleases. iOS does this whenever the device is running low on space. I'm unsure if Android treats it in the same manner, but it would not surprise me if Android does at some point, if not already.

               

              Of course, if you're planning on making an app that works on both iOS and Android, you'll have to to switch storage mechanisms anyway due to iOS's proclivity to clear localStorage.

               

              You are against base64 and storage of information in the file system. I agree with you that the information in base64 larger 30 percent but storage Local Storage is a platform-independent solutions.

              To be clear, I'm not against using the file system for data storage. That's what the File API is for, and it does a good job at it.

               

              My point is several-fold:

               

              • Device storage is already limited on user devices. Since space is at a premium, this makes base64 a poor choice when there are better ways to store said data. For example, the File API works with binary files quite nicely. There's very little reason to use base64 in this manner.
              • localStorage is not really platform independent. Again, iOS is free to delete the information at any time, and I would expect Android to do so in the future if it doesn't already.
              • localStorage is a poor storage medium. It's terribly slow and can only store strings. It's also extremely limited -- 5mb. That's 17 300kb JPG files. Not a lot, in my opinion.

               

              I hope that helps!

              • 4. Re: The loss of a piece of code
                baublysb Level 1

                Thank you, @kerrishotts!

                my suggestion is that you start using the Crosswalk Plugin

                • Increased APK size (about 17MB)

                No, the size of my apk-file is only 200 kilobytes and I do not morally ready to make it harder to 100 times.

                 

                 

                 

                Unfortunately, there seems to be no real alternative that I can see if the browser insists on not determining the file type. You could make an assumption or inspect the initial contents of the file, but that's probably not ideal.

                I decided to task, but with the help of a crutch :-) Changed index2.html code

                Here I crop the first 5 characters "data:", then add "data: image/jpeg;" and limited the permissible types of pictures one - jpg - for size reduction.

                 

                BUT, I've read up on it a bit more, and it turns out that the mimetype can be missing if the browser is unable to determine the type of file being imported. This seems to be a browser-specific issue on some devices

                 

                It is interesting. You have saved the link? I would like to make sure that it is really in the browser rather than in Phonegape.

                I read File API and https://mimesniff.spec.whatwg.org/#parsable-mime-type now but I do not interfere with a very good knowledge of the English language.

                 

                Here's the thing, though, `localStorage` is not persistent, and the OS is free to nuke it whenever it pleases. iOS does this whenever the device is running low on space. I'm unsure if Android treats it in the same manner, but it would not surprise me if Android does at some point, if not already.

                I have not seen the articles that the OS can freely release the Local Storage. Could you provide a link to one of them ?

                 

                File API works with binary files quite nicely. There's very little reason to use base64 in this manner.

                that's what they write about it here:

                readAsBinary () method provides a web application to read binary data , although it inserts this data in several awkward text string , which is not particularly efficient. And if you still want to deal with these data , then, for this you will have to suffer with extremely confusing code.

                readAsDataURL () method provides an easy way to capture the image data

                 

                 

                localStorage is a poor storage medium. It's terribly slow and can only store strings. It's also extremely limited -- 5mb. That's 17 300kb JPG files. Not a lot, in my opinion.

                Sometimes this is enough. For example, one picture with a map size of 300 KB and a number of lines with the coordinates of 100 characters in length each . If very roughly calculate that 5 MB of storage is enough for 50,000 points ! And the speed of reading the data would be sufficient .

                • 5. Re: The loss of a piece of code
                  kerrishotts Adobe Community Professional

                  No, the size of my apk-file is only 200 kilobytes and I do not morally ready to make it harder to 100 times.

                  Sometimes there is no choice. For your and your user's sanity, I highly suggest installing Crosswalk. There is an option that can use a shared Crosswalk library, but I've not played with that.

                   

                  It is interesting. You have saved the link? I would like to make sure that it is really in the browser rather than in Phonegape.

                  No, I don't have the link ATM -- I just Googled around. Pretty sure it's not a problem with PhoneGap -- the stuff I found indicated it was an issue with the browser from a specific manufacturer. That's why I suggest Crosswalk -- you have a consistent Chrome environment across all targeted platforms, regardless of manufacturer.

                   

                  That said, a missing mime type could always be a potential issue in any browser -- if the mime type can't be determined, the mime type portion of the data URI will be blank. In that case, you'd have to reject the file -- sniffing the file type is fraught with difficulty and security issues.

                   

                  I have not seen the articles that the OS can freely release the Local Storage. Could you provide a link to one of them ?

                  See Don't Assume localStorage Will Always Work In Your Hybrid App

                   

                   

                  that's what they write about it here:

                  readAsBinary () method provides a web application to read binary data , although it inserts this data in several awkward text string , which is not particularly efficient. And if you still want to deal with these data , then, for this you will have to suffer with extremely confusing code.

                  readAsDataURL () method provides an easy way to capture the image data

                   

                  I have no idea what they are talking about, and I've the sense they are flat-out wrong. Storing data in a binary form is far better than in a base64 string method, especially when using the File Plugin (https://www.npmjs.com/package/cordova-plugin-file). Some useful documentation: GitHub - apache/cordova-plugin-file: Mirror of Apache Cordova Plugin file

                  1 person found this helpful
                  • 6. Re: The loss of a piece of code
                    baublysb Level 1

                    kerrishotts написал(а):

                     

                     

                     

                    See Don't Assume localStorage Will Always Work In Your Hybrid App

                     

                    I have no idea what they are talking about, and I've the sense they are flat-out wrong. Storing data in a binary form is far better than in a base64 string method, especially when using the File Plugin (https://www.npmjs.com/package/cordova-plugin-file). Some useful documentation: GitHub - apache/cordova-plugin-file: Mirror of Apache Cordova Plugin file

                     

                    Thank you, it is helpful to my mind! I will read it including links inside.