Showing posts with label scan. Show all posts
Showing posts with label scan. Show all posts

Wednesday, July 18, 2012

Scan line indicator for ZBar overlays

Zbar is a great tool but I often struggle with adding intuitive graphics to the overlay screens in order to clue-in the users to the fact that scanning has already begun in video mode and they just need to point their camera at a barcode. To that end, I've decided that a red colored line dragging up and down on the screen is a great way to get the point across. And the code applies to any scanning framework that lets you mixin an overlay, not just ZBar.

Wednesday, July 13, 2011

Integrating with ZBar SDK 1.1

It took only 35 minutes to get a barebones scanning app up & running on the iPhone with ZBar SDK. As far as I'm concerned ZBar is a pretty good rival to RedLaser. If you haven't done already, head over to this section in the ZBar SDK docs and try out the example which will have you singing its praises in no time.

I followed it word for word other than the fact that I used UILabel instead of UITextView.

Sunday, July 10, 2011

Integrating with RedLaser SDK 3.0.0

If you've had the chance to try out the RedLaser app on your iPhone, then you know its usability is excellent and it is simply the best technology out there when it comes to scanning bar codes. As such, you may be rightfully tempted to download their SDK and try it out for yourself.

Now even though you'll find their out-of-box documentation in the 6MB-ish download to be enlightening, you may find yourself struggling and without any instructions when it comes to getting any project of you own up & running other than their RLSample project. I must say that the ZBar folks do a much better job of documenting similar integration items for their barcode scanning SDK. I just hope that the newly released RedLaser SDK 3.1.1 build1 will offer better docs than the Redlaser SDK 3.0.0 build21 that was used at the time of writing this blog entry.

Also you may feel dubious about purchasing the extremely expensive license without first figuring out if you have the skills to take your idea all the way. And you can't get into their forums without getting a license. So, I've put together some highlights to help you grapple with the SDK and get to a point where you can perform trial & error on your own to see if you have the right stuff :)
  1. Add files to "<your project>"...
  2. Navigate to wherever you downloaded and extracted the RedLaserDevSDK-3.0.0build21
    • The naming is not set in stone, it is spelled out here only to give you a feel for what you may be looking for on your mac.
  3. Drill-down into the RedLaserDevSDK-3.0.0build21/Sample/ folder and select the RedLaserSDK directory
    • Make sure to select the checkbox to Copy items into destination group's folder(if needed)
    • Also select the bullet option which will Create groups for any added folders
  4. Just to see if you can get anything simple to work on your own, you may try to run the build after pasting the barebones code from the Using the 3.0 RedLaser SDK.pdf file included with the SDK download.
    • Here's the code to throw into a method of your choosing:
      BarcodePickerController *picker = [[BarcodePickerController alloc] init];
      // Let's keep things simple by using the default built-in overlay
      //[picker setOverlay:customOverlay];
      [picker setDelegate:self];
      picker.orientation = UIImageOrientationUp;
      [[UIApplication sharedApplication] setStatusBarHidden:YES];
      [self presentModalViewController:picker animated:TRUE];
      [picker release];
    • Ofcourse you'll need to add #import "RedLaserSDK.h" at the top where you've pasted this code.
    • But the build still won't go through because some frameworks need to be added for the build to succeed.
  5. Goto <Your Project> > TARGETS > Build Phases > Link Binary With Libraries > +
    • libRedLaserSDK.a - XCode would have probably automatically placed this in the list when you imported the ./RedLaserDevSDK-3.0.0build21/Sample/RedLaserSDK directory.
    • CoreVideo.framework - makes sense since we need to the camera is used to perform the scans. If you started with something like 24 errors, adding this will bring them down to 18.
    • Security.framework - If you started with something like 18 errors, adding this will bring them down to 3.
    • libiconv.dylib - If you started with something like 3 errors, adding this will bring them down to 0.
  6. In addition you should add an empty implementation for what happens when a barcode is successfully read.
    • Here's the code:
      - (void) barcodePickerController:(BarcodePickerController*)picker
                         returnResults:(NSSet *)results
      {
          [[UIApplication sharedApplication] setStatusBarHidden:NO];
          [self dismissModalViewControllerAnimated:TRUE];
      }
  7. With this you can at least do a test build and run in the simulator mode which will not do much other than throw up the mock scanner screen from RedLaser.
  8. If you actually try to plug in your iPhone and directly test your app on the device you will run into a whole new slew of build errors! I received a total of 22 errors. Once again, goto <Your Project> > TARGETS > Build Phases > Link Binary With Libraries > +
    • libRedLaserSDK.a - XCode would have probably automatically placed this in the list when you imported the ./RedLaserDevSDK-3.0.0build21/Sample/RedLaserSDK directory.
    • AVFoundation.framework - If you started with something like 22 errors, adding this will bring them down to 6.
    • CoreMedia.framework - If you started with something like 6 errors, adding this will bring them down to 0.
  9. Now with a lot of luck and a little bit of elbow grease, when you connect your iPhone then build & run you app, you should see it launch and have the default RedLaser full-screen camera-view-like overlay being shown. All you will see is what you camera sees, no fancy buttons ... no nothing. But given that you never actually invoked any camera/media related functionality yourself, have faith in the fact that you've cleared the first phase in your experiments to integrate with RedLaser.
  10. Before beginning the 2nd phase, I had hoped to perform a simple experiment that would turn out as described below ... but that didn't happen so until I figure that out, this is it :(
    • Remembering that there are an extremely limited # of scans allowed w/ RedLaser SDK ... take the iPhone over to a barcode and try to scan it ... given the barebones code that we've talked through thus far, all that should happen is that the camera overlay screen will just disappear after a successful scan and you'll be left looking at an empty plane white view that had loaded this stuff to begin with.

