Skip to main content

Home/ Java Development/ Group items tagged Object

Rss Feed Group items tagged

mahesh 1234

Instanceof Operator, Instanceof Operator in Java, Downcasting with Instanceof Operator - 0 views

  •  
    The instanceof operator is used to test whether the object is an instance of the specified type (class or subclass or interface). The instanceof operator is also known as type comparison operator because it compares the instance with type. It returns either true or false.
mahesh 1234

Super Keyword in Java- Javatpoint - 0 views

  •  
    super keyword. The super is used to refer the immediate parent class object. There are three usage of super. Let's see:
mahesh 1234

Array in Java - 0 views

  •  
    Normally, array is a collection of similar type of elements that have contigious memory location. In java, array is an object the contains elements of similar data type. It is a data structure where we store similar elements. We can store only fixed elements in an array.
mahesh 1234

this keyword - 0 views

  •  
    There can be a lot of usage of this keyword. In java, this is a reference variable that refers to the current object. Usage of this keyword Here is given the 6 usage of this keyword. this keyword can be used to refer current class instance variable.
anonymous

untitled - 0 views

  • initWidget(uiBinder.createAndBindUi(this));
    • anonymous
       
      To inizialize the "menber variable" whith the widget object described in the XML view despription
  • uiBinder.createAndBindUi(this)
  • GWT compiler won't actually visit this URL to fetch the file, because a copy of it is baked into the compiler
  • ...15 more annotations...
  • @UiField have default visibility
  • UIObject
  • DivElement
  • If your factory method needs arguments, those will be required as attributes.
  • Every widget that is declared in a template is created by a call to GWT.create().
  • @UiConstructor annotation.
  • you can mark your own widgets with
  • CricketScores has no default (zero args) constructor
  • you can define a @UiFactory method on the UiBinder's owner
  • annotate a constructor of CricketScores with @UiConstructor.
  •   @UiFactory
  • public class UserDashboard extends Composite {  interface MyUiBinder extends UiBinder<Widget, UserDashboard> {}  private static MyUiBinder uiBinder = GWT.create(MyUiBinder.class);  public UserDashboard() {    initWidget(uiBinder.createAndBindUi(this));  }}
  • use several different XML templates for the same view
  • public interface Display
  • methods can be called to fill in attribute values
anonymous

Public Object: Refactoring to Guice: Part 1 of N - 0 views

  •  
    Refactoring code and guicify it
anonymous

Large scale application development and MVP - Part II - Google Web Toolkit - Google Code - 0 views

  • itself
    • anonymous
       
      The View Implementation
  • @UiHandler("
  • presenter.onAddButtonClicked();
  • ...91 more annotations...
  • onAddButtonClicked
  • eventBus.fireEvent(new AddContactEvent());
  • presenter needs to know more about the view
  • view needs to know more about the data model
  • data types are typically homogeneous within column borders
  • ColumnDefinition abstract class
  • houses the any type-specific code (this is the third party mentioned above)
  • ColumnDefinition
  • ColumnDefinition(s) would be created outside of the presenter
  • we can reuse its logic regardless of what view we've attached ourself to
  • update our views such that we can set their ColumnDefinition(s).
  • setColumnDefinitions
  • this.columnDefinitions = columnDefinitions;
  • so that we can pass in
  • a mocked ContactsView instance when testing our ContactsPresenter
  • in our AppController, when we create the ContactsView,
  • new ContactsViewColumnDefinitions().getColumnDefinitions();
  • we can initialize it with the necessary ColumnDefinition(s).
  • contactsView.setColumnDefiniions(
    • anonymous
       
      Initialize ContactsView with the necessary ColumnDefinition(s)
  • With our ColumnDefinition(s) we can pass the model untouched.
  • As mentioned above we were previously dumbing down the model into a list of Strings
  • current solution
  • List<String> data
  • display.setData(data);
  • how that data type is rendered.
  • use generics
  • third party that abstracts
  • knowledge of a cell's data type
  • stringing together a list of these classes
  • providing the necessary render()
  • and isClickable()/isSelectable() override
  • ContactsViewColumnDefinitions<ContactDetails>
  • columnDefinitions =      new ArrayList<ColumnDefinition<ContactDetails>>()
  • ColumnDefinition<T>
  • ContactsPresenter
  • ContactsViewImpl
  • ColumnDefinition<T> columnDefinition = columnDefinitions.get(j);
  • the presenter can pass the model untouched
  • the view has no rendering code
  • that we would otherwise need to test. And the fun doesn't stop there.
  • presenter.onItemClicked(
  • presenter.onItemSelected
  • ClickEvent
  • cell.getCellIndex()
  • columnDefinition.isClickable()
  • SelectEvent
  • columnDefinition.isSelectable()
  • return shouldFireClickEvent;
  • return shouldFireSelectEvent;
  • respond to user interaction in different ways based upon the cell type that was clicked
  • use them for rendering purposes
  • defining how to interpret user interactions
  • we're going to remove any application state from the ContactsView
  • replace the view's getSelectedRows() with a SelectionModel
  • The SelectionModel is nothing more than a wrapper around a list of model objects.
  • ContactsPresenter holds on to an instance of this class
  • onItemSelected
  • Having the ColumnDefinition create a new widget for each cell is too heavy
  • Replace our FlexTable implementation with an HTML widget
  • calling setHTML()
  • Reduce the event overhead by sinking events on the HTML widget
  • rather than the individual cells
  • update our ContactsView.ui.xml file to use a
  • HTML widget rather than a FlexTable widget.
  • <g:HTML ui:field="contactsTable">
  • Inefficiencies related to inserting new elements via DOM manipulation Overhead associated with sinking events per Widget
  • for each item ask our column definitions to render accordingly
  • each column definition
  • render itself into the StringBuilder
  • rather than passing back a full-on widget
  • calling setHTML on a HTML widget
  • rather than calling setWidget on a FlexTable.
  • This will decrease your load time, especially as your tables start to grow.
  • we're reducing the overhead of sinking events on per-cell widgets
  • instead sinking on a single container
  • ClickEvents are still wired up via our UiHandler annotations
  • get the Element that was clicked on
  • and walk the DOM until we find a parent TableCellElement
  • we can determine the row
  • shouldFirdClickEvent() and shouldFireSelectEvent()
  • to take as a parameter a TableCellElement rather than a HTMLTable.Cell.
  • faster startup times via Code Splitting.
  • runAsync() points
  • split portion of your code is purely segmented
  • not referenced by other parts of the app
  • it will be downloaded and executed at the point that it needs to run
  • Do we really want to download all of that code before the user even logs in?
  • Not really.
  • simply grab the login code, and leave the rest for when we actually need it
  • wrap the code that creates the ContactsView and ContactsPresenter in a runAsync() call
  • as optimizations such as this one become easier and easier to implement.
« First ‹ Previous 41 - 48 of 48
Showing 20 items per page