Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Matthew O'Gorman
    @mogorman
    i have an endpoint that returns gzipped json. it works fine via curl, but when i use alamofire.request im getting the gzipped json, its not automatically being de gzippped. where should i look to try to solve
    everything ive found online says that this just automatically works
    also i am using the default headers that are requesting gzip/deflate. the server is responding with content-encoding properly as well
    Lucas Ramage
    @oxr463
    Can you provide a log from your curl example vs your request?
    Matthew O'Gorman
    @mogorman
    i figured it out, the data was being double gzipped some how. alamo was doing the right thing it was my fault
    Lucas Ramage
    @oxr463
    Oh wow
    dipcse07
    @dipcse07
    Hi I am new in ios developing and recenty using alamofire..
    my question is can anyone give me the documentation to upload image to server via alamofire
    corban123
    @corban123
    Is there a good way to go from the AnyPublisher<AnyDecodable, AFError> to a AnyPublisher<AnyDecodable, Error>?
    Jon Shier
    @jshier
    Sure, you can just mapError { $0 as Error }.eraseToAnyPublisher(). I would suggest trying to keep the real types you’re dealing with though.
    AnyDecodable should only really be necessary for heterogenous collections, not for your response handling.
    corban123
    @corban123
    Oh nice, thanks. Yeah, currently I'm attempting to get from the publishDecodable return value to some sort of replacement for Single<T> of RxSwift via Combine
    Jon Shier
    @jshier
    I have an eraseError() convenience method if I want to erase the error, but you don’t need AnyDecodable to do that.
    corban123
    @corban123
    Ah, my mistake, I made a mistake. I meant Single<Data> where Data could be either an Error or a response's data that will then be decoded afterwards into some sort of object T. However, I'm unsure if this is necessary anymore as unless I'm misunderstanding, publishDecodable attempts to decode via the decoder in that function
    Jon Shier
    @jshier
    Yes. There shouldn’t be any need to do your own decoding unless publishDecodable can’t do what you want. I’d suggest investigating our DataResponsePublisher in that case to publish your own path, rather than publishing data and doing your own decoding outside Alamofire.
    corban123
    @corban123
    I'll take a look into that, thanks.
    With everything being so new with AF combine, the lack of group knowledge in terms of examples on all this has definitely slowed down my process
    Jon Shier
    @jshier
    Once you’ve published your response, it’s just Combine.
    corban123
    @corban123
    Right... Makes sense. I have one last question. Is there an easy way to add authentication via a string sessionToken that needs to be placed in the header while writing the request? From what I'm seeing, .authenticate looks like it should handle this, however, the value is not really a SecTrust or a SecIdentity. Previously I'd converted the URLRequestConvertible into a URLRequest, then added the object to the headers in the request, however, I'd like to move away from that if possible
    The reason I hadn't been adding the sessionToken prior is due to the fact that it's in a Combine version of a ReplaySubject, so accessing the token is Async
    Jon Shier
    @jshier
    Not by default, no. authenticate adds a URLCredential, so if you’re using HTTP auth or one of the other supported credential auths, those should work automatically. For async credentials I’d suggest using a RequestAdapter.
    But if you’re just using a Published value for it, you can access that value directly to add it to the request.
    corban123
    @corban123
    Are there any examples of using the RefreshWindow on AuthenticationInterceptor? I see it being default initialized, however, I'm unsure how it keeps count of the number of consecutive refresh attempts as I'm seeing a nonstop loop of attempted refreshes currently after using the default initializer for AuthenticationInterceptor
    Jon Shier
    @jshier
    Depends on what’s triggering those refreshes. You’d need to provide a full example for us to see if there’s an issue. But our tests exercise the window capability, so seeing how your code differs from them might be illuminating.
    corban123
    @corban123
    The refreshes are being triggered by the Authenticator's didRequest function coming back true. I've stuck a breakpoint within AuthenticationInterceptor, and refreshAttemptsWithinWindow comes back consistently 0
    It seems by the time isRefreshExcessive is called, mutableState.refreshTimestamps has been emptied out, but I don't see a spot in which this occurs
    Jon Shier
    @jshier
    If you can get a reproducible case, we’d appreciate an issue with an attached project so we can test it and replicate. But is it possible you’re creating new Session or authenticator instances for every request?
    corban123
    @corban123
    Hmm, singleton session, but I'm getting the feeling that the AuthInterceptor is being regenerated
    Jon Shier
    @jshier
    Are you perhaps sending one to each request rather than setting it at the Session level?
    corban123
    @corban123
    Issue for my project is that I'm unable to set the credential at the Session level
    I made my entire NetworkClient a singleton, however upon attempting to make a second request, I end up with No request created yet.
    Which makes little sense to me since all that would do is force the AuthenticationInterceptor to never get deallocated
    Jon Shier
    @jshier
    Yes, Request’s creation of underlying URLRequests are asynchronous, so that will be the summary while that process is underway.
    You’ll need to store the interceptor alongside your singleton to you can use the same instance for every request.
    corban123
    @corban123
    Is there a way to apply your initial credential to the AuthenticationInterceptor late?
    Also, despite it being asynchronous, it seems like the request never gets created as I never see a secondary network call being made
    Jon Shier
    @jshier
    You can just set the property.
    That sounds like the async process never completes, perhaps because an adapter never completes.
    corban123
    @corban123
    Which property are you referring to?
    And is there a good way to track down which async process never completes?
    Jon Shier
    @jshier
    You can set credential on the interceptor.
    Sure, you set breakpoints in the various Session perform methods, especially performSetupOperations.
    corban123
    @corban123
    Seems the adapt(initialRequest callback never happens
    neither the do nor catch get called
    Jon Shier
    @jshier
    You’ll want to then set breakpoints in your adapter and see what that is.
    corban123
    @corban123
    mutableState.isRefreshing is true
    Jon Shier
    @jshier
    So a refresh started, but is still waiting. Requests won’t start, if they need the same credential, until the refresh is complete.
    corban123
    @corban123
    I see the request complete via charles though
    Jon Shier
    @jshier
    THe refresh, or the request that’s waiting?
    corban123
    @corban123
    Hmm
    The initial failed request is the only call that gets made