Using Two-Way Data Binding in Open Event Organizer Android App:

Data Binding is the simple approach which relieves developers of repeated findViewById() calls. It is something that every developer must use if not using ButterKnife. The Open Event Organizer Android App provides options to fill in an extensive set of details while creating an event, or any other entities. The problem at hand is that many of these options are common to many of these entities. For instance, currently the element date-time-picker and text fields are common to elements of different forms, as each one of them requires date-time checkboxes. We need to be able to <include> a separate smaller and reusable layout file and bind event data to make the code shorter. This would help decreasing unnecessary code base and improving code readability. We will see how using 2 way data binding and <include> tags in the small PR #929 reduced the code of 112 lines to just 9 lines: Step 1: Configuration: The very first step is to configure your project to enable data bindings in your build.gradle (Module:app) file. dataBinding should be included as follows: android {    // Rest of gradle file...    dataBinding {    enabled true    }    // Rest of gradle file... } Step 2: Import and variable tags: Data Binding uses the tag <data> to signify the data which will be referred to in lambda expressions inside the XML. We also need to import any class, whose methods we need to use. This can be done using the <import> tag. Finally, the <variable> tag is used to define any variables that will be referenced in the XML.   <data>   <import type="android.view.View" />   <variable       name="date"       type="String" />   <variable       name="label"       type="String"/> </data> Step 3: Binding the declared variables: Data binding recognizes methods of the type set<variable>, where <variable> is event in our case. We need to use  executePendingBindings();  so that any pending bindings are done and the UI of our app responds correctly as soon as the view data is updated. @Override public void showResult(Event event) {   binding.setEvent(event);   binding.executePendingBindings(); } Step 4: Using the declared variables: Making use of the declared variables is a very simple task and is as simple as a java statement. You can do almost everything that’s possible in the java file, the only constraint being that the used variables are declared in the xml and binded appropriately. Most of the data binding expressions use data binding to condense the expression to its smallest possible form. <LinearLayout   android:layout_width="match_parent"   android:layout_height="wrap_content"   android:padding="@dimen/spacing_extra_small"   android:orientation="horizontal"   android:visibility="@{ picker.checked ? View.VISIBLE : View.GONE }"> 2 Way Data Binding In case of the Organizer App, we are using 2 way data binding. Data Binding allows us to do much more than just set text in TextView or create listener in Button. If we want to use EditText and automatically update text variable in java code, we need to use observable fields and two way binding. Thus, most variables like date, event that we are binding, are Observable fields. * Sometimes there’s a use case of using a variable declared in…

Continue ReadingUsing Two-Way Data Binding in Open Event Organizer Android App:

Implementation of Sponsors API in Open Event Organizer Android App

New contributors to this project are sometimes not experienced with the set of libraries and MVP pattern which this app uses. This blog post is an attempt to walk a new contributor through some parts of the code of the app by implementing an operation for an endpoint of the API. We’ll be implementing the sponsor endpoint. Open Event Organizer Android app uses a robust architecture. It is presently using the MVP (Model-View-Presenter) architecture. Therefore, this blog post aims at giving some brief insights to the app architecture through the implementation Sponsor endpoint. This blog post will focus only on one operation of the endpoint - the list operation - so as to make the post short enough. This blog post relates to Pull Request #901 of Open Event Organizer App. Project structure: These are the parts of the project structure where major updates will be made for the implementation of Sponsor endpoint: core data Setting up elements in the data module for the respective endpoint Sponsor.java @Data @Builder @Type("sponsor") @AllArgsConstructor @JsonNaming(PropertyNamingStrategy.KebabCaseStrategy.class) @EqualsAndHashCode(callSuper = false, exclude = { "sponsorDelegate", "checking" }) @Table(database = OrgaDatabase.class) public class Sponsor extends AbstractItem<Sponsor, SponsorsViewHolder> implements Comparable<Sponsor>, HeaderProvider {    @Delegate(types = SponsorDelegate.class)    private final SponsorDelegateImpl sponsorDelegate = new         SponsorDelegateImpl(this); This class uses Lombok, Jackson, RaizLabs-DbFlow, extends AbstractItem class (from Fast Adapter) and implements Comparable and HeaderProvider. All the annotations processor help us reduce boilerplate code. From the Lombok plugin, we are using: Lombok has annotations to generate Getters, Setters, Constructors, toString(), Equal() and hashCode() methods. Thus, it is very efficient in reducing boilerplate code @Getter,  @Setter, @ToString, @EqualsAndHashCode @Data is a shortcut annotation that bundles the features of @Getter, @Setter, @ToString and @EqualsAndHashCode The @Delegate is used for direct calls to the methods that are annotated with it, to the specified delegate. It basically separates the model class from other methods which do not pertain to data. Jackson @JsonNaming - used to choose the naming strategies for properties in serialization, overriding the default. For eg:  KEBAB_CASE, LOWER_CASE, SNAKE_CASE, UPPER_CAMEL_CASE @JsonNaming(PropertyNamingStrategy.KebabCaseStrategy.class) @JsonProperty - used to store the variable from JSON schema as the given variable name. So, "type" from JSON will be stored as sponsorType. @JsonProperty("type") public String sponsorType; RaizLabs-DbFlow DbFlow uses model classes which must be annotated using the annotations provided by the library. The basic annotations are – @Table, @PrimaryKey, @Column, @ForeignKey etc. These will create a table named attendee with the columns and the relationships annotated. SponsorDelegate.java and SponsorDelegateImpl.java The above are required only for method declarations of the classes and interfaces that Sponsor.java extends or implements. These basically separate the required method overrides from the base item class. public class SponsorDelegateImpl extends AbstractItem<Sponsor, SponsorsViewHolder> implements SponsorDelegate { SponsorRepository.java and SponsorRepositoryImpl.java A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection. Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the…

Continue ReadingImplementation of Sponsors API in Open Event Organizer Android App