Tropical Software Observations

07 February 2011

Posted by Irregular Zero

at 1:12 PM

0 comments

Labels:

A Certain Minimal QR Scanner iPhone app

A QR Code is similar to a barcode, except it contains more information and looks like a pixellated square Rorschach test.

There are a number of free QR readers in the appstore like NeoReader and RedLaser. I especially like the scanning GUI for RedLaser, which seems more streamlined than any of the apps I have tried.

A number of these apps use the open-source ZXing ("Zebra Crossing") scanner library. The library is in Java but has a number of ports which include iPhone.

To start things off, you need to download or checkout the source. Create a new "View-Based Application" project in Xcode. Inside the iphone folder of the source, follow the README on how to include the ZXingWidget project into yours.

Pay attention to the instructions, especially the direct dependency, header search path and the fact the file with the ZXing has to be a .mm instead of .m. If it does not build, you're probably missing something. You can look at the sample projects to see how they include the widget.

One last thing before moving on to the code, put the beep-beep.aiff file from the ScanTest project into your project. This is to get audio confirmation of a scan.

Inside the sole viewController of your project:

#import "ZXingWidgetController.h"
#import "QRCodeReader.h"
#import "ResultParser.h"
#import "URLResultParser.h"
#import "ResultAction.h"

- (void)viewDidLoad {
[super viewDidLoad];
[ResultParser registerResultParserClass:[URLResultParser class]]; 
}

- (void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
ZXingWidgetController *widController =
[[ZXingWidgetController alloc] initWithDelegate:self showCancel:NO OneDMode:NO];
QRCodeReader *qrcodeReader = [[QRCodeReader alloc] init];
NSSet *readers = [[NSSet alloc] initWithObjects:qrcodeReader,nil];
[qrcodeReader release];
widController.readers = readers;
[readers release];
NSBundle *mainBundle = [NSBundle mainBundle];
widController.soundToPlay =
[NSURL fileURLWithPath:[mainBundle pathForResource:@"beep-beep" ofType:@"aiff"] isDirectory:NO];
[self presentModalViewController:widController animated:YES];
[widController release];
}

#pragma mark -
#pragma mark ZXingDelegateMethods
- (void)zxingController:(ZXingWidgetController*)controller didScanResult:(NSString *)resultString {
[self dismissModalViewControllerAnimated:YES];
ParsedResult *parsedResult = [[ResultParser parsedResultForString:resultString] retain];
NSArray *actions = [[parsedResult actions] retain];

if ([actions count] == 1) {
ResultAction *theAction = [actions objectAtIndex:0];
[theAction performActionWithController:self shouldConfirm:YES]; 
} else {
UIAlertView *alertView = [[UIAlertView alloc] initWithTitle:@"Text Found:"
message:resultString
delegate:nil
cancelButtonTitle:@"OK"
otherButtonTitles:nil];
[alertView show];
[alertView release];
}
}

The code in viewWillAppear is lifted off from the sample projects. This sets up the scanning video camera with the appropriate reader. If a scan is successful, the delegate method didScanResult will execute. The result is parsed to see if it is a URL. You set which parser to use in viewDidLoad. A parsed result can have default actions associated with it, the URLResultParser opens up the url in Safari as default. Otherwise the result is treated as text and displayed.

This app can now scan QR codes and open up URLs in Safari. There are a number of other things you can add to this, eg you can switch out the ResultParser with a UniversalResultParser that includes all the parser classes. You should take a look in the Classes folder of the ZXingWidget project to see what is available.

04 February 2011

Posted by Yasith Fernando

at 11:15 AM

0 comments

Labels: ,

Honeycomb

Google is getting ready to launch Android 3.0, aka Honeycomb, the latest version of the Android OS that is aimed at tablets. It has a lot of new goodies that will radically change the way we will design and develop applications, especially user interfaces.

