b393c08c067ea6c25a8d943cf971b4f126e47ed5
wiki/racecommittee-app.md
| ... | ... | @@ -25,7 +25,13 @@ The Feedback a User gave to the Application and the Feedback the user gave to th |
| 25 | 25 | |
| 26 | 26 | ## Course Updates |
| 27 | 27 | |
| 28 | -Kuruh, Kuruh,... |
|
| 28 | +The app has several course designer varying in their input method and output: |
|
| 29 | + |
|
| 30 | +* **By-Name** Course Designer: just setting the name of a _CourseBase_ object with no waypoints |
|
| 31 | +* **By-Map** Course Designer: just setting the name of a _CourseBase_ object with now waypoints |
|
| 32 | +* **By-Marks** Course Designer: full _CourseBase_ object with waypoints |
|
| 33 | + |
|
| 34 | +The _CourseBase_ is attached to a _RaceLogCourseDesignChangedEvent_. On the server the _TrackedRace_ attached to the race log will forward such events to the _TracTracCourseDesignUpdateHandler_. If activated this handler will forward the _CourseBase_ object (regardless of whether its has waypoints or not) to **TracTrac**. |
|
| 29 | 35 | |
| 30 | 36 | ## RaceState |
| 31 | 37 | |
| ... | ... | @@ -69,30 +75,64 @@ This chain continues until the _RacingProcedure_ detects that there are no furth |
| 69 | 75 | |
| 70 | 76 | ### Adding a new racing procedure |
| 71 | 77 | |
| 72 | -Ja. |
|
| 78 | +When adding a new racing procedure you should start by basing your work on one of the existing ones. Have a look at the basic countdown racing procedure to see the most simplest. The brave ones base their work on the gate start procedure. |
|
| 73 | 79 | |
| 74 | -## Configuration |
|
| 80 | +A working racing procedure needs the following: |
|
| 81 | +1. A new type in _RacingProcedureType_ |
|
| 82 | +2. An implementation of _RacingProcedure_ |
|
| 83 | +3. A _RacingProcedureConfiguration_ field in _RegattaConfiguration_ (see below on how to do this) |
|
| 84 | +4. App UI - just extend _RaceInfoFragmentChooser_ and you'll see what you need |
|
| 75 | 85 | |
| 76 | -intro-text verweis zu admin-guide |
|
| 86 | +## RaceLog priorities and authors |
|
| 77 | 87 | |
| 78 | -### Adding a new configuration option |
|
| 88 | +TODO. |
|
| 79 | 89 | |
| 80 | -DeviceConfiguration vs RegattaConfiguration |
|
| 81 | -merge |
|
| 82 | -PreferenceScreen and AppPreferences |
|
| 90 | +## Build and Auto-Update |
|
| 83 | 91 | |
| 84 | -## RaceLog priorities and authors |
|
| 92 | +When build by Maven the resulting APK of the RaceCommittee App will be made available as static content on the server's web page. |
|
| 93 | + |
|
| 94 | +The RaceCommittee App is set up as an optional dependency of the bundle **com.sap.sailing.www**. This way the app will be build before the www-bundle. After the install phase the RaceCommittee App bundle will copy its artifact APK into _com.sap.sailing.www/apps_. The contents of this folder are packaged into the **com.sap.sailing.www** plugin, which will be deployed as the server's web page. When build with _buildAndUpdateProduct.sh_ an additional version information file is stored alongside the APK. Version information is taken from the AndroidManifest.xml (**android:versionCode**). |
|
| 85 | 95 | |
| 86 | -Bruuuum. |
|
| 96 | +On synchronizing the connection settings (see [[administrator's guide|racecommittee-app-administrator]]) the RaceCommittee App downloads the version file to determine whether it should update itself or not. The file is expected to be found on _{SERVER_URL}/apps/{APP_PACKAGE_NAME}.version_ (e.g. _http://ess2020.sapsailing.com/apps/com.sap.sailing.racecommittee.app.version_). If the version file is not found, no update will be performed. |
|
| 97 | + |
|
| 98 | +See the next section about versioning. |
|
| 87 | 99 | |
| 88 | 100 | ## Versioning |
| 89 | 101 | |
| 90 | -Baruh |
|
| 102 | +The app's version is defined in its AndroidManifest.xml in the **versionCode** attribute. This version code is used by several components: |
|
| 91 | 103 | |
| 92 | -## Build and Auto-Update |
|
| 104 | +* Android OS for standard versioning operations |
|
| 105 | +* Helper-Class **PreferenceHelper** to determine whether a refresh of the stored preferences is needed |
|
| 106 | +* Auto-Update feature (see above) |
|
| 93 | 107 | |
| 94 | -On Maven builds the resulting APK of the RaceCommittee App will be made available as static content on the server's web page. |
|
| 108 | +This leads to the following situations, in which one should bump the **versionCode**: |
|
| 95 | 109 | |
| 96 | -The RaceCommittee App is set up as an optional dependency of the bundle **com.sap.sailing.www**. This way the app will be build before the www-bundle. After the install phase the RaceCommittee App bundle will copy its artifact APK into _com.sap.sailing.www/apps_. The contents of this folder are packaged into the **com.sap.sailing.www** plugin, which will be deployed as the server's web page. When build with _buildAndUpdateProduct.sh_ an additional version information file is stored alongside the APK. Version information is taken from the AndroidManifest.xml (**android:versionCode**). |
|
| 110 | +1. You feel like you have achieved something remarkable. |
|
| 111 | +2. You have added or changed the type of a preference (see below for a walk-through on how to add a new preference option). |
|
| 112 | +3. You have made non-backwards-compatible changes to the app<->server interface. This includes changes to serializers/deserializers, changes to servlets,... |
|
| 113 | +4. You want to trigger the auto-update because you customized the app for the current event. |
|
| 114 | + |
|
| 115 | +## Configuration (or Preferences) |
|
| 116 | + |
|
| 117 | +Configuration of the app is crucial for the app to function properly. See the [[administration guide|wiki/racecommittee-app-administrator]] on how to it is done. The main idea is, that all configuration options are editable on the app via the Android standard preferences interfaces. Still most of the configuration should be configurable on the server. |
|
| 118 | + |
|
| 119 | +The app fetches its **DeviceConfiguration** on logon. This overall **DeviceConfiguration** is merged with configuration that is stored on device. Additionally each regatta can have a specific **RegattaConfiguration** attached to it. A regata-specific RegattaConfiguration is merged with the overall **DeviceConfiguration**. |
|
| 120 | + |
|
| 121 | +### Adding a new configuration option |
|
| 97 | 122 | |
| 98 | -On synchronizing the connection settings (see [[administrator's guide|racecommittee-app-administrator]]) the RaceCommittee App downloads the version file to determine whether it should update itself or not. The file is expected to be found on _{SERVER_URL}/apps/{APP_PACKAGE_NAME}.version_ (e.g. _http://ess2020.sapsailing.com/apps/com.sap.sailing.racecommittee.app.version_). If the version file is not found, no update will be performed. |
|
| ... | ... | \ No newline at end of file |
| 0 | +The following leads you to the process of adding a remote-configurable configuration option. The text assumes you are adding the configuration option to _DeviceConfiguration_. The process of adding an option to _RegattaConfiguration_ or one of the _RacingProcedureConfigurations_ is very similar. |
|
| 1 | + |
|
| 2 | +1. Device-Local Configuration |
|
| 3 | + 1. res/xml/preference_xxx.xml add preference (check com.sap.sailing.racecommittee.app.ui.views) and define title and summary in localization files |
|
| 4 | + 2. res/values/preferences.xml define key string and default value - this default value will be set on first start (or version change!) |
|
| 5 | + 3. If needed initialize your preference in _com.sap.sailing.racecommittee.app.ui.fragments.preference.YourPreferenceFragment_ (keep in mind: default value will be set automatically) |
|
| 6 | + 4. If your preference needs to accessed from app code this should be done through the helper class _AppPreferences_ -> create getter (and if needed setter) in _AppPreferences_ |
|
| 7 | +2. Exposing the option on the server |
|
| 8 | + 1. Add a getter for your option to _DeviceConfiguration_ |
|
| 9 | + 2. Implement the getter and a setter in _DeviceConfigurationImpl_ |
|
| 10 | + 3. Modify the _DeviceConfigurationImpl#clone_ method (for _RegattaConfiguration_ or one of its items you need to extend the merge method too) |
|
| 11 | + 4. Teach the _com.sap.sailing.racecommittee.app.domain.configuration.PreferencesDeviceConfigurationLoader_ how to load and store your setting from/to AppPreferences (for RegattaConfiguration you should extend com.sap.sailing.domain.base.configuration.impl.EmptyRegattaConfiguration too) |
|
| 12 | + 5. Modify the configuration's serializer and deserializer (good news: they are used for persistence, but don't tell anyone) |
|
| 13 | + 6. Integrate your new option in the GWT UI (Extending the existing DTOs and Dialogs) |
|
| 14 | + |
|
| 15 | +If feel the need to add a new category of preferences (i.e. adding a new preference fragment in res/xml/preference_xxx) be sure to modify _PreferenceHelper#resetPreferences_ to incorporate your new screen. |
|
| ... | ... | \ No newline at end of file |