Removed forName method

[martin-morek]

• fixes 686 and 685
• Removed use of forName method in push activation state machine implementation and replaced by switch constructing Event object based on name

[QuintinWillison]

Thanks, this is a great start. However, as discussed in our call earlier today, this only presents one side of the story... I think we need to see:

• Addition of functionality that does directly the opposite of your constructEventByName static method - probably an instance method on Event, perhaps simply something like getEventName()
• Some unit tests for this class hierarchy proving:
  • that Event instances can be represented as string and then rehydrated from the same
  • that attempts to rehydrate unsupported event types (those with non-nullary constructor) throw the right exception
  • that attempts to rehydrate unknown event types throw the right exception

We need to get rid of any code that uses runtime reflection. This has to be checked by the compiler.

[martin-morek]

@QuintinWillison could you please elaborate on getEventName() method? Right now for getting event name we are using getClass().getName(), I'm not sure if this can be simplified. What we can do is define property called name for an event object and manually fill it with a value. That way when we change class name code stays functional but real name would differ.

[QuintinWillison]

Hi @martin-morek - so, the use of getClass().getName() is the crux of the issue! 😄

That method is dynamic at runtime. If the class name is different, because of obfuscation or something else outside of control as SDK developers, then that can mess things up - in particular from build to build of a application.

Each class mast vend its own serialisation name from a static string. These cannot be dynamically sourced like this.