Zbar on Android with the NDK

We've had experience writing an automobile VIN (Code 39) scanner on both iPhone and Android. In the case of the iPhone we leverage the ZBar library and the Android the ZXing library. Unfortunately, Android has been a tremendous amount of work. There was a tremendous amount of fracturing with the camera drivers to code around to tune the image capture. But that's another story...

For the image processing the ZXing library on Android with was simply not as fast or accurate as capturing   Code 39 barcodes (no opinion on QR, etc.) as ZBar on the iPhone. This left an interesting customer service dilemma as Android would be subpar. We looked at a few options and settled on an interesting proposition.

Android recently introduced the NDK (Native Development Kit) that allows you to build native code from C/C++. Interesting... We realized that there was a good chance that we could get the ZBar library running on Android with the NDK (at least for the image processing). We did have to rewrite the build/make system as the NDK does not have full make/configure support. But, after investing time in this we were able to build the ZBar library on the NDK and leverage their JNI wrapper to invoke this code on Android.

So far the results have been excellent. The ZBar library on Android is 50% faster in recognition for Code 39 and a lot more accurate.

We'll be donating an example project to the ZBar project once we can remove the client specific portions.

Also, just be aware this only applies for Code 39. We have no idea how the image processing quality compares for the other formats.

How to Upgrade Test in the iOS Simulator

For the purpose of upgrade testing in automation it's useful to have a build of the previous version of the application. Of course, for actual device installs this is easy with the use of adhoc builds and .ipa files, but for the Simulator this is a little more involved. It is feasible if you follow the following steps.

1. Launch the Simulator (/Developer/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone Simulator.app) and set the hardware and version to the appropriate settings.
2. Delete any existing apps in the simulator.
3. Put a breakpoint in the main function (i.e. first line of the main function main.m). This is to ensure that no code writes any files to the build directory (i.e. CoreData, Analytics, Preloading URL's, etc.).
4. Run the project in debug and stop the program once it reaches the breakpoint in the main function.
5. At this point if you followed step (2) and only have one application it should be easy to locate in ~/Library/Application Support/iPhone Simulator/[version]/Applications and can easily be tar'ed up and archived and moved around.

Now in an automated testing script you can remove any applications from the simulator, untar the appropriate archive, exercise preloading (i.e. logging in) to get the simulator in a state to test an upgrade. Now, simply build the project and have it install over this version and test any upgrade scenarios.

This has even worked from Xcode 3.2.6 builds being applied to Xcode 4.0.1.

iPhone Open Source Automation

Testing iPhone apps is always thought of last and is typically performed manually. At Lolay we believe in a strong automation investment to allow testing as we develop so that we can have confidence in the stability of our builds as we develop.

Checkout a demonstration of how to automate the iOS platform / iPhone using all open source. This is all compatible with ANT and Maven in any continuous environment. In this demo you will be shown on open source can perform a basic test in Where U At? and run through both positive and negative testing. At the end you can see the JUnit results including screen shots of the failure.

Vimeo: How to automate the iPhone using open source

BIA/Kelsey Reviews Lolay, Future of Things to Come

Gary recently spoke with Mike Boland from BIA/Kelsey about Lolay's social and location-based efforts. You can read the details here.



We are excited to note several key areas where Lolay will be focusing its efforts:

• Where U At? iOS: Where U At? for iOS will have some major updates within the next two weeks. Look out for the details!
  
• Where U At? Android: We have been working diligently to release Where U At? for Android and are pleased to announce it will be in the Marketplace very soon!
  
• Lolay's Incubator: Helping other developers (novice to experienced) create apps that make money and solve a problem out of the starting gate. Our Lab Werx platform will serve as the foundation for quick success.
  
• Partnerships: We are looking for like-minded people, companies and mobile efforts that are complimentary to Lolay's mission to change the way people interact. Feel free to Connect with Us.

Looking forward to a great 2011!

Mobile, Token Based Authentication

We've had some recent discussion on mobile authentication and thought it might be a good time to discuss how this works in the Where U At? application where we had white space to start fresh. For the most part we took a lot of insight from Twitter to use a token based authentication method, but not use OAuth. It's more of a service based OAuth that fits better in a paradigm where applications will interact as a service and want to tightly control the authentication service.

As everything in Where U At? it's a REST implementation that looks like the following (a few details are omitted):

1. POST: /tokens
1. Request Data
1. email
2. password
3. manufacturerId
2. Returns: Token
2. GET: /tokens/{UUID}
1. Returns: Token
3. DELETE: /tokens/{UUID}

Behind the scenes we have a few objects that make this all work on the server.

1. Token
1. token_id
2. expiration
3. user_id
4. device_id
2. User
1. user_id
2. email
3. name
4. password (one way encrypted)
3. Device
1. device_id
2. type
3. manufacturer_id
4. security_id

Any application can create a token (i.e. login) and store the token or token_id locally and reuse that. For any requests to our other services you simply pass an X-Token header with the token_id as the value. The other resources will validate the token is valid (i.e. that it exists and is not expired).

Any application can verify the token using a GET request if they so desire. Additionally, they can delete a token to perform a logout.

We follow a practice that only one user and one device can have a token active at any time. This means that if I login into my iPhone and then my iPad the token for the iPhone is deleted on the server. This works for us in a Location Based Application with push notifications to ensure only one device for a user is updating location at a time. It also ensures push notifications go to the right device.

A token_id has the same security behavior as a cookie based session id like every web app in existance these days and can be "stolen". To prevent this all requests are encrypted using standard SSL (not just login) so that only the server and device ever can see the token.

Where U At? Server Release 8 (1/29/2011)

Another month in the new year almost over and another release from team Where U At?! Another quick server release to upgrade to the new CityGrid v2 API's. With the new CityGrid v2 Offers API we are considering another upcoming release to make our deals/offers better!

Where U At? Server Release 8 (1/29/2011)

1. CityGrid v2 API's which has made our app faster for finding places and locations!

What are you waiting for? Download the FREE app from http://bit.ly/whereuat

Where U At? Server Release 7 (1/3/2011)

Happy New Year from the Where U At? Team! We have a quick release in the new year to fix a few bugs.

Where U At? Server Release 7 (1/3/2011)

1. Made the push notification text more clear when accepting a meetup
2. Location access for a Friend was showing as Disabled even when you requested All The Time

Again, if you *still* haven't download our FREE app yet, you can download it from http://bit.ly/whereuat