remind101 / autograph Goto Github PK

After pod update with the last version of AutoGraph, I stuck on crashes in release mode.
In debug mode, everything works fine.

Currently, I'm developing the app using the AutoGraph library (0.4.4), and after update to Xcode 9.3 I have a problem with generics used in Crust library. After Autograph update with all dependencies, everything worked fine. But when I compiled in release mode, my app start crashing in any part of code after the request from GraphQL server.

Thread 1: EXC_BAD_ACCESS (code=1, address=0x60020044c998)

Then I created a simple app with dependencies used for Autograph last version and tried to make a simple request. The behavior of the application remains the same in release mode.

Example app:

pod 'AutoGraph'
pod 'RealmSwift'

Using Alamofire (4.7.2)
Using AutoGraph (0.5.0)
Using Crust (0.9.0)
Using JSONValueRX (4.0.0)
Using Realm (3.5.0)
Using RealmSwift (3.5.0)

and set one model in the app for fetch data from GraphQL server.

Result: App always crashes.

Update: xcode 9.4 beta 1 In release mode, everything works fine.

My bad, I failed to add bridge header file.

Are union types supported and if so, how would I go about doing them?

So for example, if I had a request of:

query GetItems {
     item {
          ... on SuperItems {
               id
               name
          }
          ... on SuperDuperItem {
               id
               name
          }
     }
}

How would I specify this in the Query Document, and also in parsed model?

Thanks!

spm ci

Hi, are there any plans to add Swift 4 support for this library? Thanks.

Hi , i've a call that return null when a data is not found in the database.
like when a user is not found.

{ "data": { "user": null } }

it result in a [NSJSONSerialization dataWithJSONObject:options:error:]: Invalid top-level type in JSON write in swift when I launch the app.

the error is triggered by public func didFinishRequest(response: HTTPURLResponse?, json: JSONValue) throws { }
how can I handle null data with autograph

Hi!

Great repo, thanks for sharing! This might be a shot in the dark as my question pertains to an old version of AutoGraph, so feel free to say you can't help.

I'm using v0.8.0 (we utilize Realm integration so aren't in a position to upgrade just yet to 0.9.0) and am trying to figure out the proper way to set up mappingKeys on my Request object for inline fragments. I am able to build and send my request fine with InlineFragment objects but I'm failing to come up with what feels like the correct way to map/parse the response. Issue #107 came close to answering my question, but I'm wondering if there's a more proper way of handling the mapping (via mappingKeys) instead of doing it all manually from the raw json response?

Example query:

query getFeed {
    id
    blocks {
      __typename
      id
      ... on BlockTypeOne {
        title
      }
      ... on BlockTypeTwo {
        message
        userName
      }
    }
}

My attempt at mappingKeys:

var mappingKeys: Set<FeedKey> = [
  .id,
  .blocks([
      .typename,
      .id
      .title,
      .message,
      .username
    })
]

Since the 2 inline fragments have different fields, I'm trying to figure out a "correct" way to set up my mappingKeys. Using the above example, if I try to include title, message and userName at all times in the Request object's mappingKeys, I end up with a Crust.MappingError.noDataAtKeyPathFromKeyToMapFrom(keyPath:key:) error in Crust as all values are not present on all response objects. Again, I realize my question involves a legacy version that includes old dependencies, but I thought I'd ask. At worst, I can probably just take the root json response and map everything the old fashioned way by hand.

Thanks again for your time and the great repo!

My project is using pod that uses Autograph and since I updated to the latest Xcode 10.2 I can't compile it.

This is the error I am getting

Any ideas how can I go around this?? Have you heard or someone else having this issue...??

Thanks

https://github.com/realm/jazzy

More flexible this way.

Since RealmAdapter currently takes a realm which is thread confined, and the mapping itself is used on a background thread, it can only be implemented as a computed property or access to the realm will crash in runtime. Passing a configuration instead means we can lazily instantiate the realm on the correct thread.

You are using AlamoFire 4.8.2 which has not active module resiliency and causes the following error during compilation Module compiled with Swift 5.0.1 cannot be imported by the Swift 5.1.2 compiler

Please check this issue in the AlamoFire GitHub

Alamofire/Alamofire#2990

This is solved for AlamoFire V5. Is there any chance you can update your AlamoFire version??