iOS-SDK, accessing external DB and own objects

#1

After setting up an external database service (MySQL) and configuring the service in DF, I can successfully query and store elements via the REST calls in the web interface.
However, I’m building a native iOS app (based on the given iOS ToDo-list example) and would appreciate some pointers on the following topics:

  • How to properly access the external DB service instead of the standard “REST/db/” (is there a way using the SWGDbAPI, or should I use different API classes?).
    I’ve now added a custom constructor, replacing the /db/ parts when initialised with another DB API string.

  • How to create one or multiple records. The ‘body’ argument is a SWGRecordsRequest type, that I’m unsure about how to fill. The API-doc says they should be key value pairs, but how can I properly form these as an SWGRecordsRequest?

  • I see the ID field is non-optional (can’t be nil) with the DB api/online SWAGGER, but what if the external DB service has an auto-increment on the ID?

Thank you in advance.

#2

You would use SWGDbAPI as a template to create your new API class.
I’ll look at that SDK again later this morning and get back to you on the other questions.

#3

After an intensive exploration through the project I realised that the ‘SWGRecordRequest’ etc. classes are not generic wrappers, but specific ones for the ToDo-App.
What confused me was that:

  • the properties of the SWGRecordRequest/-Response do have names that are easily mistaken to be ‘meta names’. Is the value ‘name’ representing a name of a key, or the name of the ToDo-list item. I thought that I could serialise an existing object definition using the SWG-Classes (automatically). Using “todo_name” or so would have prevented this mistake on my side.
  • I did not anticipate on the fact that there would be files in the API that I have to customise. From my experience, normally an API is just a black box with some header files. Maybe it would help if the files that are specific to the ToDo-list implementation are placed in a separate directory/group and are given names that clearly separate them from generic (prototype) files of the API.

Thank you for your quick responses and seeing a lot of potential in the service!

#4

Good idea, working on making it more generic, those files in the root directory are generated by hitting the actual service and getting the params, path, etc. Would be nice if you could just use the invoker to call a generic service handler that would take the params and service name. I’ll work on getting that into the next release.

#5

That sounds good!
Is there a solution to send a null value as an ID when creating a new record in a custom autoincremented-ID MySQL database?

#6

Thats’s gotta be a bug, createRecord shouldn’t require ID, let me check on that.

#7

I went back and found where we did indeed have this bug on auto increments with that particular method, but we then used it in the latest SDK.

[swgDbApi createRecordWithCompletionBlock:kTableName _id:@"" body:record fields:nil id_field:nil id_type:nil related:@"" completionHandler:^(SWGRecordResponse *output, NSError *error) {
…

So I’m thinking your “custom” means more than I thought it did.