Skip to content

Fix soft button object invalid states#1776

Merged
RHenigan merged 20 commits intosmartdevicelink:developfrom
noah-livio:bugfix/issue_1774
Feb 3, 2022
Merged

Fix soft button object invalid states#1776
RHenigan merged 20 commits intosmartdevicelink:developfrom
noah-livio:bugfix/issue_1774

Conversation

@noah-livio
Copy link
Contributor

@noah-livio noah-livio commented Dec 7, 2021

Fixes #1774

This PR is ready for review.

Risk

This PR adds a new public getter function to SoftButtonObject

Testing Plan

  • I have verified that I have not introduced new warnings in this PR
  • I have run the unit tests with this PR
  • I have tested this PR against Core and verified behavior
  • I have tested Android and Java SE

Unit Tests

  • testConstructSoftButtonObjectWithEmptyStateList() passes if getAttemptedToAssignEmptyStateList() returns true after an empty state list is passed to the main primary constructor and fails otherwise.

  • testAssignEmptyStateListToSoftButtonObject() passes if an getAttemptedToAssignEmptyStateList() returns true after an empty state list is passed to setStates() of an instance of SoftButtonObject that already has at least one state in its state list.

Core Tests

Tests performed by modifying a local clone of hello_sdl_android
  • Constructed an instance of SoftButtonObject with a state list containing a single state, added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • That instance along with all the other instances in the same transaction displayed successfully.
    • The app continued to function normally
  • Constructed an instance of SoftButtonObject with an empty state list, added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool stating that the state list is empty
    • That instance and all other other instances within the same transaction failed to display to the HMI
    • The app otherwise continued to function normally
  • Constructed an instance of SoftButtonObject with a state list containing a single state, reassigned the state list to an empty list using setStates(), added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool stating that the state list is empty
    • The instance did not set overwrite the old state list with the new state list
    • The app otherwise continued to function normally

SDL Core / 8.0.0 / master / 68f082169e0a40fccd9eb0db3c83911c28870f07 / module tested against: SDL Core on Ubuntu 20.04.3 LTS Virtual Machine
Generic HMI / 0.11.0 / master / 47e0ad42f05b27adff61befd864e79c2ab4b8cec / module tested against: Generic HMI on Ubuntu 20.04.3 LTS Virtual Machine

Summary

This pull request adds an if statement to SoftButtonObject.setStates() that checks if the given state list is empty and displays if it is. This PR also replaces the direct state list assignment in the main constructor with usage of setStates() to enforce the check in the constructor without writing redundant code.

Changelog

Breaking Changes
  • None
Enhancements
  • Adds a getter function to check if an empty list was passed to the instance
Bug Fixes

CLA

Make SoftButtonObject throw IllegalStateException when given empty state list
Add tests for giving SoftButtonObject an empty state list
@noah-livio noah-livio marked this pull request as ready for review December 8, 2021 18:26
Convert throwing of IllegalStateException to setting a boolean variable, printing an error with DebugTool, and returning
Changed unit tests to reflect this new intended behavior
Added a private boolean variable and public getter function to make unit testing simpler
The alternative to reading a flag to trigger tests failing is reading logs programmatically, which is more complicated and less reliable
Remove attemptedToAssignEmptyStateList and getAttemptedToAssignEmptyStateList() from SoftButtonObject
Change unit tests to reflect the removals stated above
Add testConstructingSoftButtonObjectWithNonEmptyStateList() and testAssignNonEmptyStateListToSoftButtonObject() to test normal functionality
@noah-livio
Copy link
Contributor Author

Fixes #1774

This PR is ready for review.

Risk

None

Testing Plan

  • I have verified that I have not introduced new warnings in this PR
  • I have run the unit tests with this PR
  • I have tested this PR against Core and verified behavior
  • I have tested Android and Java SE

Unit Tests

  • testConstructSoftButtonObjectWithEmptyStateList() passes if SoftButtonObject.getStates() returns null when the constructor is given an empty state list
  • testConstructingSoftButtonObjectWithNonEmptyStateList() passes if SoftButtonObject.getStates() returns the nonempty state list passed to the constructor
  • testAssignNonEmptyStateListToSoftButtonObject() passes if SoftButtonObject.getStates() returns a state list not equal to the empty state list passed to SoftButtonObject.setStates()
  • testAssignEmptyStateListToSoftButtonObject() passes if SoftButtonObject.getStates() returns a state list equal to the nonempty state list passed to SoftButtonObject.setStates()

Core Tests

Tests performed by modifying a local clone of hello_sdl_android
  • Constructed an instance of SoftButtonObject with a state list containing a single state, added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • That instance along with all the other instances in the same transaction displayed successfully.
    • The app continued to function normally
  • Constructed an instance of SoftButtonObject with an empty state list, added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool stating that the state list is empty
    • That instance and all other other instances within the same transaction failed to display to the HMI
    • The app otherwise continued to function normally
  • Constructed an instance of SoftButtonObject with a state list containing a single state, reassigned the state list to an empty list using setStates(), added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool stating that the state list is empty
    • The instance did not overwrite the old state list with the new state list
    • The app otherwise continued to function normally

SDL Core / 8.0.0 / master / 68f082169e0a40fccd9eb0db3c83911c28870f07 / module tested against: SDL Core on Ubuntu 20.04.3 LTS Virtual Machine
Generic HMI / 0.11.0 / master / 47e0ad42f05b27adff61befd864e79c2ab4b8cec / module tested against: Generic HMI on Ubuntu 20.04.3 LTS Virtual Machine

Summary

This pull request adds an if statement to SoftButtonObject.setStates() along with an identical if statement in the main constructor that throws an error and returns if the state list passed is empty

Changelog

Breaking Changes
  • None
Enhancements
  • None
Bug Fixes

CLA

import com.smartdevicelink.proxy.rpc.listeners.OnRPCNotificationListener;
import com.smartdevicelink.test.Validator;

import org.junit.Assert;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove this unused import

import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;

import android.database.sqlite.SQLiteCantOpenDatabaseException;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can remove this. unused import

* {@link SoftButtonManager}
*/
@RunWith(AndroidJUnit4.class)
//@RunWith(JUnit4.class)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can remove this comment as well

SoftButtonObject softButtonObject = new SoftButtonObject("hi", softButtonState, null);

softButtonObject.setStates(stateList);
assertNotEquals(stateList, softButtonObject.getStates());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rather than assert that these are not equal we could assert that the state on the Object is left unchanged after calling setStates.
assertEquals(softButtonState, softButtonObject.getStates)
You may want to use the constructor that takes a list for states rather than a single state. or you could make a list out of softButtonState before you make the assertion


stateList.add(softButtonState);
softButtonObject.setStates(stateList);
assertEquals(stateList, softButtonObject.getStates());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this test it may be beneficial to have stateList contain a state that is different than what was passed in the constructor. this way we are verifying the states are in fact being updated.

this.currentStateName = initialStateName;
this.buttonId = SOFT_BUTTON_ID_NOT_SET_VALUE;
this.onEventListener = onEventListener;
this.states = states;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we put this back to the same line it was previously on? this will help to reduce noise in the diff for changes that aren't really changes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you mean where it was when I was using setStates() in the constructor, I don't think I can without making the diff noisier, because now the check is happening there and the check obviously has to happen first to prevent assignment in the error case. This change is just reverting the states assignment back to how it was in develop before I forked. Maybe I could squash commits? But I think that might be more trouble than it's worth

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just move this.states = states; back under this.name= name;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh okay, will do

}
return null;
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just cleaning up whitespace

import java.util.Collections;
import java.util.List;


Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just cleaning up white space.

Remove whitespace and unused imports
Change logic of tests based on smartdevicelink#1776 feedback
Rename testConstructingSoftButtonObjectWithNonEmptyStateList() to testConstructSoftButtonObjectWithNonEmptyStateList() to match naming of related tests
Add testAssignSameNameStateListToSoftButtonObject() to test the new behavior
@noah-livio
Copy link
Contributor Author

Fixes #1774

This PR is ready for review.

Risk

None

Testing Plan

  • I have verified that I have not introduced new warnings in this PR
  • I have run the unit tests with this PR
  • I have tested this PR against Core and verified behavior
  • I have tested Android and Java SE

Unit Tests

  • testConstructSoftButtonObjectWithEmptyStateList() passes if SoftButtonObject.getStates() returns null when the constructor is given an empty state list
  • testConstructingSoftButtonObjectWithNonEmptyStateList() passes if SoftButtonObject.getStates() returns the nonempty state list given to the constructor
  • testAssignNonEmptyStateListToSoftButtonObject() passes if SoftButtonObject.getStates() returns the nonempty state list given to the constructor after SoftButtonObject.setStates() is given an empty state list
  • testAssignEmptyStateListToSoftButtonObject() passes if SoftButtonObject.getStates() returns a state list equal to the nonempty state list passed to SoftButtonObject.setStates()

Core Tests

Tests performed by modifying a local clone of hello_sdl_android
  • Constructed an instance of SoftButtonObject with a state list containing a single state, added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • That instance along with all the other instances in the same transaction displayed successfully.
    • The app continued to function normally
  • Constructed an instance of SoftButtonObject with an empty state list, added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool saying that the state list is empty
    • That instance and all other other instances within the same transaction failed to display to the HMI
    • The app otherwise continued to function normally
  • Constructed an instance of SoftButtonObject with a state list containing a single state, reassigned the state list to an empty list using setStates(), added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool saying that the state list is empty
    • The instance did not overwrite the old state list with the new state list
    • The app otherwise continued to function normally
  • Constructed an instance of SoftButtonObject with a state list containing a single state, reassigned the state list to a state list with states with duplicate names using setStates(), added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool saying "Two states have the same name in states list for soft button object"
    • The instance did not overwrite the old state list with the new state list
    • The app otherwise continued to function normally

SDL Core / 8.0.0 / master / 68f082169e0a40fccd9eb0db3c83911c28870f07 / module tested against: SDL Core on Ubuntu 20.04.3 LTS Virtual Machine
Generic HMI / 0.11.0 / master / 47e0ad42f05b27adff61befd864e79c2ab4b8cec / module tested against: Generic HMI on Ubuntu 20.04.3 LTS Virtual Machine

Summary

This pull request adds an if statement to SoftButtonObject.setStates() along with an identical if statement in the main constructor that throws an error and returns if the state list passed is empty. This pull request also adds a similar check to SoftButtonObject.setStates() for state lists containing states with duplicate names.

Changelog

Breaking Changes
  • None
Enhancements
  • None
Bug Fixes

CLA

