Update config with relevant info from project endpoint

[seeReadCode]

Currently GET for a project returns:

{
  "name": "Test Project",
  "latitude": 1,
  "longitude": 1,
  "pub_date": "2011-12-06T16:06:32",
  "audio_format": "mp3",
  "auto_submit": true,
  "max_recording_length": 30,
  "listen_questions_dynamic": false,
  "speak_questions_dynamic": false,
  "sharing_url": "http://roundware.org/r/eid=[id]",
  "out_of_range_url": "http://scapesaudio.dyndns.org:8000/mg_outofrange.mp3",
  "recording_radius": 20,
  "listen_enabled": true,
  "geo_listen_enabled": false,
  "speak_enabled": true,
  "geo_speak_enabled": true,
  "reset_tag_defaults_on_startup": true,
  "timed_asset_priority": true,
  "repeat_mode": "stop",
  "files_url": "http://halseyburgund.com/dev/rw-base/webview/rw.zip",
  "files_version": "1",
  "audio_stream_bitrate": "128",
  "ordering": "random",
  "demo_stream_enabled": false,
  "demo_stream_url": "http://scapesaudio.dyndns.org:8000/scapes1.mp3",
  "out_of_range_distance": 1000,
  "sharing_message": "Check out this awesome recording I made using Roundware!",
  "out_of_range_message": "You are out of range of this Roundware project.  Please go somewhere within range and try again.  Thank you.",
  "legal_agreement": "Herein should be the brief legal agreement that participants need to agree to in order to make and submit a recording to a Roundware project.",
  "demo_stream_message": "You are out of range of this Roundware project.  Please go somewhere within range and try again.  Thank you.",
  "project_id": 1
}

See http://roundware.org/docs/api/index.html

[seeReadCode]

It might be nice to have these:

reverse_domain  (expected in framework, for error reporting)
startup_message (expected in framework)
map_url (used in our app)
gps_idle_interval_in_seconds (expected in framework)

We can set them dynamically per project via our plist in the meantime.

[seeReadCode]

Project config vals are updated from the server and accessible ( see https://github.com/seeRead/roundware-ios-framework-v2/blob/develop/Pod/Classes/RWFrameworkAPI.swift#L115 and https://github.com/seeRead/roundware-ios-framework-v2/blob/develop/Example/RWFramework/ViewController.swift#L162 ) but still need to confirm that critical booleans are observed within the framework.

[seeReadCode]

So it appears that the listen/speak booleans immediately set off their related actions after they are consumed from the server via getProjectsIdSuccess. See: https://github.com/seeRead/roundware-ios-framework-v2/blob/develop/Pod/Classes/RWFrameworkAPI.swift#L131-L145

Next I will compare with play(), stop(), startRecording() and start()

[seeReadCode]

Generally, my approach has been to have the data that comes from the GET project response be values that are likely to need adjusting during testing or deployment of an app. So things that are pretty static for the most part, I think make more sense to remain in the app's plist.

That said, startup_message used to be something that the server sent in api/1, though I don't remember specifically what the mechanism was or where it came from. It is not a field in project because this was viewed more as a server-wide feature to tell users if the server was down or otherwise experiencing issues.

I think your approach of setting them in the plist for now makes the most sense as I don't have a firm enough grasp on what will be the best ultimate approach. map_url will certainly remain in the plist for the foreseeable future, and I imagine reverse_domain will as well.

[seeReadCode]

Understood. Also, just to reiterate from the above comment https://github.com/seeRead/roundware-ios-framework-v2/issues/2#issuecomment-229509266, the project config from the server is set here https://github.com/seeRead/roundware-ios-framework-v2/blob/develop/Pod/Classes/RWFrameworkAPI.swift#L115 and then read to start speak/listen immediately after the successful GET project response here https://github.com/seeRead/roundware-ios-framework-v2/blob/develop/Pod/Classes/RWFrameworkAPI.swift#L131-L145

So I will double check that these config values are checked within play(), stop(), startRecording() and start() AND I will change the GET project callback so that it doesn't immediately call the listening or speaking functions.

Edited to clarify / be real English.

[seeReadCode]

I'm slightly confused about this. The speak/listen enabled and geo_speak/listen enabled booleans should be set based on the values received from GET project, though I assume they will have some default value specified locally in the plist as well. I'm not sure what you mean by getting positives back from the server but not wanting to turn on immediately?

[seeReadCode]

@hburgund I updated my previous comment to make more sense. Is it clear now?

[seeReadCode]

Yes, thanks, I think I understand what you are saying now and it makes sense. Please feel free to check in with @zobkiw anytime with framework questions as he knows all the history and thinking behind decisions there.