Convention Identifier Introduction

[Pinselohrkater]

• Moved API_BASE_URL to buildConfig (previously remote config).
• Added CONVENTION_IDENTIFIER to buildConfig
• Re-Generated Swagger Model (apiV2* is now api*)
• Updated FCM Subscription topics to {CID} and {CID}-android (previously live-all live-android / test-all test-android - we no longer need to distinguish between live/test since CID is the new selector)
• Updated FCM Device Registration topics to include cid-{CID}, removed live (because it's ambiguous)
• Updated RemotePreferences to prefix {CID}_ to all keys
• UpdateIntent now fails when CID mismatches. Also shows toast for failure reason when triggered interactively.
• If initial update from first start (ActivityStart) fails, show dialog with reason and exit app.
• Added version & CID info to first start screen.

[Requinard]

it feels strange to lock this up by convention identifier in the URL and build. Preferably (and RESTly), a get on app.eurofurence.org/api/ would get you the versions available and then the app itself would pick which version it needs. This is a lot nicer than the current way of hardcoding these parameters

[Pinselohrkater]

it feels strange to lock this up by convention identifier in the URL and build. Preferably (and RESTly), a get on app.eurofurence.org/api/ would get you the versions available and then the app itself would pick which version it needs. This is a lot nicer than the current way of hardcoding these parameters

Locking up a build artifact against a specific endpoint is intentional and desired.

If it's just about the string concatenation of "API url follows convention of BASE_PATH + CID"... I'd be up for just having the CID in the BuildConfig and move the API base path to Firebase Remote Config instead (again).

The backend is not specifically designed for multi-tenancy, so every version (EF24, EF25, ...) is an unique instance on an unique path with a dedicated hosting process. There's currently no API on a level 'above' that would enumerate available instances, and I wouldn't want to bootstrap & introduce that just for a single operation that currently isn't any more complex than a simple string concatenation.