Saturday, March 19, 2011

Idea Day: Scan for shared webapp dependencies and move them to the common/lib folder

Welcome to Idea Day!
It is 6:43 AM on 3/19/2011 and its a Saturday.
Lets get cracking :)

Google search for "tomcat scan detect common jars" yielded some reading material for starters - jar-scanner and loader - but both these seemed to be get kicked-off per web-application whereas something more global is required to move jars around and thin the pack before web applications are considered at all.

Let us break-down the process:
  1. Tomcat starts
  2. Hook-in at the point where we have a list of the docBase attribute for all the web applications that will be hosted by this tomcat instance. And none of the web application specific handling has begun yet.
    1. Loop over each ${docBase}/WEB-INF/lib folder and make a list of common jars.
    2. Try to decide "commonality" based on a combination of the following factors:
      • start by doing a fuzzy match on the file name
      • then try to match the jar version in the names or if you can find it by introspecting the jar's manifest
      • and at the end confirm by doing an exact match on the file size
      • Thought: generating and comparing md5 hashes on files might yield the same results quicker?
  3. Even after the jar dependencies have been moved to common/lib folder, one might not want to expose any of the other common jars in the shared folder to their webapp. For this case, the wiki about embedding JBoss into Tomcat gives us an idea about the possibility of only having each web application refer strictly to the jars it really needs via the help of a resource scanner listener.
Possible pitfalls:
  1. There may not be a hook in the tomcat code where we have a consolidated list of the docBase attribute for all the web applications!
  2. Even if such a hook exists, it may be happening at three different places:
    1. when the application contexts defined via server.xml are processed,
    2. when the war files directly under the webapps/ folderare processed,
    3. and when the context-fragment files under conf/Catalina/localhost/ folder are processed!
  3. The user starting tomcat may not have the permissions required to move the files around.
Alternate approach:
  1. Piggyback off a resource scanner listener per application and create a list/report as each individual app comes up.
  2. Then Tomcat can be shutdown and the list/report can be acted upon by a script that runs under an admin/root account to achieve the same results as before.
  3. Starting back the tomcat server afterwards should be fine.
It is now 7:33 PM on 3/19/2011 and it still a Saturday :)
Sent an email to the tomcat users list to find out if a hook into the process exists.
Started the process of getting and building the source-code for Tomcat.