After going through some articles and documents that were sourced from the Internet, I am compiling this blog post as an overview of the main UI changes introduced in the 3.0 API. And to see how this might help application developers like you and me write applications that could potentially (nobody knows for sure whether honeycomb will run on smartphones or not. But it seems to support smaller screen sizes as well. I am been optimistic here! ) run on smart phone and tablet devices. Even if this is possible it might not be a reality in the near future. As google is yet to announce any smartphones with the new branch of the OS.

Ouch! it seems that is not going to be true anytime soon: Google Says Honeycomb Will Not Come To Smartphones.

Honeycomb is the first release of the 3.x branch. Right now, Google seems to be reserving the 3.x branch for tablets and the 2.x branch for smartphones. As for the 2.x branch, Android 2.4 (Ice Cream) will be the next release. Given that maintaining two platform-specific versions of the OS doesn't seem like a long-term strategy, convergence will probably happen at some point in the future.

Fragments


This seems to be one of the most exciting new features of Honeycomb. The API documentation defines a Fragment as “...a piece of an application's user interface or behavior that can be placed in an Activity”. Fragments are basically small units or modules that can together make up an Activity. Perhaps the coolest thing is that you can change them dynamically at runtime!

Modularity is almost always good! (caveat: only if used with some common sense). You can create different layouts by mixing up Fragments. An Activity can be broken down into different regions and then designed separately. It also allows developers to create interfaces that let users choose among different layouts at runtime. Because Fragments can be added in or removed dynamically, this should be fairly easy to do.

Google has cited another use for Fragments: changing the layout of an application depending on the orientation of the screen. So you can create UIs that will make maximum use of screen space depending on the screen orientation. For example, if a given device has a lower resolution than a tablet, a developer can decide to use a Fragment (or a set of Fragments) that are designed to better fit a smaller screen size and resolution. Or, if the device that you are using has a larger, higher resolution screen, you can conditionally use a different set of Fragments or simply a different mix of Fragments to optimize the interface. I have not really tried using Fragments in a real world application, but I think they could be very helpful in making applications more adaptable to different device form factors and somewhat independent of hardware platforms. However, we should not expect this to be a perfect solution to make apps device and resolution independent, as it will involve many other considerations such as sizing and resolution of embedded image assets and other content types.

Back Stack

Fragments that are displayed one after another can be added to a stack by modifying the Fragment inside a transaction. This will help users go back to whatever Fragment they came from by using the standard back button. Such UI statefulness can greatly improve user experience.

ActionBar

One can argue that the space taken by the title bar is a waste on small handheld devices like tablets or smartphones. The action bar replaces the title bar and displays the title for a window while harbouring various other widgets, menus, and tool buttons.

Browsing through the API documentation for ActionBar, you can see some interesting classes and constants like ActionBar.Tab and NAVIGATION_MODE_LIST that suggest the ActionBar can be used for navigation and can contain embedded menus, buttons, and tabs. When used with methods such as setCustomView() to set a custom view to appear inside the ActionBar, this can be used to implement things like a search function for an eBook reader app.

A breakdown of some other highlights:
  • Multi-select, clipboard, and drag-and-drop
  • Richer notifications
  • Live HTTP streaming
  • New APIs for Bluetooth A2DP and HSP
  • Hardware accelerated rendering
    • New animation framework (new android.animation package)
    • Hardware-accelerated OpenGL renderer for 2D graphics
    • A new 3D rendering engine called Renderscript (new android.renderscript package)
  • Ability to leverage multi-core processors
  • DRM framework (new android.drm package)

Playing with the SDK
There is no substitute for playing with the SDK yourself. You can get it here. If you already have a previous version of an Android SDK installed, you can install Honeycomb via the Android SDK manager. Look for Android 'Honeycomb' Preview SDK along with the documentation bits. Have fun!

Sources
  • Android 3 Highlights - Google
  • First look: Honeycomb APIs power tablet-friendly Android apps - Ars Technica
  • Google posts Android 3.0 Honeycomb SDK preview - intomobile