Migrate to null-safety

[tiholic]

• lib
• test
• example
• test_integration

[ben-xD]

Hi @tiholic :)

Could you explain the process that you took to migrate to null safety? That would be interesting and useful to know.

I notice there a lot of usages of optionals, and I wanted to see if they're necessary (though it will require some work to find out which fields need to be optional). For example, all the fields of Message are optional, but isn't id and timestamp (and others) always known? An example of useful information for investigation is TM2.

• There are many states that e.g. Message can be in if we make all the fields optional. This makes it complex to construct and handle.
• Reducing the usage of optionals is useful to avoid having to unwrap optional. In fact, it might make code more verbose because optional cases need to be handled even if they do not happen in reality. This tempts the developer to use ! and just implicitly unwrap it dangerously.

Another example is AblyMessage, which is used to communicate between platform and dart. If we require (non optional) handle and type, that would make the usage of this stricter, and so on the other side of the message, we can guarantee the data to be there.

TLDR: Though we don't have compilation failures and we used the migration tool, there could be a lot of improvements because our models are too flexible, we may be abusing nullability by using ? too much.

[tiholic]

Hey @ben-xD!

I followed this guide first to auto migrate https://dart.dev/null-safety/migration-guide, then looked into each of the implemented APIs (channel publish, subscribe, history, paginated results, etc). While I may also have touched few areas that are not implemented, we need to ensure they are appropriate while implementing them as per the spec.

For example, all the fields of Message are optional, but isn't id and timestamp (and others) always known?

A message can be received (read) or published (created). So fields like id and timestamp are not always expected to be present. An alternative would be to have different models for read and write (deviates from spec).

As you may have understood by now that AblyMessage.type only comes into play when we have generics involved, and handle is not always necessary (refer to usages).

As many languages do not have support for null safety, it might not have been considered while building the SDK developer docs to flag which property of a model is nullable and which is not.

[QuintinWillison]

This is very difficult to review line by line, but looks sensible to me.

[ben-xD]

LGTM with comments

[ben-xD]

The failing tests have been disabled and are successfully passing (on most occasions) in #144. I'm merging this in now even though the tests fail, because the test disabling PR depends on this one.