Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

decouple storage from activity lifecycle #62

Merged
merged 3 commits into from
Jun 28, 2016

Conversation

dryganets
Copy link
Contributor

to allow background data processing in particular push notification payload persist scenario we need to have storage package decoupled from activity

DB close is not required on android.
All big applications what exist on the market don't use close function as there is no appropriate place to close DB connection in app lifecycle as you are usually want to have it shared between different activities.

By using Activity callbacks you making your application work unpredictable and prohibit background usage of your package.

We are recently moved JS engine initialization to the application level to be able to process push notifications in background correctly.

You could check stack overflow and any other resources regarding to this call - it not need to be called.

…ayload persist scenario we need to have storage package decoupled from activity
@andpor
Copy link
Owner

andpor commented Jun 21, 2016

Can you apply the change to both android (pure-java and native) packages? Thanks.

And also please create an issue for this so I can link it up to this change.

@dryganets
Copy link
Contributor Author

done,
Does it looks fair now?

@andpor
Copy link
Owner

andpor commented Jun 23, 2016

So if we implement it your way, we will introduce a backward incompatibility and everyone will have to make code adjustments. Instead of changing the constructor, why don't you add a new one that only takes react context without Activity. Then in original constructor everything works as Activity is assigned to local var and in the new constructor you get the Context from React Context.

Let me know once you make the adjustment and I will review the code...


public SQLitePlugin(ReactApplicationContext reactContext, Activity activity) {
public SQLitePlugin(ReactApplicationContext reactContext) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I mentioned, this create unnecessary backward incompatibility. Instead of removing original constructor, I think it will be more appropriate to add a new constructor taking only reactContext. This way both modes of creation are supported.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no incompatibility as everyone would use Package, there is no need to create Module directly, right?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, since we have these two constructors at the Package level it should be all right.

@dryganets
Copy link
Contributor Author

I've added package constructors with activity as you suggested, but marked them as deprecated.

@andpor andpor merged commit 2b6adfe into andpor:master Jun 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants