[micaww]

Hey everyone. I am familiar with both Interfaces#getAt and Interfaces#newQuery methods of finding an Interface on the screen.

My question is, is it considered bad practice to retrieve either an Interface or InterfaceComponent directly by it's ID? I read in another thread that Interfaces#getAt will be deprecated soon (@Cloud). Also, what is the reason for this? The only reason I could figure is that the IDs are possibly dynamic and that hardcoding them can be unreliable.

Getting an interface by its ID should have a lower time-complexity than querying for it every time an interface is needed, if not cached. So performance wise, using direct IDs would be preferable if as accurate as querying.

Would a viable workaround be to query for an Interface by text, get it's container ID, and then choose another child component from that container via getComponent(#)?

Thank you for clarifying.

 

[derk]

You can still gather interfaces based on ID's with the querying system using the .ids() filter. But yes, it's frowned upon. Not only interfaces, for that matter, just generally using ID's for initializing variables. Use it only if you really can't do it without using other filters such as .names(), .texts(), .size(), etc etc... The main reason for not using ID's is that ID's are very prone to change on updates, while text in the interfaces or the interface names are not. If the speed of loading an interface using ID's, sure you can use it. But how often is it more important to sacrifice milliseconds opposed to keeping maintainability at a high level? Speed isn't really of the essence in most cases, as a bot should mimic a legit user as much as possible. So whether it takes 100 milliseconds longer isn't relevant, I'd say.

Perhaps there's more reasons as of why it's frowned upon, but this is the main reason I was taught it to be.

 

[micaww]

Thanks @Bertrand. The evaluation speed isn't really a concern, especially when botting, I agree. I guess my biggest concern is finding the most reliable way to locate a dynamic text interface in a given container. Thanks for the response!

 

[party]

It's not frowned upon to specify a container ID, as it increases the speed at which the query returns.

 

[micaww]

@Party how's it going? Are you saying that container IDs are very unlikely if never to change? That would boost performance tremendously and narrow down the results I want to see.

Or are you saying that I should first query for the container and then use that ID to find the text view I'm actually looking for?

 

[party]

@Party how's it going? Are you saying that container IDs are very unlikely if never to change? That would boost performance tremendously and narrow down the results I want to see.

Or are you saying that I should first query for the container and then use that ID to find the text view I'm actually looking for?

Very unlikely to change. If they do, it's one ID that needs to be changed. The difference is that when you don't supply a container ID, the query searches all InterfaceComponents, whereas supplying one narrows the search to components within that container.

eg. Interfaces.newQuery().containers(1337).texts("blah").results() executes faster than Interfaces.newQuery().texts("blah").results(), whilst also being more specific.

 

[infinite inferno]

i despide using ID's for anything, as can be found in the dev chat, but specifying container id's yields the result in 1/10 of the time that it would take normally, even if you specify, name, color, etc etc. Containers are the only id's when it comes to interfaces which are not prone to change frequently.

 

[micaww]

Perfect, just what I needed to know. Thank you guys