I am trying to do barcode reading in HTML5/ Javascript on mobile so I can extract the barcode and post to a Ruby on Rails web service.
I am using this code for barcode reading: code by manuels which works fine (You can try out the barcode reader code here) if camera on mobile is set to a very low resolution, not at high resolution though. This method using HTML Media Capture is not ideal as user would have to switch to low resolution manually. I know one can set resolution using GetUserMedia but it's not compatible with many browser/ versions.
I am trying to resize the captured photo using a canvas, based on the canvas code here (not written by myself). The resize works as expect. I then combine the barcode reading code mentioned above in the resize function as below but the barcode reading part doesn't work.
... var interface = new Interface('./bardecode-worker.js');
interface.on_stdout = function(x) { document.getElementById('barcode').appendChild(document.createTextNode('result:
'+x)); }; ...
interface.addData(tempCanvas.toDataURL('image/jpeg'), '/barcode.jpg').then
(
function()
{
interface.run('/barcode.jpg').then
(
function() { console.log(arguments); }
);
}
)
This is manuels' original code below, and in the above code, I am trying to feed the resized image from the canvas into the interface.js instead of a FileReader:
document.getElementById('barcode_file').onchange = function(e) {
var file = e.target.files[0];
var reader = new FileReader();
document.getElementById('barcode').appendChild(document.createTextNode('running...'));
reader.onload = function(ev) {
interface.addData(ev.target.result, '/barcode.jpg').then(function() {
interface.run('/barcode.jpg').then(function() { console.log(arguments); });
})
};
reader.readAsBinaryString(file);
};
Sorry, I am quite new to javascript. Any suggestions? Or is there a better solution?
You might be interested in looking at this program which specializes in providing easier access to hardware on mobile phones.
http://bridgeit.mobi/
It installs a native app on the phone and then lets you open the app from your webpage and then passes back the scan or photo or other item.
They use a javascript library they wrote to open the app and then pass the information back to your webpage.
The library will also open the store page of the program if it is not installed the first time it a user tries to use it.
Related
This question already has answers here:
Check if file has changed using HTML5 File API
(3 answers)
Closed 2 years ago.
I have a web app, where the user can select a local file as input, using the html5 FileReader API. Is there any way I can check if the file has changed, that works in modern browsers?
Historically, this was possible in some browsers by polling the file object and comparing the File.lastModifiedDate (deprecated) or File.lastModified property, as outlined in this QA: Check if file has changed using HTML5 File API. However, the spec says that lastModifiedDate and other file data should be a snapshot of the file as it looked like when the users first selected it, so this should not work (and it seems like recent versions of most browsers indeed follow the spec now, making this hack unavailable).
I was hoping to be able to check for changes by reading the file. This kind of works, but as soon as the file is changed on disk, Chrome and Firefox throw an error saying DOMException: The requested file could not be read, typically due to permission problems that have occurred after a reference to a file was acquired. Is there any way around this?
This is what I tried:
let oldText
setInterval(function () {
const fileObj = document.getElementById('myFileInput').files[0]
const reader = new FileReader()
reader.onload = evt => {
const text = evt.target.result
if (text !== oldText) {
console.log("The file has changed!")
oldText = text
}
}
reader.readAsText(fileObj)
}, 1000)
...or simpler:
const fileObj = document.getElementById('myFileInput').files[0]
const reader = new FileReader()
reader.readAsText(fileObj) // works
// now lets edit the file and try again
reader.readAsText(fileObj) // fails
reader.readAsText() works as expected, until the file is changed, when it throws the error mentioned above. I guess this is a security measure of sorts, though I don't fully understand what it's trying to protect the user from. What can I do instead?
This will be possible again if/when the Native File System API is implemented in browsers. It will be partially enabled in Google Chrome 85, scheduled for release in October 2020.
Unlike the FileReader API it requires a explicit user interaction, so you'd do something like this:
myFileInput.addEventListener('change', async (e) => {
const fh = await window.chooseFileSystemEntries()
// fh is now a FileSystemFileHandle object
// Use fh.getFile() to get a File object
})
I've added the jsPDF library to my Titanium project to generate PDFs client side, which has been working great. But now I want to localize the app for Arabic countries, which means that I have the add a custom font. This works perfectly if you use doc.save('file.pdf'), but it doesn't seem to work correctly for doc.output(). I have to use output because I'm using jsPDF outside of a browser.
To make the library work in Titanium I've had to strip all of the references to window, because it's not running in a browser or webview.
I've tried writing the file from different sources, but nothing seems to yield any results.
My current implementation:
doc = new jsPDF();
var f = Ti.Filesystem.getFile(Ti.Filesystem.resourcesDirectory, 'fonts/markazi-text.regular.ttf');
var contents = f.read();
var base64font = Ti.Utils.base64encode(contents).toString();
doc.addFileToVFS("MarkaziText-Regular", base64font);
doc.addFont('MarkaziText-Regular', 'markazi-text', 'normal');
doc.setFontSize(20);
doc.setFont('markazi-text', 'normal');
doc.text('The quick brown fox jumps over the lazy dog', 20, 20);
var tempFile = Ti.Filesystem.getFile(Ti.Filesystem.getTempDirectory(), 'report.pdf');
if (tempFile.exists()) {
tempFile.deleteFile();
}
tempFile.write(doc.output());
I've also tried to write the file from a blob:
var reader = new FileReader();
reader.onloadend = function () {
tempFile.write(reader.result);
};
reader.readAsText(getBlob(buildDocument()));
But the pdf is empty if I use this. I've also tried the library in a webview within a titanium application, which does work but I don't really want to go that road. It would require too many changes to the code.
Expected:
Actual:
I've finally resolved it by creating a local HTML file. In this HTML file I've loaded jsPDF and my own JavaScript to generate a PDF file. I've loaded this HTML file in a WebView.
I'm generating all the data needed for the PDF in an Alloy controller. I'm sending this data to my WebView JavaScript by firing an app event and catching it in the WebView.
After the PDF is created I trigger an app event in the WebView that contains the base64 data of the jsPDF doc:
Ti.App.fireEvent('app:pdfdone', {
output: doc.output('dataurlstring').replace("data:application/pdf;filename=generated.pdf;base64,", "")
});
I finally save this as a file in the Alloy controller:
var f = Ti.Filesystem.getFile(Ti.Filesystem.getTempDirectory(), 'doc.pdf');
f.write(Ti.Utils.base64decode(e.output));
Right now, I have created an HTTP Server on My iPhone Application and have hosted HTML there. Then Accessing it on Browser of the system that is in the same network of iPhone. I can see the File on my Browser.
Now using WebSockets I am trying to send File from Browser to Application, but It's not working. It's fine with Text Message but Not in case of Data.
As a workaround, I tried it via Base64 String, but in that case also socket Get Closed.
For uploading using JAVAScript I have written this code, here I tried by sending Base64 string in fragments of size 200 characters.
function sendFile() {
var preview = document.querySelector('img');
var file = document.querySelector('input[type=file]').files[0];
var reader = new FileReader();
var rawData = new ArrayBuffer();
reader.onloadend = function () {
var stringContent = reader.result;
preview.src = stringContent;
var array = stringContent.match(/.{1,200}/g);
for (var i = 0; i < array.length; i++) {
ws.send(array[i]);
};
}
if (file) {
reader.readAsDataURL(file);
}else {
preview.src = "";
}
}
On iPhone side, I have used WebSocket Class from Libary CocoaHTTPServer
Socket closed at this line.
EDIT
After lots of trial and Error, I come to know that This is happening If I am opening this in Browser of Mac, Not in case of any other devices' browser like iPad, iPhone. This is very weird use-case but its true.
EDIT II
After lots of wondering, I found a Clue to this, This was working nicely for iPhone, iPad, iPod & Opera browsers, because they have old websocket support, i found this from here..
In this question the Guy have the reverse case, He is trying to close the connection on these browsers, in My case It's closing on other Browsers like chrome, Mozilla, etc. It's because something called Hybi formatted packets. This might help someone to suggest the solution for my case.
I think you should look at the official CocoaHTTPServer examples. There is one for http file uploads: https://github.com/robbiehanson/CocoaHTTPServer/tree/master/Samples/SimpleFileUploadServer
ws: protocol is allowed? For example config.xml
<access origin="ws://192.168.1.xx/*"/>
I've created a small test site in which you can upload a picture. And without a round-trip to the backend, the selected picture is shown. So far nothing very interesting
$('input').on('change', function () {
var file = this.files[0];
var reader = new FileReader();
reader.onload = function (event) {
var base64 = event.target.result;
$('<img>').attr('src', base64).appendTo('body');
};
reader.readAsDataURL(file);
});
However, I noticed that on my iPad3 some pictures are shown up-side-down. I found on google about EXIF metadata which is stored in the image (base64) which defines the orientation of the picture. But another thing is, that on my laptop the image are shown normal (with the same pictures of course). Is there any way to prevent/fix this behaviour from happening ? (I want them to show the picture the same way, and if possible I also want them to be shown normal (not up-side-down))
This is not a CSS issue. It's actually an issue with the image. Some browsers interpret the orientation of the image through meta data. Simply open the image in any image editing software and export it. Upload it to your server and let me know if that worked!
EDIT - Reference this URL for a possible solution:
Accessing JPEG EXIF rotation data in JavaScript on the client side
I want to use the HTML5 FileApi to read a SWF to an OBJECT (or EMBED, if it's better to do?).
My current code crashes on Chrome/Iron (the only stable browser which also supports the xmlhttprequest v2 FormData). I got it to read image data into a on-the-fly created IMG. But the object one crashes the current tab in the browser.
else if (file.type == "application/x-shockwave-flash") {
var show = document.createElement("object");
show.type = "application/x-shockwave-flash"
show.style.width = "100%";
show.style.height = "100%";
show.id = "thumb";
document.getElementById("thumbnails").appendChild(show);
var reader = new FileReader();
reader.onload = (function (aImg) {
return function (e) { aImg.data = e.target.result; };
})(show);
reader.readAsDataURL(file);
Do I really read to the object.data part? How is it done right? Anybody know? Or is this incomplete and I have to wait for better implementation?
A few things I'd recommend trying (in order of increasing complexity):
base64 encode the data with btoa and set it using a data: URI,
instead of creating the object using createElement, construct the <object> tag with all attributes as an HTML string (including the base64 advice above), then inject it into a DOM element with innerHTML,
create a reflector web service where you POST the swf content, it gives you a URL, then pass the URL off to the object,
similar to the previous, create a reflector web service where you POST the swf content, targeting a full-screen IFRAM as the target, have the service spits back an HTML doc including an <object> pointing back to the server.
The later of these options is more intense, and requires round-trips from the server that you'd probably want to avoid - just some more options you might want to consider.
ActionScript 3 has a Loader which may be useful as well. I don't know if it supports data: URI's, but if it does, you could write a boot loader SWF which runs the contents of the local swf file directly.