Sergeyd/plugin system

[dryganets]

Historically android had two packages android and android native.
This is the first step for deprecation of android-native.

The plugin system allows abstract logic of work with SQLite out of the logic of work with database implementation.

As an icing on the cake, it adds the implementation of SqliteCipher plugin.

[henryphtang]

Woah great thanks! you're awesome! I'll check this out someday!

[dryganets]

@andpor I rebased the PR to fix conflicts.

[dryganets]

@andpor, is there something I could do to move it to master?

[andpor]

I just got back from being away for a while this summer. I will take a look at all outstanding stuff in this repo in the next few weeks. Apologies for delay...

[andpor]

apologies for not getting to this PR yet...too busy at work ...hopefully very soon...

[dryganets]

Any news here? :)

[brody4hire]

Comments from owner of Cordova-sqlite-storage that this project was based on:

+1 for additional abstraction to make it easier to change Android sqlite implementation

-1 for the following items:

• additional steps needed to add plugin to react-native application
• bundling of sqlcipher

Bundling of sqlcipher leads to important legal export requirements described at: https://discuss.zetetic.net/t/export-requirements-for-applications-using-sqlcipher/47

[dryganets]

@brodybits, we are not bundling the sqlitecipher.
In android/gradle, you are bundling something only in case you are using it.
So, as long as you don't perform that additional step - you are legally fine, as your release bundle doesn't have sqlitecipher.

That was the point of the abstraction layer - if people don't need to have an encryption they don't need to do anything extra. If they want to - there is one extra step to take in order to make it work.

[brody4hire]

@dryganets I think I get it now. SQLCipher for Android is only included if the extra package is added. SQLCipher is already supported for iOS if SQLCIPHER is defined ref: #40 (comment). I am still wondering how the needed encryption provider (probably CommonCrypto in case of iOS) would be linked (dynamic), should not be linked unless explicitly required by the app developer.

I am starting to warm to the idea of the separate sqlite provider for Android to improve the modularity and make it easier for the app developer to only add the parts actually needed. It would be ideal to have pluggable sqlite provider for both iOS and Android. Assuming we would only need the sqlite provider for Android, I would personally favor calling it something like "sqlite-provider-android" or "react-native-sqlite-provider-android".

[dryganets]

So far, the best way I see is to have two different podfiles for different configurations.
But I'm not an iOS developer and might miss some ways.

[dryganets]

@andpor any plans to release it?

I could move all the plugins related stuff under my personal repositories with appropriative licensing to minimize structural changes to the project if you want.

[dryganets]

Closed in favor of Plugin System V2.