Comment on lines +74 to +78
// If the list of states is empty, throw an error with DebugTool and return
if (states.isEmpty()) {
DebugTool.logError(TAG,"The state list is empty");
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alignment note:

On iOS I did this

BOOL hasStateWithInitialName = NO;
for (SDLSoftButtonState *state in states) {
    if ([state.name isEqualToString:initialStateName]) {
        hasStateWithInitialName = YES;
    }
}
NSAssert(![self sdl_hasTwoStatesOfSameName:states], @"A SoftButtonObject must have states with different names.");
NSAssert(hasStateWithInitialName, @"A SoftButtonObject must have a state with initialStateName.");
if ([self sdl_hasTwoStatesOfSameName:states]) { return nil; }
if (!hasStateWithInitialName) { return nil; }

The advantage this has is only throwing an exception in DEBUG builds (I don't know that is available on Java Suite). Second, this tests not only that there are states, but also that the initial state name is available. The for loop won't run if there are no states, so the boolean will just stay false. That check at least should be a part of this PR as well.

Last, I also made a change to SoftButtonState on iOS to check if both text and image are null, which is an invalid state configuration. I think that should be a part of this PR as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Understood, I'll work on implementing this

Make constructor check for valid initialStateName in state list
Adjust tests to reflect new behavior
@noah-livio
Copy link
Contributor Author

I have added the initialStateName check in the constructor, added AssertionErrors that only throw when built in debug mode, and adjusted existing tests to avoid failing for the initialStateName check. I also added a debug only AssertionError to SoftButtonState in the check for null text and image.

@noah-livio
Copy link
Contributor Author

Fixes #1774

This PR is ready for review.

Risk

None

Testing Plan

  • I have verified that I have not introduced new warnings in this PR
  • I have run the unit tests with this PR
  • I have tested this PR against Core and verified behavior
  • I have tested Android and Java SE

Unit Tests

  • testConstructSoftButtonObjectWithEmptyStateList() passes if SoftButtonObject.getStates() returns null when the constructor is given an empty state list
  • testConstructingSoftButtonObjectWithNonEmptyStateList() passes if SoftButtonObject.getStates() returns the nonempty state list given to the constructor
  • testConstructSoftButtonObjectWithInvalidInitialStateName() passes if SoftButtonObject.getStates() returns null when the constructor is given a state list that does not contain initialStateName
  • testAssignNonEmptyStateListToSoftButtonObject() passes if SoftButtonObject.getStates() returns the nonempty state list given to the constructor after SoftButtonObject.setStates() is given an empty state list
  • testAssignEmptyStateListToSoftButtonObject() passes if SoftButtonObject.getStates() returns a state list equal to the nonempty state list passed to SoftButtonObject.setStates()

Core Tests

Tests performed by modifying a local clone of hello_sdl_android
  • Constructed an instance of SoftButtonObject with a state list containing a single state, added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • That instance along with all the other instances in the same transaction displayed successfully.
    • The app continued to function normally
  • Constructed an instance of SoftButtonObject with an empty state list, added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool saying that the state list is empty
    • That instance and all other other instances within the same transaction failed to display to the HMI
    • The app otherwise continued to function normally
  • Constructed an instance of SoftButtonObject with a state list containing a single state, reassigned the state list to an empty list using setStates(), added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool saying that the state list is empty
    • The instance did not overwrite the old state list with the new state list
    • The app otherwise continued to function normally
  • Constructed an instance of SoftButtonObject with a state list containing a single state, reassigned the state list to a state list with states with duplicate names using setStates(), added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool saying "Two states have the same name in states list for soft button object"
    • The instance did not overwrite the old state list with the new state list
    • The app otherwise continued to function normally

SDL Core / 8.0.0 / master / 68f082169e0a40fccd9eb0db3c83911c28870f07 / module tested against: SDL Core on Ubuntu 20.04.3 LTS Virtual Machine
Generic HMI / 0.11.0 / master / 47e0ad42f05b27adff61befd864e79c2ab4b8cec / module tested against: Generic HMI on Ubuntu 20.04.3 LTS Virtual Machine

Summary

This pull request adds an if statement to SoftButtonObject.setStates() along with an identical if statement in the main constructor that throws an error and returns if the state list passed is empty. This pull request also adds a similar check to SoftButtonObject.setStates() for state lists containing states with duplicate names.

Additionally AssertionErrors are now thrown in these error checks when built in debug mode.

Changelog

Breaking Changes
  • None
Enhancements
  • None
Bug Fixes

CLA

@RHenigan
Copy link
Contributor

Older unit tests fail as a result of the new hasStateWithInitialName check.
Some tests are using empty lists and null or mismatched initia state names which are the states we are trying to avoid.

ScreenManagerTests.testAssigningIdsToSoftButtonObjects
SoftButtonManagerTests.testSoftButtonObjectEquals

Update SoftButtonManagerTests.testSoftButtonObjectEquals()
Update ScreenManagerTests.testAssigningIdsToSoftButtonObjects())

import androidx.annotation.NonNull;

import com.livio.BuildConfig;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove unused import


import androidx.annotation.NonNull;

import com.livio.BuildConfig;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove unused import

Copy link
Contributor

@RHenigan RHenigan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

testAssignNonEmptyStateListToSoftButtonObject is now failing, this test would need to set a list with a state that is equivalent to the currentState. We should also test to verify the negative is true as well (confirm setting a list without the currentState fails to update)

boolean hasStateWithCurrentName = false;
for (SoftButtonState state : states) {
if(state.getName().equals(currentStateName)) {
hasStateWithCurrentNameName = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
hasStateWithCurrentNameName = true;
hasStateWithCurrentName = true;

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, and that'll be easy to fix

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also to avoid confusion for the developer we will still want to set the states in the case the currentState is not present in the list, but we will still want to log the error.

We should test and confirm that the SoftButtonManager can handle this error case (trying to upload a SoftButton where the currentState is not in the list)

@noah-livio
Copy link
Contributor Author

Fixes #1774

This PR is ready for review.

Risk

None

Testing Plan

  • I have verified that I have not introduced new warnings in this PR
  • I have run the unit tests with this PR
  • I have tested this PR against Core and verified behavior
  • I have tested Android and Java SE

Unit Tests

  • testConstructSoftButtonObjectWithEmptyStateList() passes if SoftButtonObject.getStates() returns null when the constructor is given an empty state list
  • testConstructingSoftButtonObjectWithNonEmptyStateList() passes if SoftButtonObject.getStates() returns the nonempty state list given to the constructor
  • testConstructSoftButtonObjectWithInvalidInitialStateName() passes if SoftButtonObject.getStates() returns null when the constructor is given a state list that does not contain initialStateName
  • testAssignStateListWithCurrentStateToSoftButtonObject() passes if SoftButtonObject.getStates() returns the new state list given to SoftButtonObject.setStates()
  • testAssignStateListWithoutCurrentStateToSoftButtonObject() passes if SoftButtonObject.getStates() returns the new state list given to SoftButtonObject.setStates()
  • testAssignEmptyStateListToSoftButtonObject() passes if SoftButtonObject.getStates() returns a state list equal to the nonempty state list passed to SoftButtonObject.setStates()

Core Tests

Tests performed by modifying a local clone of hello_sdl_android
  • Constructed an instance of SoftButtonObject with a state list containing a single state, added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • That instance along with all the other instances in the same transaction displayed successfully.
    • The app continued to function normally
  • Constructed an instance of SoftButtonObject with an empty state list, added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool saying that the state list is empty
    • That instance and all other other instances within the same transaction failed to display to the HMI
    • The app otherwise continued to function normally
  • Constructed an instance of SoftButtonObject with a state list containing a single state, reassigned the state list to an empty list using setStates(), added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool saying that the state list is empty
    • The instance did not overwrite the old state list with the new state list
    • The app otherwise continued to function normally
  • Constructed an instance of SoftButtonObject with a state list containing a single state, reassigned the state list to a state list with states with duplicate names using setStates(), added it to a list of SoftButtonObjects, and attempted to display them to the Generic HMI using ScreenManager. Results:
    • The instance printed an error with DebugTool saying "Two states have the same name in states list for soft button object"
    • The instance did not overwrite the old state list with the new state list
    • The app otherwise continued to function normally

SDL Core / 8.0.0 / master / 68f082169e0a40fccd9eb0db3c83911c28870f07 / module tested against: SDL Core on Ubuntu 20.04.3 LTS Virtual Machine
Generic HMI / 0.11.0 / master / 47e0ad42f05b27adff61befd864e79c2ab4b8cec / module tested against: Generic HMI on Ubuntu 20.04.3 LTS Virtual Machine

Summary

This pull request adds an if statement to SoftButtonObject.setStates() along with an identical if statement in the main constructor that throws an error and returns if the state list passed is empty. This pull request also adds a similar check to SoftButtonObject.setStates() for state lists containing states with duplicate names.

Additionally AssertionErrors are now thrown in these error checks when built in debug mode.

Changelog

Breaking Changes
  • None
Enhancements
  • None
Bug Fixes

CLA

@codecov
Copy link

codecov bot commented Jan 28, 2022

Codecov Report

Merging #1776 (39efd8e) into develop (423836c) will increase coverage by 0.04%.
The diff coverage is 88.88%.

Impacted file tree graph

@@              Coverage Diff              @@
##             develop    #1776      +/-   ##
=============================================
+ Coverage      54.36%   54.40%   +0.04%     
- Complexity      5512     5521       +9     
=============================================
  Files            562      562              
  Lines          25515    25540      +25     
  Branches        3319     3327       +8     
=============================================
+ Hits           13872    13896      +24     
+ Misses         10383    10381       -2     
- Partials        1260     1263       +3     
Impacted Files Coverage Δ
...rtdevicelink/managers/screen/SoftButtonObject.java 69.42% <88.88%> (+12.12%) ⬆️
...smartdevicelink/encoder/VirtualDisplayEncoder.java 43.50% <0.00%> (-1.60%) ⬇️
...nk/managers/screen/SoftButtonReplaceOperation.java 58.33% <0.00%> (-0.65%) ⬇️
...ink/managers/screen/BaseTextAndGraphicManager.java 64.16% <0.00%> (-0.42%) ⬇️
...reen/choiceset/PreloadPresentChoicesOperation.java 35.81% <0.00%> (-0.08%) ⬇️
...java/com/smartdevicelink/proxy/rpc/TireStatus.java 88.46% <0.00%> (ø)
...smartdevicelink/managers/screen/DispatchGroup.java 92.85% <0.00%> (ø)
...rtdevicelink/proxy/rpc/GetVehicleDataResponse.java 93.70% <0.00%> (ø)
...celink/proxy/rpc/SubscribeVehicleDataResponse.java 92.37% <0.00%> (ø)
...link/proxy/rpc/UnsubscribeVehicleDataResponse.java 92.37% <0.00%> (ø)
... and 4 more

@RHenigan
Copy link
Contributor

Awaiting iOS Alignment before merging

@joeljfischer joeljfischer changed the title Bugfix/issue 1774 Fix soft button object invalid states Feb 1, 2022
Copy link
Contributor

@joeljfischer joeljfischer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also seems to be missing the changes to SoftButtonState to ensure a state never has neither text nor an image.

}
}
if (!hasStateWithCurrentName) {
DebugTool.logError(TAG, "A SoftButtonObject should have a state with currentStateName.");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
DebugTool.logError(TAG, "A SoftButtonObject should have a state with currentStateName.");
DebugTool.logError(TAG, "A SoftButtonObject setting states must contain a state with currentStateName.");

Can you also include the name of currentStateName?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is an easy change

@noah-livio
Copy link
Contributor Author

This also seems to be missing the changes to SoftButtonState to ensure a state never has neither text nor an image.

That check is already handled in the constructor of SoftButtonState

Rephrase debug output and add extra detail
@joeljfischer joeljfischer added bug A defect in the library manager-screen Relating to the manager layer - screen managers labels Feb 2, 2022
@RHenigan RHenigan merged commit 3d1e54e into smartdevicelink:develop Feb 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug A defect in the library manager-screen Relating to the manager layer - screen managers

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants