|
None I can think off. But, this application has been a long time coming so apologies to those whom I have forgotten
This application has been a long time in gestation. It is possibly the most complex application I will ever attempt to write, it is a compound application, with 5 or 6 applications in one.
In the more modern age(circa 2014) I would probably have created this as a bundle of applications and maybe I will make them work that way next. But the basic design predates Application Bundles and there is a lot to change if I did that.
Where to begin.
This application provides Waterpolo venue infrastructure for running a game, it provides:
Wait a minute how can one IPad do all that at the same time ? It can't, this a multiIpad application!
It runs each function executes on separate iPads, that all interact via some available network, preferably a WiFi network, cooperatively to provide synchronised time displays.
For the very dexterous , you can combine the game Clock console and Electronic scoresheet onto a single iPad.
Ok, so all the displays are optional, so you could run a game with a single iPad.
But for a standard Waterpolo game setup you would need 5 iPads:
plus
This does not sound too cheap, NO but then try buying a Waterpolo game clock. Yes, it may also provide revenue for me !
Of course you might run two games at one venue, so then you would need another 5 iPads. Wouldn't they interact with each other ?
No, the application is designed to allow ten groups of iPads to operate independently on the same network(assuming the network supports that many devices).
But, I am not finished yet, there is more to the application. No, it doesn't provide steak knives !
It also provides database application to enable you to manage an entire waterpolo completion or season, you can create a draw for a division of teams, schedule the draw at venues, publish the draws, publish the results, publish divisional points ladders, publish player stats, edit the players who play for clubs in teams in divisions. In reality it is a very complex database application, and basically you have to manage seasons my way, although there is a lot of flexibility. Seasons are assumed to have a game cycle which is either weekly which suites most inter-club competitions, daily which might suit a international competition, or continuous which would suit an age championship held over a long weekend. Divisions can have a home venue for all games, split games across multiple venues, or alternatively games can be schedule a club home venues. Draws are automatically generated for all but final rounds, but the draws can be edited allowing teams to be moved to position in a draw, whether the edit will be carried over into the next round or not depends upon when you do the edit, but you can regenerate draws for subsequent rounds automatically taking into account previous edits.
It is envisioned that an organisation running a Waterpolo would have an iCloud account that all their iPads would be configured to connect too, having done that then all the iPads can have access to same database.
Providing sample data is frowned upon but because the database is complex and may users will not want to bother with managing a season, it creates "A Default Season, with a default division, default clubs, default teams and default players". There is a Setting switch to turn this off if you don't want it, it can be annoying, if you delete the "Default Season", it will be created again. The reason it is frowned on with iCloud databases, is that it creates a race condition, if the database cannot be opened in time, a second "Default Season" is created on start up. I have tried to prevent this by delaying the creation of the "Default Season" for ten seconds after the application starts, so don't rush the first time you start the application.
If you give it time to create the default season before you open the electronic scoreboard, it will load the default game, with default players, but only if this is the only defined season and only one game exists in that season. You can edit anything in a default season except the name of the season, and the things you change will not cause new things to be created next time you start the application. Otherwise you will have to find a game, or set of games from some other season and load them into the electronic scoresheet.
Notes: The PIN numbers of the default players follow their names, "A-1 Player" has a PIN of "1", "A-2 Player" has a PIN of "2". The backdoor PIN of the Default Association is 999999999 (thats 9 9's), can be used without reference to a member( of which there are none).
There is security, so if you have spent time creating a season, no unauthorised person can modify your efforts. There is also security at the club level, allowing a club authorised person to modify club specific data, members, teams, team rosters, etc. There is of course a back door, but more of that later. When you have only the default season in the database, then security is disabled, I don't care what you do to the Default Season really, but be warned if you delete it, it will come back !
The Season Manager probably has a obligation to ensure that the players who claim to play a game actually play the game.
The electronic scoresheet, allows players to sign the score sheet, yes each player gets a PIN, but it only a best effort, if you get it wrong three times the application gives up, and records what you entered. The Season Manager can check what is entered later and castigate as they see fit. The sign in also allows you to have a photo taken when you sign in, seemed like a good idea at the time, but is probably problematic from a number of perspectives, the photos are optional.
Match Officials can also sign in.
WARNING: Waterpolo is played at swimming pool, where there is water, which IPads need to be protected from. That sounds like telling you not putting your cat in the microwave, but people do that too (the cat will explode, the iPad dies less dramatically).
Associated with many many tables in the application, there is a segmented control with three values
| Select | Delete | Add |
It is used to set the select mode of the table.
This control is used consistently throughout the application and will only be described in detail once, here, using the "Association Selector" screen as an example.
Below is shown the "Association Selector" with the "Select" option chosen. When in this mode, the associated table can be used to select something for some purpose. In the case of the Association Selector the table entry is selected and the Association Selector dismissed.
In "Delete" selection mode, entries in the table can be deleted. It is a two stage process, first a red - appears on each entry.
This is illustrated bellow.
When selected, a red DELETE button is displayed with the table entry as illustrated below.
Selecting the "Delete Button" will delete the associated entry from the database, selecting another select mode will cancel the list staged of deletion.
The "Add" mode selection is a little less intuitive.
If the table is empty, then an editor of data normally presented in the Table is launched, the editor is empty of data.
If the table is not empty, then a green + appears against the each entry,
selecting the + in any entry will launch the data item editor, the editor is empty of data.
selecting the entry to the right of + will launch the data item editor, loaded with the selected table entry.
There is one exception, you cannot edit a Club or Association Position Data Item.
The Association Editor is shown below with the Default Association loaded into the editor. In this case the empty editor is the same without the data.
