Android model IDs must be UUIDv4; iOS imposes no such restriction

Android versions:

implementation 'com.amplifyframework:core:1.3.2'
implementation 'com.amplifyframework:aws-api:1.3.2'

iOS versions:

  - Amplify (1.1.2):
    - Amplify/Default (= 1.1.2)
  - Amplify/Default (1.1.2)
  - Amplify/Tools (1.1.2)
  - AmplifyPlugins/AWSAPIPlugin (1.1.2):
    - AppSyncRealTimeClient (~> 1.4.0)
    - AWSAuthCore (~> 2.15.0)
    - AWSCore (~> 2.15.0)
    - AWSPluginsCore (= 1.1.2)
    - ReachabilitySwift (~> 5.0.0)
  - AmplifyPlugins/AWSDataStorePlugin (1.1.2):
    - AWSAuthCore (~> 2.15.0)
    - AWSCore (~> 2.15.0)
    - AWSPluginsCore (= 1.1.2)
    - SQLite.swift (~> 0.12.0)
  - AppSyncRealTimeClient (1.4.1):
    - Starscream (~> 3.1.0)
  - AWSAuthCore (2.15.3):
    - AWSCore (= 2.15.3)
  - AWSCognitoIdentityProvider (2.15.3):
    - AWSCognitoIdentityProviderASF (= 1.0.2)
    - AWSCore (= 2.15.3)
  - AWSCognitoIdentityProviderASF (1.0.2)
  - AWSCore (2.15.3)
  - AWSMobileClient (2.15.3):
    - AWSAuthCore (= 2.15.3)
    - AWSCognitoIdentityProvider (= 2.15.3)
  - AWSPluginsCore (1.1.2):
    - Amplify (= 1.1.2)
    - AWSCore (~> 2.15.0)
    - AWSMobileClient (~> 2.15.0)
  - CocoaAsyncSocket (7.6.4)
  - ReachabilitySwift (5.0.0)
  - SQLite.swift (0.12.2):
    - SQLite.swift/standard (= 0.12.2)
  - SQLite.swift/standard (0.12.2)
  - Starscream (3.1.1)

Example Model:

type Todo @model
{
    id: ID!
    task: String
}

Example Android Code:

Todo todo = Todo.builder()
    .id(“ABC123xyz”)
    .task(“Do something great!”)
    .build();
Amplify.API.mutate(ModelMutation.create(todo),
    response -> Log.i("MyAmplifyApp", "Added Todo with id: " + response.getData().getId()),
    error -> Log.e("MyAmplifyApp", "Create failed", error)
);

This results in:

java.lang.IllegalArgumentException: Model IDs must be unique in the format of UUID.

Example iOS Code:

var item = ToDo(id:"ABC123xyz”, task:”Do something great!”)
 _ = Amplify.API.mutate(request: .create(item)) { event in
    switch event {
    case .success(let result):
        switch result {
            case .success(_): break
                print("Successfully saved: \(savedItem.id)")
            case .failure(let graphQLError):
                print("Failed to create graphql \(graphQLError)")
            }
        case .failure(let apiError):
            print("Failed to create a todo", apiError)
        }
    }

This works as expected and is entered into DynamoDB. The documentation is not clear on what platform implementation is correct, and if they should work in the same manner.

[EdwardFinegan]

We place a serial number of a physical item in this field in the iOS implementation. We could move this serial number to another field but this would cause us to create another key. I believe this would be another secondary index in Dynmo which has a cost associated with it (while not significant we always try to keep this in mind). That was our reasoning behind why we did iOS as we did.

Either way it would seem to make the most sense to have both platforms behave in the same manner, regardless of what one is changed.

[jamesonwilliams]

@kjones @EdwardFinegan

The ID field is used while defining AppSync-compatible GraphQL schema. It is documented here:

The ID scalar type represents a unique identifier, often used to refetch an object or as the key for a cache. The ID type is serialized in the same way as a String, however, defining a field as an ID signifies that it is not intended to be human‐readable.

Currently, Android does require the model ID to be a Version 4 UUID.

The Android library could potentially relax this constraint, in a backwards-compatible way, so that the customer may define her own “unique identifier,” (unique how?) instead of us defining it for her. IIRC, I required this field to be UUIDv4 for convenience only. I don’t remember this being a hard constraint of the system design – but that warrants a review.