Bug #415

Model Alarm compare will return true if model has no alarms

Added by Hans Cappelle over 5 years ago. Updated over 5 years ago.

Status:ClosedStart date:04/27/2012
Priority:NormalDue date:
Assignee:Android Dashboard Developers% Done:

100%

Category:-Spent time:-
Target version:2.5 Maintenance

Description

Not sure if this is intented or not. On the compare methods for the alarms between the module and the model the default value is true so if no channels are to be compared this method will still return true. I did refactor the method but respected this behaviour. I believe it's better to return false if model has no channels.

Also if no model is set it would still return true. That could be desirable not to cause any warnings when nog model active yet.

Methods in question:

FrSkyServer.alarmSameAsModel(Model):boolean
FrSkyServer.compareAlarms():void

Associated revisions

Revision 456
Added by Hans Cappelle over 5 years ago

closes #415 adding comments about default alarms

History

#1 Updated by Espen Solbu over 5 years ago

compareAlarms() is only called after recording of alarms have happened and the list of incoming alarms (_alarmMap) is complete. (initiated from recordAlarmsFromModule())
alarmsSameAsModel() iterates the incoming alarms and not the models alarms, checking for each of the incoming alarms if it exists in the model. If one of the incoming alarms does not exist in the model, it will return false, covering the scenario of the model not having alarms (model.getFrSkyAlarms().containsValue(a) should cause this to return false

If no model is set, i guess you mean that there is currently no _currentModel. The check in compareAlarms skips the entire thing if there is no _currentModel. (compareAlarms() does not return anything)

I am not sure that this is the best way, but i think your scenarios are already covered.

#2 Updated by Espen Solbu over 5 years ago

I was incorrect, it did indeed not flag "mismatch" if model had no alarms.

It has been fixed on another level (alarms are intialized in model ctor, so that a model will always have alarms).
I am not sure if this then needs to be fixed.

#3 Updated by Hans Cappelle over 5 years ago

  • Status changed from New to In Progress
  • Assignee set to Android Dashboard Developers
  • % Done changed from 0 to 90

Espen Solbu wrote:

I was incorrect, it did indeed not flag "mismatch" if model had no alarms.

It has been fixed on another level (alarms are intialized in model ctor, so that a model will always have alarms).
I am not sure if this then needs to be fixed.

I agree this also closes this issue. Just add this information to code and ticket can be close for me (or let me know I can update code).

#4 Updated by Hans Cappelle over 5 years ago

Hans Cappelle wrote:

Espen Solbu wrote:

I was incorrect, it did indeed not flag "mismatch" if model had no alarms.

It has been fixed on another level (alarms are intialized in model ctor, so that a model will always have alarms).
I am not sure if this then needs to be fixed.

I agree this also closes this issue. Just add this information to code and ticket can be close for me (or let me know I can update code).

if editing this also adapt no args Model() ctor to use DEFAULT_MODEL_NAME =>

    public Model() {
        this(Model.DEFAULT_MODEL_NAME, "");
    }

#5 Updated by Espen Solbu over 5 years ago

You can change the code if you wish

#6 Updated by Hans Cappelle over 5 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

Applied in changeset r456.

Also available in: Atom PDF