Developers: breaking changes forthcoming in 1.50.0

[Raptor399]

Unfortunately it's not possible, because we can get more information with the new method, because the old one haven't received the end of the time range, so we can call the old one, from the new, but not the otherwise.

Huh? That is strange.

Let's assume I'm a plugin writer (I'm not ).
My current code reads:

Code: Select all

InputStream is = resource.getInputStream(a, b, c, config);

This will be deprecated in 1.50, so now I want to migrate my code to the new method signature.
How do you suggest I rewrite my plugin code?

[renszarv]

Unfortunately it's not possible, because we can get more information with the new method, because the old one haven't received the end of the time range, so we can call the old one, from the new, but not the otherwise.

Huh? That is strange.

Let's assume I'm a plugin writer (I'm not ).
My current code reads:

Code: Select all

InputStream is = resource.getInputStream(a, b, c, config);

This will be deprecated in 1.50, so now I want to migrate my code to the new method signature.
How do you suggest I rewrite my plugin code?

Why strange ?
The old code is like :

Code: Select all

InputStream is = resource.getInputStream(a, b, c, config);

The new code is like:

Code: Select all

InputStream is = resource.getInputStream(a, b, c, d, config);

With the additional contraint that either a - b or c - d is specified, at most. Just the Range class encapulates either a byte-range, or a time-range.
So if you are a plugin developer, and you don't care about seeking, you don't have to do anything If you only support byte-range based seeking, you should check for Range.Byte and handle the case ... or if it is able to handle Range.Time, check for that, and handle separately.

[SharkHunter]

I'm with raptor here. Thats what I want. The reason is simple. If I need to fix a bug in a plugin now I'll have to keep track of which PMS I'm building towards etc. There are people who find this kind of logistics funny, I don't, I like the code. For that reason both signatures should be present for a transient time. The old sig should call the new just like raptor suggested, and yes it is of course possible to do that. And since constructs of this

Code: Select all

long low = range.isByteRange() && range.isStartOffsetAvailable() ? range.asByteRange().getStart() : 0;
                long high = range.isByteRange() && range.isEndLimitAvailable() ? range.asByteRange().getEnd() : -1;

is in the new code I find it really hard to believe it is impossible to do a function that creates a range out of the 3 int/doubles? Yes the functionallity will not be as good as it can be with the new method BUT it will not be worse than it was before. If no backwards compatible function is made the plugin will not work at all which is way worse than it was before.

Making changes to really core stuff like DLNAResource should in my opinion always be made 100% backwards compatible for 2-3 releases and maybe even ask on the forum if anybody is affected in a negative way by this change. It might be that the thing you like to change requires a complete rewrite of something.

[Raptor399]

To add to the list of breaking changes:

• Old occurences of DLNAResource.getId() should be replaced by the new method DLNAResource.getResourceId()

The old getId() would return something like "0$0$1$3", the new getId() returns the internal id of the resource, which is something like "3" (without parents). The newly introduced getResourceId() mimics the pre-1.50.0 getId() behavior.

We would like to make all DLNAResource instance variables private, so r962 introduces proper getters and setters for all protected variables. Please use these access methods.
The variables have been left as is to remain backwards compatible, but they will be made private in the future.

To help you find affected plugin code, all protected variables have been marked with @deprecated.

[Raptor399]

A minor breaking change is introduced in r968:

• Old occurrences of DLNAMediaLang.getLang() should be replaced by the new method DLNAMediaLang.getLangFullName().

The old getLang() would return something like "Undetermined", the net getLang() will return the language code instead, something like "und". The newly introduced getLangFullName() mimics the pre-1.50.0 getLang() behavior.