The source code provided with this chapter contains skeleton Apex classes shown in the UML diagrams used earlier in this chapter. In the upcoming chapters, we will flesh out the methods and logic within them. For now, deploy them into your packaging org and add them into your package. Note that once you add Apex classes, any Apex classes they subsequently go on to reference will be automatically pulled into the package. The following is a list of the Apex classes added in this chapter and the application architecture layer they apply to:
Apex class |
Layer |
---|---|
|
Visualforce Controller |
|
Apex test |
|
Visualforce Controller |
|
Apex test |
|
Visualforce Controller |
|
Apex test |
|
Apex Scheduler |
|
Apex test |
|
Race Service |
|
Apex test |
|
Season Service |
|
Apex test |
|
Contestant Service |
|
Apex test |
Note that there is one class, SeasonNewsLetterSchedule
, that requires the use of the global
access modifier. This ensures that this class cannot be deleted or renamed in future releases. This might feel restrictive, but is the key to supporting the Apex Scheduler feature in this case. As it is important when users upgrade to new versions of your package, the schedules they have defined continue to reference the code in your package.
Upload a new version of the package and install it into your test org. You should see a confirmation install summary page that looks something like the following:
3.149.250.11