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.

Sign up for GitHub

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

Jump to bottom

Negotiating data exchange, Tracking last sent data on the receiver & generate hash key if not presenter device start #32

Merged

ekigamba merged 18 commits into master from issue/8-negotiating-data-exchange

Apr 17, 2019

Contributor

ekigamba commented Mar 27, 2019 •

edited

Loading

Fixes #8
Fixes #5
Covers some tasks on #6

Negotiating data exchange
Tracking last sent data on the receiver
Generate hash key if not presenter device start

ekigamba force-pushed the issue/8-negotiating-data-exchange branch from db0c31f to 19c2831 Compare

March 28, 2019 08:12

ekigamba changed the title ~~Negotiating data exchange & Tracking last sent data on the receiver~~ Negotiating data exchange, Tracking last sent data on the receiver & generate hash key if not presenter device start

ekigamba added 14 commits

April 1, 2019 11:37


          Generate hash key if not presenter device start

5efd03f

Capitalize Constant sub-classes/interfaces instead of using UPPER_CASE


          Add ability to send and receive hash key after successful authorization

d25d79b


          Generate hash key when the library starts and use it after authorization

945294f

- Add room and encrypted sql cipher
- Use Wifi mac address as the device unique identifier since it persists across installs and device formats
- Add SendingDevice records as sending_devices table to keep track of sending devices
- Add p2p_received_history table to keep track of received history
- Sending devices sends the hash_key(app-lifetime-key) to the receiving device together with the unique identifier
- Register new sending device on recieving device
- Clear previous receiving history if the sending device has it's app-lifetime-key(hash_key) changed


          Code cleanup

d284cfc


          Fix tests

98f0057


          Code cleanup

13b81e1


          Remove unused classes & limit query

6ddecf7


          Implement processPayload, performAuthorization interface methods in S…

f52b492

…enderPresenter

- Move log strings and other UI strings to strings.xml


          Immediately disconnect from endpoints when connections fail

- This seems to work better than ConnectionsClient.stopAllEndpoints() and reduces the possibilty of memory leaks
- This also fixes the NPE when a connection callback is called after the app exits and the interactor is null


          Unregister lifecycle listener in QRCodeScannerView

338bdd0


          Fix tests and codacy issues

2a4b859


          Add more tests for P2PSenderPresenter

2eb5915


          Modify tables to enable for tracking of last sent data

2aca35b

Fixes #6


          Retrieve the device received history and send it to the sender

d8835e3

- Change the current connection level of the app after authorization
and after negotiating the start of the data exchange

Fixes #8

ekigamba force-pushed the issue/8-negotiating-data-exchange branch from 19c2831 to d8835e3 Compare

April 1, 2019 08:39

ekigamba mentioned this pull request

Generate hash key if not presenter device start #31

Closed

ekigamba added 2 commits

April 1, 2019 18:05


          Fix codacy issues

d14b877


          Add tests & fix codacy issues

2beb0cd

ekigamba requested a review from githengi

April 4, 2019 13:49

githengi reviewed

View reviewed changes

p2p-sync/src/main/java/org/smartregister/p2p/presenter/P2PReceiverPresenter.java

