Objective C encoder port working
Yoni
element, but haven't been able to find any library as good as ZXing's
Java code to use for our iPhone app. Not wanting to rely on generating
all our QR codes remotely from Google Charts, we decided to port Zxing
to Objective-C. We have an initial working version, but we wanted to
check with you ZX maintainers first.
A few questions. First off, are there objections to us contributing
this to the main ZXing project? Right now the only ObjC code is
decoder-based stuff; is the encoder something there's been demand
for?
If it's not wanted in the main source tree, then we'd create a new
(Apache-licensed) project just for the ObjC components. If we have to
do that, does anyone have a problem with us using the Zxing name (for
example, zxing-objc)? Or on the other hand, would you be OK with (or
prefer) us not using Zxing in the name?
What would be the preference in terms of the copyright notice? Still
"ZXing authors", or perhaps our company name instead? Is it OK for us
to use the same class and package names from Zxing, and/or any of the
comments from Zxing core?
Steven Parkes
I think we'd be happy to have it incorporated into the project, particularly if it follows the Java closely (which makes maintenance easier … not that the encoder requires much maintenance.)
You say you ported it to Objective C? Not Objective C++? Personally, I'd prefer to have the core encoder in C++ with the appropriate additions to incorporate it into AppKit/UIKit as a separate module, much as the current code is split between the cpp and iphone/objc directories. (Not that I want to throw up unnecessary objections …)
Costa Walcott
I'm Yoni's coworker, and did most of the porting. The main reason we
ported to Objective-C was the ease in porting from Java, and my C++
chops being a bit rusty :). I kept the code as close to the core as
possible, making changes only as required for language differences.
It's a port of the zxing core (currently 1.7 as 2.0 wasn't released
when we started), although right now only the QR encoding has been
fully tested. It would be great to have some other eyes on the code.
How would you like me to share what we've done so far?
Thanks!
-Costa
Steven Parkes
On Mar 15, 2012, at 12:40 PM, Costa Walcott wrote:
> How would you like me to share what we've done so far?
It's a bit up to you. You can create an issue in the issue tracker and a attach a patch.
If you're using git, you could push it to github.
Steven Parkes
> We've put it up on GitHub:
>
> https://github.com/TheLevelUp/ZXingObjC
Wow. Looks like this is _way_ more than a QR encoder. It looks like it's what the README says it is: "a full Objective-C port of ZXing".
Did you hand-port every file? Have you run the blackbox tests and compared against the Java or C++?
Costa Walcott
really tested the QR encoding. I'd like to port over the tests next.
The port stays as close to Java as possible. I used java2objc (http://
code.google.com/p/java2objc/) as a starting point, but from there I
went file-by-file. Going from Java to Objective-C isn't that bad, the
main difficulties come in memory management, and also handling of
arrays and hashes, since the NSArray and NSDictionary classes require
elements to be subclasses of NSObject. This means numbers needed to
wrapped in NSNumber, or else using old C-style arrays. I've started
doing the later in some places, I'm sure there are other places where
it makes more sense to do this as well.
-Costa
Costa Walcott
The main things we're still working on is replacing the exception
handling with NSError (Objective-C encourages only using exceptions
for exceptional things like runtime errors), and also porting test
cases.
-Costa
Steven Parkes
An obvious possibility here would be to incorporate the whole port as another supported language. Are you interested in sticking around and keeping it up to date?
If we decided to do that, we'd want to discuss how to integrate it. Right now, the Java and C++ ports separate out the UI stuff from the core algorithmic code. There's also an existing Objective C library. It both wraps the core C++ in Objective C classes and provides classes to integrate with AppKit and UIKit. In theory, it'd be nice if the UIKit and AppKit interfaces were the same (if you have them) though I'm not sure if it's worth the effort ...
Costa Walcott
Gonna reiterate the question about running the blackbox tests: have you? Those are the gold standard of verification against the other ports.
An obvious possibility here would be to incorporate the whole port as another supported language. Are you interested in sticking around and keeping it up to date?
If we decided to do that, we'd want to discuss how to integrate it. Right now, the Java and C++ ports separate out the UI stuff from the core algorithmic code. There's also an existing Objective C library. It both wraps the core C++ in Objective C classes and provides classes to integrate with AppKit and UIKit. In theory, it'd be nice if the UIKit and AppKit interfaces were the same (if you have them) though I'm not sure if it's worth the effort ...
Steven Parkes
> really tested the QR encoding.
Ah.
> The port stays as close to Java as possible. I used java2objc (http://
> code.google.com/p/java2objc/) as a starting point
Ah. No name spacing, among other things. Not sure if there are any duplicate class names in the Java. Certainly unprefixed names could cause problems with user code.
Are you using the exiting code for decoding? Or maybe you're not decoding right now?
Costa Walcott
> Are you using the exiting code for decoding? Or maybe you're not decoding right now?
haven't tested it.
Steven Parkes
> Sorry, what's the exiting code? I've ported the decoding code but
> haven't tested it.
The C++ code, either using the widget or the Objective C wrappers.
j
How far away do you think you are from a working QR-code scanner?
/johan