Open midaslefkowitz opened 5 years ago
@midaslefkowitz Thank you for reporting to us. This is currently a limitation of TransferUtility
. The current design does not allow us to use a different network connection type for each transfer. I will take this as a feature request to the team for prioritization.
Meanwhile, I wanted to suggest a workaround and see if that works for you. You can construct a TransferUtility
object for each transfer and specify a preferred network connection type of your choice.
@kvasukib, thanks for replying. Your workaround is a good idea, however I also need to be able to change the preferred network connection for requests that are already queued and/or in progress. The reason for this is (for example) if a user has a queued request waiting for wifi and the user changes his settings to allow Mobile uploads as well we don't want the queued request to wait for wifi any more.
@midaslefkowitz Have you tried using TransferUtility.resumeAllWithType()
to resume the paused transfers? When doing so, you could construct a TransferUtility
instance with the preferred network connection type.
Just to clarify, you are saying that I can have two TransferUtility
instances, each with a different TransferNetworkConnectionType
. Let's call them AnyNetworkTransferUtility and WifiOnlyTransferUtility.
Then, if the user decides that they want to change their preferred network connection type (from ANY to WIFI for example), I can simply pause all transfers on the AnyTransferUtility object and then resume all transfers on the WifiOnlyTransferUtility ?
As far as I can tell this will not work as the transfer_utility_options are not changed in the awstransfer db. The connection type stays the same. Although I am happy to be wrong, so please tell me if I am making a mistake here.
@midaslefkowitz You are right. The network connection type is being stored in the transfer database. A transfer if started with a particular network connection type, for example WiFiOnly will need that network connection type to complete.
I will take this design choice we made to the team for further discussion and evaluate if we could change this behavior. Thank you for pointing it out.
@kvasukib any progress? it is pretty standard things nowadays to enable/disable networking type in runtime
it will be helpful, when TransferUtility
can have some options/context/flags shared between all transfers at the same time.
for example:
in this case:
a) TransferUtility
can ask this shared options in runtime
b) user can change/ask this options in runtime
OR
as alternative it can be implemented in several steps:
changeNetworkingType
in TransferObserver
very useful.
thanks!
My android app uses AWS Transfer Utility to facilitate transferring videos to and from an S3 bucket. The app has a setting (which the user can adjust) to allow transfers via Wifi only or to allow transfers regardless of connection type.
The current version of the android amazon sdk allows the developer to pass a TransferNetworkConnectionType in the options that are used in the TransferUtility builder. However, there isnt a way to change these on the fly or to configure them per request. I need this in cases where the user changes these settings while a transfer is ongoing.
For example, the user has defined that transfers be WifiOnly and user is on a data network. In the TransferListener the sdk informs client that the state of this transfer is now WAITING_FOR_NETWORK. In my app, we take this opportunity to inform the user that the transfer is pending requested network. Now the user changes the setting to allow any network type. There is no way for me to change the current transfer to TransferNetworkConnectionType.ANY. There is also no way for me to make this change in the TransferUtility itself. Options are defined once per TransferUtility.
As a workaround I attempted to use the available API to get all transfers, clean all listeners from each transfer, cancel each transfer and delete each transfer record. Then I created a new TransferUtility with the updated options and resubmitted the request. The TransferListener calls back with a state change to IN_PROGRESS, however, the file is never actually transferred (ie onProgressChanged(int id, long bytesCurrent, long bytesTotal) is never called).
I am testing on a Xioami AOne with SDK 7.1.2