I know that the topic is looking super strange but I've got from previous developer very strange approach for developing menu. The Menu Items is in Statical Structure and it's spreaded through a lot of classes and it's defined in global scope. Something like this:
static const struct {} Struct[] = {
Item1, Item2, Item3
}
Is there any way to assign this structure dynamically? I need this structure make dependable on language parameter.
The class that is making this view inheriting UICollectionViewDelegate, UICollectionViewDataSource and UICollectionViewDelegateFlowLayout.
There is nothing strange about the approach if the Menu Items are relatively static which in many UIs that could be the case and that was the requirements for the previous developer.
You will have refactor the code. Perhaps the references to the struct menu items can remain intact but the struct can no longer be a constant.
Related
I'm trying to figure out the best way of making my Page Objects simple, and whether to put absolutely all logic elsewhere. And whether all Selenium code/functionality should be in the Page Object, or in the Step Definition methods I use to access it.
I have the following structure:
Cucumber.feature files
Given blablabla
Java/Kotlin step definitions
#Given("^blablabla$") {
}
And the page object files
fun getOwnerFields(): MutableList<WebElement> {
return driver.findElements(By.if("owner-fields")
}
As a simple example.
Now, what I cannot come to an agreement with myself on, or find much of other's opinions about, is:
Should I do page actions - for instance, a button click, in the Step Definition class OR in the Page Object?
This:
#Given("^I click on the Next button$") {
startPage.nextButton().click()
}
PO:
fun nextButton(): WebElement {
return driver.findElement(By.id("next-button")
}
Or:v
#Given("^I click on the Next button$") {
startPage.clickNextButton()
}
PO:
fun clickNextButton(): WebElement {
return driver.findElement(By.id("next-button").click()
}
I've tended to think that it's best to keep all the page and selenium code in the Page Object. But in cases like this, it makes the PO bigger, because I'll need different methods for clicking, checking for visibility, counting etc. While if all this is done in the step definitions, the PO can practically contain nothing but getters and setters for the page elements.
Anyone got any light to shed? I know it's not THAT important, but I tend to be quite occupied with the best and/or cleanest way of organizing my code.
This is indeed opinion based question. It depends on the bunch of factors including what your app can and how flexible the user interaction is assumed to be.
As to me since your core abstraction is assumed to be on Gherkin statement level I would say I does not make sense to put a lot of abstraction on lower levels.
Button is not that good example actually because normally you only can click it so there would hardly be other types of interactions. But for other elements my choice would definitely fall on your first approach.
Such the approach would let you to concentrate on the logic that is specific for the step so that being in the step definition you can clearly see what's happening there without extra navigation through the classes.
my question is, what is the best way to let a child class communicate with the parent class.
For example:
I have a main class simply called Main, and another class SomeClass.
Now the Main class creates an instance of SomeClass, once the state of the SomeClass-object changes, the Main class should execute different code, depending on what changed.
Yeah I know, that already sounds like the Observer design pattern, but how would I implement it with state changes treated differently?
I'm currently writing an Android app with a database to make it more specific.
In my project I have the main class, a class to connect, read from/write to the database and a GUI container class. (oversimplified, there are a few more)
The main class creates an instance of both the GUI and database class.
Now if I press a button A, it should write A-data to the database,
if I press button B, it should write B-data to the database.
As I think that a gui class shouldn't have direct access to the database, I tried other options, than just accessing the database from the gui-class
Currently, I defined a placeholder abstract class with only one method, that I am just overwriting with the functionality.
So right now I have to create a one-method-class A for the click of button A and a one-method-class B for the click of button B.
It doesn't sound like the best way to me, I mean It's working, but I'd like to improve my code, so if you have any idea, please write your solution. :)
As a good practice it is better to avoid write code in GUI class. So we can use MVVM pattern here.
Let me show a simple example for your case. This is a ViewModel class. View model does not have reference to view class:
public class YourViewModel
{
public void LoadA()
{
// here you can interact with your database
}
public void LoadB()
{
// here you can interact with your database
}
}
This is your view class. It handles button clicking, user interactions with view and forwards to the view model. It has a reference to view model.
public class YourView
{
YourViewModel yourViewModel;
public YourView()
{
yourViewModel = new YourViewModel();
}
public void ButtonA_Handler()
{
yourViewModel.LoadA();
}
public void ButtonB_Handler()
{
yourViewModel.LoadB();
}
}
If you want to handle many events, then you can try to use this approach How to: Handle Multiple Events Using Event Properties.
It seems like a good way to approach this would be to use a pattern like that described in this previous Stack Overflow answer.
They provide sample implementations there but to apply to your case, you don't need to give the GUI direct access, you can have a parent class which implements the "listener" functionality, and a child (GUI) class which just calls its parent, with those details abstracted away from the child.
If you feel like you need more details/examples on implementing this pattern see https://refactoring.guru/design-patterns/observer/java/example
I'm following the Page Object model approach. I’m working on implementing a SearchResultsPage where a bunch of search results are displayed. In thinking about this page, I would like to implement it in such a way that it would support a getSearchResultByIndex(int index) method. Ideally, I would like the return type of this method to be a SearchResult, which would be a mini-page object (aka panel) that encapsulates the functionality found on a search result item since there are a number of attributes of a search result that the user can interact with. I don’t see how to accomplish this though. I was hoping to find a method like PageFactory.initElements() that would take in the WebDriver, a WebElement or selector (that identified an individual search result), and an instance of my SearchResult, but haven’t seen anything.
For clarity. Here's the basic structure of a SearchResults page.
<div class="searchResultsContainer">
<div class="searchResult">various internal fields to interact with/inspect</div>
<div class="searchResult">various internal fields to interact with/inspect</div>
...
<div class="searchResult">various internal fields to interact with/inspect</div>
</div>
It seems like this has to be a common problem out there that people have solved. I've used this "panel" notion for other common page elements like header, footer, etc, but never in the case where multiple instances of the same panel type are on the same page.
Any thoughts would be appreciated. Thanks.
If it were me I would approach it differently. I would split this into 2 page object classes. One for SearchResults, and one for SearchResultPage. The SearchResults would be the generic results list and actions you can take on those results. Within that class you would add a method to click on an individual search result, to pop up the details of that result, that would be what returns your SearchResultPage object.
Here is a rough sketch of what that method could look like inside your SearchResults page object. Not sure what language you are using but this is in C# (Java would be similar, Python much different but you'll get the general idea):
public SearchResultPage GetSearchResult()
{
// do something to click and show search details
return new SearchResultPage(_driver);
}
And then a skeleton of the SearchResultPage class object itself:
public class SearchResultPage
{
IWebDriver _driver;
// add whatever elements you want to work with specific to that single record view
//constructor
public SearchResultPage(IWebDriver driver)
{
_driver = driver;
}
// add whatever methods you want to interact with the elements in that view
}
The good thing about keeping the page objects separate in this case is SearchResults could actually be used in other areas of the application as well, if there are results on other pages that use the same elements etc. I find myself taking out common page elements (drop down menus, grids, etc) into their own objects all the time. Otherwise you end up repeating a lot of code if you stick to strict Page Object model where common functionality exists on multiple pages.
I think I've got this solved. I ended up abandoning PageFactory.initElements(), which I think I've learned is really key and likely an old-school way of implementing the page/object model. Adopting the use of By rather than FindBy seems to work much better as long as the appropriate conditional WebDriverWait.until(ExpectedConditions.elementToBeClickable(elementLocator)) is used.
After coming to this understanding, introducing the concept of a panel locator in my base Panel class allowed me to combine that locator with a nth-of-type(idx) locator to get things wired up and working as expected. Here's a simplified example of that in use in my SearchResultsPage:
public SearchResult getSearchResult(int idx) {
SearchResult res = new SearchResult(getWebDriver(),
By.cssSelector(".searchResultsContainer .seachResult:nth-of-type(" + idx + ")"));
return res;
}
My SearchResult class then just has a number of By locators defined that essentially call new ByChained(panelLocator, locator);
So glad to have solved this!
A Java class has properties and methods for manipulating those properties. An ExtJS class has properties, methods and configOptions.
Conceptually, what is the difference between configOptions and properties? Why we need both?
As per my understanding…
configs - are passed in the constructor, which defines behavior of the class, configs should not be changed at run-time because it will not have any effect, suppose you need to specify a title for the panel then you can add a config e.g. { title : 'some title' } that will be used by panel to set title of the panel at render time, but after that, even if you try to change title, you can't alter the property by simply changing that config option.
properties - are used to store information which is useful for that class, this is normally not passed through constructor but should have getter and setter methods, you can change property at run-time (if setter method is defined) and class object should detect this change, there can be read only properties also which are modified by class object only we shouldn't change it all.
More Info
Sencha: Properties vs Configs, in the Ext 4 Documentation
My answer to this question is a little simplistic and idealistic. I'm afraid trying to give a full answer that covers all the subtleties is more likely to add to the confusion rather than clarifying the situation.
Config options are used to configure an object when it is created. Trying to set them as properties on the object after it has been instantiated will often have no effect.
Ext.create('Ext.panel.Panel', {
// config options go here
});
An object will have lots of properties but only the ones listed in the Properties section should be considered public properties. While there's nothing to stop you accessing the private properties you should only do it as a last resort, try to use the documented methods to manipulate them instead where possible.
// rendered is a public property used to indicate whether the panel has been rendered
if (panel.rendered) {
// could just do panel.el but that isn't a public property, so use getEl instead
var el = panel.getEl();
...
}
One reason why the lines get blurred is that objects generally copy their configs onto themselves like this:
Ext.apply(this, config);
This results in all the config options becoming private properties, at least initially. Internally classes can then manipulate those properties as appropriate but externally accessing those properties is a breach of encapsulation and should be avoided.
When generating setters and getters in Eclipse one of the options is to use the getters and setters within the class rather than accessing the class members directly. Is this level of class internal encapsulation useful or is it taking a good idea one step too far?
DUPE: Should you use accessor properties from within the class, or just from outside of the class?
I think it's a good idea if you want the potential side-effects to occur - validation, logging etc. (In C# I'd like to be able to declare a variable and property and say that the only access to the variable is through the property.)
Occasionally you may well find you need to set the variable directly precisely because you don't want the side-effects. For instance, you may need to set two variables together, and both the "before" and the "after" states are valid, but setting either property individually would make validation blow up.
It can be useful, if you allow derived classes to re-define your getters. So, using getters even from inside the class will keep your design extensible.
In my opinion this is something that needs to be defined in the coding guidelines.
The short answer is "it depends" :)
Eric Lippert has an excellent article on Automatic vs. Explicit properties that deals with this issue, albeit from a slightly different angle.
Essentially, the question you need to ask is:
"From within the class, [are] the desired semantics of accessing this ... property different from the desired semantics of accessing the property from the outside?"
If the semantics are the same, your class should use its own properties. If the semantics are different, your class will need to directly manipulate the backing fields.
It's useful for example when you have setters which do extra actions like setting a dirty flag or notifying observers.
For getters you may instead of accessing a field compute a value when you change representation.
When you need to extend the getter/setter behavior of a class, it is useful have encapsulated fields (getters/setters instead of direct member access).
Yet in inheritance, it is conceptualy interesting to preserve the inners of your class, if its subclasses shouldn't be aware of its private stuff. So, sometimes the field is private to the implementation of a class, so that even the subclasses aren't aware of it.
I find that I do that at times - specifically when I require, or strongly anticipate that I'll require, some login around getting or setting (and the validation around them) of members.
I find that having private/internal properties does help in these cases.
But I certainly not do it for any memeber.
Latest .NET/VS really helps here as you can declare a property as such:
public string SomeProperty
{
get;
set;
}
and it effectively creates the memebr behind the scene. I know that doesn't help you, but I thought it might be of some interest :-)
If you want for this member to be databindable by either Winform or WPF, I believe that you need to declare it as a property. I'm about 95 percent positive that databinding requires a property (getter/setting syntax). I have a small wpf solution that demonstrates this, but I don't see a way to attach it here.
Here's the code: (built with VS 2008 SP1, targeting .net 3.5 - I used a WPF Project).
There are 2 items in the WPF project, the main window (window1), and the object that we are testing (DataObject)
There is a label on the window that is databound to the Name property in an instance of data object. If you convert the Name property to a field (remove the getter/setter), the databinding will stop working.
Window1.xaml:
<Window x:Class="WpfDatabinding.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1" Height="300" Width="300">
<Grid>
<Label Name ="Label1" Height="28" Margin="12,24,37,0" VerticalAlignment="Top" Content="{Binding Name}"></Label>
</Grid>
Window1.xaml.cs
using System;
using System.Windows;
namespace WpfDatabinding
{
/// <summary>
/// Interaction logic for Window1.xaml
/// </summary>
public partial class Window1 : Window
{
private DataObject ADataObject;
public Window1()
{
InitializeComponent();
this.ADataObject = new DataObject();
this.ADataObject.Name = "Hello!";
this.DataContext = this.ADataObject;
}
}
}
namespace WpfDatabinding
{
/// <summary>
/// Interaction logic for Window1.xaml
/// </summary>
public partial class Window1 : Window
{
private DataObject ADataObject;
public Window1()
{
InitializeComponent();
this.ADataObject = new DataObject();
this.ADataObject.Name = "Hello!";
this.DataContext = this.ADataObject;
}
}
}
DataObject.cs:
namespace WpfDatabinding
{
public class DataObject
{
// convert this to a field, and databinding will stop working
public string Name
{
get;
set;
}
}
}