Feature/implement receiving files

[walterholohan]

This PR attempts to create the mechanism for the phone to receive a file from the watch using the didReceiveFile event. I have tried to copy how it was previously done for didReceiveUserInfo i.e. creating a fileQueue etc

[yolpsoftware]

We don't use file transfers in that direction, so I'm unable to test your changes.

Code looks good to me.

[mtford90]

@walterholohan I'm thinking it might be worth adding this functionality to the example app - what do you think? That way e.g. @yolpsoftware would be able to test this out despite not having a need for it in their own app.

That being said - not sure how well the example app works on more recent RN versions, have either of you tried it recently?

[walterholohan]

@walterholohan I'm thinking it might be worth adding this functionality to the example app - what do you think? That way e.g. @yolpsoftware would be able to test this out despite not having a need for it in their own app.

That being said - not sure how well the example app works on more recent RN versions, have either of you tried it recently?

Yeah, I tried to run the example app yesterday but it was complaining about Flipper. I am going to test this new feature out on our production app today, as we have a time-critical bug that needs to be fixed asap.

At the moment when a user completes a workout on our apple watch app, we store a tonne load of data points from that workout, and at the need when a user saves it we try to send it back to the phone using user-info. However, we are getting a lot of crashes with the error message PayloadTooLarge. Our plan to fix this and make the transfer of data more reliable is to save the data to a JSON file and compress it on the watch using the zlib algorithm. We are then going to send it back to the phone using the file transfer API where the phone will then receive and upload the compressed file to our servers using a multipart/formdata POST request. We will then decompress the file using the node zlib library.

I will let you know how we get on with testing this approach today. Hopefully, once everything is working I will then have some time to update the Example app.

[mtford90]

@walterholohan I'm thinking it might be worth adding this functionality to the example app - what do you think? That way e.g. @yolpsoftware would be able to test this out despite not having a need for it in their own app. That being said - not sure how well the example app works on more recent RN versions, have either of you tried it recently?

Yeah, I tried to run the example app yesterday but it was complaining about Flipper. I am going to test this new feature out on our production app today, as we have a time-critical bug that needs to be fixed asap.

At the moment when a user completes a workout on our apple watch app, we store a tonne load of data points from that workout, and at the need when a user saves it we try to send it back to the phone using user-info. However, we are getting a lot of crashes with the error message PayloadTooLarge. Our plan to fix this and make the transfer of data more reliable is to save the data to a JSON file and compress it on the watch using the zlib algorithm. We are then going to send it back to the phone using the file transfer API where the phone will then receive and upload the compressed file to our servers using a multipart/formdata POST request. We will then decompress the file using the node zlib library.

I will let you know how we get on with testing this approach today. Hopefully, once everything is working I will then have some time to update the Example app.

Understood - sounds good. Not the end of the world if it doesn't make it to the example app - more of a nice to have.

[walterholohan]

@yolpsoftware @mtford90 we managed to get this working. One of the major hurdles that we faced was that the file was transfer to phone but was stored in temp storage on the FS and gets wiped once the function didReceiveFile returns. So in order to fix this, we are saving the file to a directory called FilesReceived within the Documents directory. It will then be up to the RN side to delete this file from FS when you don't need it anymore. In our case, we delete the file once we have successfully uploaded it to our servers. We also have a check on app load that will search this directory for any files that failed to upload and will then try retry the upload

[walterholohan]

We also added in a listener for EVENT_WATCH_FILE_ERROR

[walterholohan]

Hey @yolpsoftware @mtford90, would I be able to get another review on the above? I have added some more error listener for the below events which should help debug issues with connectivity. Also, just an FYI we have gone live with the file transfer approach and its all working great

EVENT_ACTIVATION_ERROR EVENT_APPLICATION_CONTEXT_RECEIVED_ERROR EVENT_SESSION_BECAME_INACTIVE EVENT_SESSION_DID_DEACTIVATE

[walterholohan]

@mtford90 @yolpsoftware just bumping this. These changes have been live on our app in production for the last two weeks and we've experienced no issues so far

[yolpsoftware]

@walterholohan sorry I have been away two weeks.

I have not really time to test this, but I'm glad to give my thumbs up if you say you are productively using these changes.

Two things:

• I noticed you added the dist folder. Are those files auto-generated, or why weren't they necessary before this PR?
• I'm not listed as a reviewer. Can I review anyway?

[walterholohan]

@walterholohan sorry I have been away two weeks.

I have not really time to test this, but I'm glad to give my thumbs up if you say you are productively using these changes.

Two things:

• I noticed you added the dist folder. Are those files auto-generated, or why weren't they necessary before this PR?
• I'm not listed as a reviewer. Can I review anyway?

Thanks @yolpsoftware

Regarding the dist folder, its prob one for @mtford90 . I think he generates a new dist folder when deploying a new release to NPM. I was using it so I could use my fork in package.json and the app would pull the code from the dist folder

[yolpsoftware]

Ah I see. I was missing that dist folder when I tried to use my fork on package.json. To me it makes sense to include it.

What do you think @mtford90 ?

[walterholohan]

Thanks guys, I have now removed the dist folder

[TamasNo1]

Hey guys, just wanted to say a quick thanks, this works perfectly!

[walterholohan]

@mtford90 would it be possible to get a review on this PR and then get a new release?

[mtford90]

@walterholohan all done - sorry for delay