POST
|
I can confirm that this workaround does indeed work as expected. Thanks a lot you are a life saver.
... View more
01-23-2017
11:23 AM
|
0
|
0
|
352
|
POST
|
fetchData(completion:) method on AGSPortalItem can lead to out of memory kills of the app. It appears that shortly before the completion handler is called, the app suddenly needs four times the size of the download in memory with no apparent reason. In my case its an 100 MB Download. This leads to the App getting killed under Memory pressure. On another note it looks like the complete download is stored in memory the whole time. This is probably not ideal even without the 4x memory bug. portalItem.fetchData { [weak self](data, fetchError) -> Void in if let error = fetchError { print("Could not fetch data due to error : \(error)") }else{ print("Downloaded portal item") print("Title : \(portalItem.title)") print("Type : \(portalItem.type.rawValue)") print("ID : \(portalItem.itemID)") } }
... View more
01-21-2017
11:57 AM
|
0
|
2
|
1088
|
POST
|
Loadable pattern for asynchronous resources—ArcGIS Runtime SDK for iOS | ArcGIS for Developers If a resource has failed to load, calling loadWithCompletion: on it subsequently will not change its state. The callback will be invoked immediately with the past load error. In order to retry loading the resource, you must useretryLoadWithCompletion: instead. The advantage of this approach is that if, hypothetically, loadWithCompletion:were to retry loading a failed resource, an app could easily end up making many asynchronous requests to load the same resource just because it shared the same resource instance in different parts of the application and each part tried to load the resource without first checking if it was already loading. This pattern allows loadWithCompletion: to be invoked indiscriminately without worrying that it might add overhead, and makes retrying a separate and explicit scenario using retryLoadWithCompletion:.
... View more
01-01-2017
07:18 AM
|
0
|
0
|
241
|
POST
|
If I download an AGSPortalItem via the load: method and the download fails (for example there is no network connectivity at that moment) I need to use the retryLoad: method on further download attempts for the same AGSPortalItem. Even if the network is back up, another load: call on the original PortalItem will always fail. I wonder what the design decision is behind this construct. Would't it be much easier to recheck network connectivity on all load: operations? Best, Linnart
... View more
12-29-2016
11:42 AM
|
0
|
1
|
1434
|
POST
|
Thanks for the reply. I think that is not possible. I only ever get access to the Data object when the completion callback is called. In the AGSLoadable Protocol there is a property called public var loadStatus: AGSLoadStatus { get } which is stated to be KVO compliant. It should be easy to add another kvo compliant property that has the download progress. How can I file an enhancement request to the API? Having a download of possible hundreds of MB of data triggered by a user without any indication how long the download will take is out of the question.
... View more
12-28-2016
05:56 AM
|
1
|
0
|
350
|
POST
|
Is there a way to get continues download progress updates (aka bytesLoaded/bytesTotal) when loading a PortalItem? I would like to display a download progress bar to the user. Best, Linnart
... View more
12-25-2016
07:23 AM
|
0
|
2
|
1548
|
POST
|
Did you try: pod repo update As suggested in the error message? I installed the Beta SDK via CocoaPods without any problems.
... View more
10-16-2016
11:10 AM
|
0
|
2
|
571
|
Title | Kudos | Posted |
---|---|---|
1 | 12-28-2016 05:56 AM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|