Reported not to work with android about qrgen

[nelsonalmendra]

Confirmed. I tried to use it in an Android Application and I always get an exception.

[atomfrede]

In my branch (https://github.com/atomfrede/QRGen/tree/modularize) I've split the library into three modules core, javase and android (so what do you think about that solution...)

core contains all stuff that can be used with android and standard java. javase is more or less the current state and android replaces all operations using a BufferedImage with android's Bitmap.
Nevertheless there are some minor drawbacks:

• Not sure how an android library behaves when some transitive dependency has been build for java 7 (Android Supports java 7 since KitKat)
• Robolectrics unit testing capabilties regarding Bitmaps are not optimal. I think they use a shadow for all Bitmap related stuff, therefore the File generated is broken and empty. But I've tested the implementation on a real emulator an the QRCodes are generated fine.

[kenglxn]

Great work here as well @atomfrede . Perhaps I can get this as part of the next release. If not we should be able to solve this soon. I really want users of QRGen to be able to use ZXING as is, but at the same time get some convenience from QRGen. If we can solve the use case in a pretty way, then this will definately be a refactor I want to push :)

[atomfrede]

Maybe a longer pre-release phase would be a good idea to test the android module extensive on different api levels. Would like to me to file a pull request or should I merge my work into master first? What about creating a development branch so that master is always ready to release even when larger refactorings happen (on dev branch)?

[kenglxn]

I think the current setup works good, so I am hesitant to change it. Additionally, I don't want the overhead of having to configure and manage CI setup for two branches.

Could you update the Readme with a section for javase and one for android before making a PR.
Does this refactor cause breaking changes to existing users? If so the version should be bumped to 2.0-SNAPSHOT before PR as well.

[atomfrede]

It will break something as current users have to change their pom (or gradle or whatever) as the location of the artifact has changed. Nevertheless the api is the same so there is no need to change the code (expect imports). Will prepare everything during the day and then file a PR.

[kenglxn]

#17 fixes this. This fix is available in 2.0-SNAPSHOT. Will release 2.0 soon, after it has marinated in the intertubes a bit :)