-                      view.showToast(view.getString(R.string.an_error_occurred_before_acceptance_or_rejection), Toast.LENGTH_LONG);
-                      resetState();
-                      startAdvertisingMode();
+                      if (getCurrentPeerDevice() != null && endpointId.equals(getCurrentPeerDevice().getEndpointId())) {

Contributor

githengi Apr 17, 2019

Shouldn't there be an else

Contributor Author

ekigamba Apr 17, 2019 •

edited

Loading

The else is not supposed to be possible, if it is, then due to the memory leak whose issue is here #39.

The app was crashing without the if since the code was being run even after exiting the activity and the ConnectionsClient is holding on to the callbacks passed

If the google issue has no reply by the time I am done with the remaining issues and no other solution in site, then we'll have to use WeakReferences for the view (Or clean it up) but the API might still hold onto the listener until it makes the last call

The else happening, means that the callback was called although we are not connected to the endpoint or have already disconnected

githengi reviewed

View reviewed changes

p2p-sync/src/main/java/org/smartregister/p2p/presenter/P2PReceiverPresenter.java

-                      resetState();
-                      view.showToast(String.format(view.getString(R.string.connection_to_endpoint_broken), endpointId), Toast.LENGTH_LONG);
-                      startAdvertisingMode();
+                      if (getCurrentPeerDevice() != null && endpointId.equals(getCurrentPeerDevice().getEndpointId())) {

Contributor

githengi Apr 17, 2019

Shouldn't there be an else

Contributor Author

ekigamba Apr 17, 2019 •

edited

Loading

The else is not supposed to be possible, if it is, then due to the memory leak whose issue is here #39.

The app was crashing without the if since the code was being run even after exiting the activity and the ConnectionsClient is holding on to the callbacks passed

If the google issue has no reply by the time I am done with the remaining issues and no other solution in site, then we'll have to use WeakReferences for the view (Or clean it up) but the API might still hold onto the listener until it makes the last call

The else happening, means that the callback was called although we are not connected to the endpoint or have already disconnected

githengi reviewed

View reviewed changes

p2p-sync/src/main/java/org/smartregister/p2p/presenter/P2PReceiverPresenter.java Outdated

+                      sendingDevice.setAppLifetimeKey(appLifetimeKey);
+                      db.sendingDeviceDao().update(sendingDevice);
+                      return db.p2pReceivedHistoryDao()

Contributor

githengi Apr 17, 2019

Shouldn't clear be done before update or maybe consider using Transaction

Contributor Author

ekigamba Apr 17, 2019

Either can work, there is device_id which will never change and is used to reference the device in the received_history table. I will add a transaction to this

githengi reviewed

View reviewed changes

p2p-sync/src/main/java/org/smartregister/p2p/presenter/P2PReceiverPresenter.java Outdated Show resolved Hide resolved

githengi reviewed

View reviewed changes

p2p-sync/src/main/java/org/smartregister/p2p/presenter/P2PReceiverPresenter.java

-                      Timber.e(view.getString(R.string.log_endpoint_lost), endpointId);
-                      resetState();
-                      startAdvertisingMode();
+                      if (getCurrentPeerDevice() != null && endpointId.equals(getCurrentPeerDevice().getEndpointId())) {

Contributor

githengi Apr 17, 2019

Consider adding else to do cleanup

Contributor Author

ekigamba Apr 17, 2019

The else is not supposed to be possible, if it is, then due to the memory leak whose issue is here #39.

The app was crashing without the if since the code was being run even after exiting the activity and the ConnectionsClient is holding on to the callbacks passed

If the google issue has no reply by the time I am done with the remaining issues and no other solution in site, then we'll have to use WeakReferences for the view (Or clean it up) but the API might still hold onto the listener until it makes the last call

The else happening, means that the callback was called although we are not connected to the endpoint or have already disconnected

githengi reviewed

View reviewed changes

p2p-sync/src/main/java/org/smartregister/p2p/presenter/P2PSenderPresenter.java

-                      view.showToast(view.getString(R.string.an_error_occurred_before_acceptance_or_rejection), Toast.LENGTH_LONG);
-                      resetState();
-                      startDiscoveringMode();
+                      if (getCurrentPeerDevice() != null && endpointId.equals(getCurrentPeerDevice().getEndpointId())) {

Contributor

githengi Apr 17, 2019 •

edited

Loading

Consider doing cleanup for an else clause

Contributor Author

ekigamba Apr 17, 2019

Same case

The else is not supposed to be possible, if it is, then due to the memory leak whose issue is here #39.

The app was crashing without the if since the code was being run even after exiting the activity and the ConnectionsClient is holding on to the callbacks passed

If the google issue has no reply by the time I am done with the remaining issues and no other solution in site, then we'll have to use WeakReferences for the view (Or clean it up) but the API might still hold onto the listener until it makes the last call

The else happening, means that the callback was called although we are not connected to the endpoint or have already disconnected

githengi reviewed

View reviewed changes

p2p-sync/src/main/java/org/smartregister/p2p/presenter/P2PSenderPresenter.java

-                      view.showToast(String.format(view.getString(R.string.connection_to_endpoint_broken)
-                              , endpointId), Toast.LENGTH_LONG);
-                      startDiscoveringMode();
+                      if (getCurrentPeerDevice() != null && endpointId.equals(getCurrentPeerDevice().getEndpointId())) {

Contributor

githengi Apr 17, 2019

Consider an else and doing cleanup

Contributor Author

ekigamba Apr 17, 2019

The else is not supposed to be possible, if it is, then due to the memory leak whose issue is here #39.

The app was crashing without the if since the code was being run even after exiting the activity and the ConnectionsClient is holding on to the callbacks passed

If the google issue has no reply by the time I am done with the remaining issues and no other solution in site, then we'll have to use WeakReferences for the view (Or clean it up) but the API might still hold onto the listener until it makes the last call

The else happening, means that the callback was called although we are not connected to the endpoint or have already disconnected

ekigamba added 2 commits

April 17, 2019 17:08


          Perform device details update & history delete in transaction

be09016


          Handle clear device history and update device key transaction fails

ab9f818

githengi approved these changes

View reviewed changes

ekigamba merged commit 6aa80be into master

ekigamba deleted the issue/8-negotiating-data-exchange branch

April 17, 2019 17:07

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet