Иван Курнаков

С ретрофитом вы наверняка используете какую-нибудь ConverterFactory для преобразования ответа в объект. Например, GsonConverterFactory (GSON). Рассмотрим ситуацию на его примере:
Все объекты описываете как обычно, кроме msg. Его описываете как интерфейс Message. Регистрируете:

class MessageDeserializer implements JsonDeserializer<Message>{ ... }
...
Gson gson = new GsonBuilder()
                .registerTypeAdapter(Message.class, new MessageDeserializer())
                .create();
GsonConverterFactory.create(gson);

В методе

public Message deserialize(JsonElement json, Type typeOfT, JsonDeserializationContext context) throws JsonParseException { ... }

Десериализуете msg на основе тех данных, которые есть (надо научиться различать разные типы msg). Кладёте данные в разные реализации Message, например для {'txt':''} делаете такую реализацию:

class MessageTxt implements Message {
    private final String txt;
    public MessageTxt(String txt){
        this.txt = txt;
    }
    String getTxt() { return txt; }
}

Сам интерфейс Message может вообще не содержать методов (маркерный интерфейс) или содержать общие для всех типов msg методы, или дополнительно содержать метод для возвращения типа. Как-то так я бы поступил, видимо. Разные реализации Message потом можно просто проверять instaceof и кастовать.

Насколько я понимаю, плохо – это когда разница между минимумом и максимумом очень большая, хорошо – когда эта разница маленькая (по крайней мере на конце графика). Также имеет значение гладкость.

Я вижу здесь два варианта решения:

1. Описательный.
Вы сами формулируете критерии "хорошести", и находите способ её измерения. То есть нужна функция L: "множество функций" -> [0, 1], и если L(f) = 1, то график f хороший, если L(f) = 0, то график f плохой.

2. Машинное обучение.
Здесь вам всё равно нужно описать какие-то критерии функции, и для каждой функции соорудить вектор-признак. Например, вектор-признак может содержать информацию (значение максимума; значение минимума; разность между макс и мин; какой-то показатель гладкости (может быть вычислить производную в каждой точке, и смотреть чтобы производная менялась не сильно); площадь подграфика и т.п.).
Затем, собираете выборку графиков, для них получаете выборку векторов-признаков, и дальше можете использовать алгоритмы классификации: логистическая регрессия, нейронные сети, SVM и т.п. Успех данного подхода зависит от того, насколько хорошо придуманный вами вектор-признак будет описывать ваши же критерии.
Результатом будет та же функция L: "множество функций" -> [0, 1], только, возможно, вы не сможете осмыслить её работу (не будет словестного критерия, как в п.1), но она также будет выдавать на выход является функция хорошей или плохой.

Тут нужно определить критерии "плохой\хороший", потому как по графикам не особо заметно разницы, нужно понимать, что если результат не очевиден человеку, объяснить это компьютеру будет еще тяжелее.
Если таких критериев нет нужно их найти, что можно следать:

1. Отобрать как можно больше "плохих" графиков и отдельно "хороших"
2. Нормализовать, то есть привести их виду, где минимальное и максимальное значение по осям будет одно и тоже (если конечно нет критерия вида много по Y - плохо и т.п.)
3. На нормализованной плоскости построить сплайн или просто сразу апроксимировать функции таким образом чтобы получить для каждого графика одинаковый набор значений y для одних и тех же X, к примеру на нормализованной плоскости через каждые n единиц по X получить значение Y.
На выходе получится матрица Xmax*Ymax, где каждой на пересечении будет 1 либо 0
Данные матрицы можно использовать для обучения нейронной сети.

или матрицы не строить а оставить в виде последовательности значений Y, потом сравнивать вектора "плохих" графиков с векторами "хороших",
для сравнения можно будет использовать все что в голову взбредет, то есть любые математические функции, какая ни будь даст достаточно статистически различимый результат. Кстати полученное на п.2-3 можно использовать и для кластеризации.

К предыдущему ответу я бы еще добавил что в зависимости от задачи можно элементы наследовать от INotifyPropertyChanged. Что бы при изменении элементы коллекции шло уведомление в UI.
И да, вариант описанный вами не единственный, но вполне имеющий право на жизнь в проекте. Изучайте эту тему дальше.

1. Класс ObservableCollection уже реализует интерфейс INotifyPropertyChanged.
2. Вы не правильно вызываете метод NotifyPropertyChanged. В качестве параметра должно передаваться имя свойства, которое было изменено. Т.е. должно быть так
NotifyPropertyChanged("Lenght");
3. Правильнее писать Length, а не Lenght