Another neat aspect of our API classes is that they are all partial classes. This means you can spread out the class definition in multiple source files. It’s very good for auto-generated code (like with web services) because you can have code that you control in one file while the auto-generated code stays in another file.
Again, there are many uses for this concept. For example:
- You can add properties.
- You can add methods.
- You can implement additional interfaces.
- You can override the Invoke method and create a single point for all your API calls to flow through.
My last point is probably the most useful. For a given service, all API functions flow through the Invoke method. By overriding that method, you can have a common spot to put code. For example, you can…
- Handle errors in a generic way, such as popping up a dialog.
- Log each API call.
- See how long an API call takes to complete.
- Put in fixes for specific errors, such as error 300.
This is a good time to talk about error 300, because overriding the Invoke method is the only good way I know of to handle it. Error 300 means that the authentication token is invalid. Usually it occurs because that server changes its encryption key, which happens periodically and without warning. In other words, error 300 can happen, without warning, at any time while your program is running.
The best thing to do is to re-authenticate and run the command again. Thanks to partial classes, it isn’t too hard.
namespace // TODO: set namespace same as service class
Namespace ' TODO: set namespace same as service class