Data Binding

Read more about the article Speaker details in the Open Event Orga App

Speaker details in the Open Event Orga App

The Open Event Organiser Android App is currently released in the Alpha phase on the Google Play Store here. This blog post explains how the speaker details feature has been implemented in the app. Model The model for Speaker is pretty straightforward. It includes the personal details of the speaker such as name, biography, country, social media profiles, designation etc. Apart from these details, every instance of speaker is associated with a single event. A speaker will also have multiple instances of sessions. Full implementation of the speaker’s model can be found here. Network Call We use Retrofit in order to make the network call and Jackson Factory to deserialize the data received from the call into an instance of the speaker model. The following endpoint provides us with the required information: https://open-event-api-dev.herokuapp.com/speakers/{speaker_id} Repository In any typical android application using both network calls and data persistence, there is a need of a repository class to handle them. Speaker Repository handles the network call to the API in order to fetch the speaker details. It then saves the data returned by the api into the database asynchronously. It also ensures that we send the latest data that we have stored in the database to the view model. Given below is the full implementation for reference: @Override public Observable<Speaker> getSpeaker(long speakerId, boolean reload) { Observable<Speaker> diskObservable = Observable.defer(() -> repository .getItems(Speaker.class, Speaker_Table.id.eq(speakerId)).take(1) ); Observable<Speaker> networkObservable = Observable.defer(() -> speakerApi.getSpeaker(speakerId) .doOnNext(speaker -> repository .save(Speaker.class, speaker) .subscribe())); return repository .observableOf(Speaker.class) .reload(reload) .withDiskObservable(diskObservable) .withNetworkObservable(networkObservable) .build(); } ViewModel The View Model is responsible for fetching the necessary details from the repository and displaying it in the view. It handles all the view binding logic. The most important method in the SpeakerDetailsViewModel is the getSpeakers method. It accepts a speaker id from the fragment, queries the repository for the details of the speaker and returns it back to the fragment in the form of a LiveData. Below is the full implementation of the getSpeakers method: protected LiveData<Speaker> getSpeaker(long speakerId, boolean reload) { if (speakerLiveData.getValue() != null && !reload) return speakerLiveData; compositeDisposable.add(speakerRepository.getSpeaker(speakerId, reload) .compose(dispose(compositeDisposable)) .doOnSubscribe(disposable -> progress.setValue(true)) .doFinally(() -> progress.setValue(false)) .doOnNext(speaker -> speakerLiveData.setValue(speaker)) .flatMap(speaker -> sessionRepository.getSessionsUnderSpeaker(speakerId, reload)) .toList() .subscribe(sessionList -> sessionLiveData.setValue(sessionList), throwable -> error.setValue(ErrorUtils.getMessage(throwable)))); return speakerLiveData; } We add the disposable to a composite disposable and dispose it in the onCleared method of the View Model. The full implementation of the View Model can be found here. Fragment The SpeakerDetailsFragment acts as the view and is responsible for everything the user sees on the screen. It accepts the id of the speaker whose details are to be displayed in the constructor. When an instance of the fragment is created it sets up it’s view model and inflates it’s layout using the Data binding framework. @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { context = getContext(); binding = DataBindingUtil.inflate(inflater, R.layout.speaker_details_fragment, container, false); speakerDetailsViewModel = ViewModelProviders.of(this, viewModelFactory).get(SpeakerDetailsViewModel.class); speakerId = getArguments().getLong(SPEAKER_ID); AppCompatActivity activity = ((AppCompatActivity) getActivity()); activity.setSupportActionBar(binding.toolbar); ActionBar actionBar = activity.getSupportActionBar(); if (actionBar != null) { actionBar.setHomeButtonEnabled(true); actionBar.setDisplayHomeAsUpEnabled(true); }…

Continue ReadingSpeaker details in the Open Event Orga App
Read more about the article Using Two-Way Data Binding in Open Event Organizer Android App:

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:
Read more about the article Handling Click Events using Custom Binding Adapters

Handling Click Events using Custom Binding Adapters

The Open Event Organiser Android App is the Event management app for organizers using the Open Event Platform. It is currently released in the Alpha phase on the Google Play Store here and is being actively developed by the community. The Data Binding Library is one of the most popular libraries among the android developers. We use it extensively in the application in order to greatly simplify the UI binding logic. While trying to show the details of a speaker in the application, we wanted to list his/her social media links using Image buttons. Upon clicking one of these buttons, the user was supposed to be directed to the link after opening the default web browser. This blog post discusses how we used custom Binding Adapters to handle click events on an Image Button by defining a custom attribute. Defining the Binding Adapter We defined a simple Binding Adapter for an Image button meant to handle social media links. We used “imageOnClick” as the custom attribute name for specifying the URL that will be opened once the button is clicked. @BindingAdapter("imageOnClick") public static void bindOnImageButtonClickListener(ImageButton imageButton, String url) { imageButton.setOnClickListener(view -> { if (url != null) { Context context = imageButton.getContext(); Intent intent = new Intent(Intent.ACTION_VIEW); intent.setData(Uri.parse(url)); if (intent.resolveActivity(context.getPackageManager()) != null) { context.startActivity(intent); } else { Toast.makeText(context, "No Web browser found", Toast.LENGTH_SHORT).show(); } } }); }   The method can be named anything you want and can be placed anywhere in the project but we would recommend creating a separate class for all the Binding adapters. The important things to take away from the above method are: The method needs to be public otherwise the Data binding framework won’t be able to find it. We need to pass in the view as the first parameter and the attribute value as the second parameter. Then we simply set the familiar click listener to handle the click interaction. We use the Context from the view passed in the method as the first parameter. Then we create an Intent and set the passed in URL as the data. We make sure that the user has a browser installed on his/her android phone before we try to open the browser. We show a suitable error message if they don’t. Using it in Layout Using the custom attribute in the layout was extremely simple. We specified the url using the attribute “imageOnClick” and the rest was handled by the Binding Adapter and the Data binding framework.   <ImageButton android:id="@+id/action_speakers_linkedin" android:layout_width="@dimen/spacing_larger" android:layout_height="match_parent" android:contentDescription="@string/linkedin_icon" app:imageOnClick="@{ speaker.linkedin }" android:background="#ededed" android:visibility="@{ (speaker.linkedin != null) ? View.VISIBLE : View.GONE }" app:srcCompat="@drawable/ic_linkedin_colored"/> References Data Binding Library: Data Binding Library Binding Adapters guide: Binding Adapters

Continue ReadingHandling Click Events using Custom Binding Adapters
Read more about the article Using Android Palette with Glide in Open Event Organizer Android App

Using Android Palette with Glide in Open Event Organizer Android App

Open Event Organizer is an Android Application for the Event Organizers and Entry Managers. The core feature of the App is to scan a QR code from the ticket to validate an attendee's check in. Other features of the App are to display an overview of sales, ticket management and basic editing in the Event Details. Open Event API Server acts as a backend for this App. The App uses Navigation Drawer for navigation in the App. The side drawer contains menus, event name, event start date and event image in the header. Event name and date is shown just below the event image in a palette. For a better visibility Android Palette is used which extracts prominent colors from images. The App uses Glide to handle image loading hence GlidePalette library is used for palette generation which integrates Android Palette with Glide. I will be talking about the implementation of GlidePalette in the App in this blog. The App uses Data Binding so the image URLs are directly passed to the XML views in the layouts and the image loading logic is implemented in the BindingAdapter class. The image loading code looks like: GlideApp .with(imageView.getContext()) .load(Uri.parse(url)) ... .into(imageView);   So as to implement palette generation for event detail label, it has to be implemented with the event image loading. GlideApp takes request listener which implements methods on success and failure where palette can be generated using the bitmap loaded. With GlidePalette most of this part is covered in the library itself. It provides GlidePalette class which is a sub class of GlideApp request listener which is passed to the GlideApp using the method listener. In the App, BindingAdapter has a method named bindImageWithPalette which takes a view container, image url, a placeholder drawable and the ids of imageview and palette. The relevant code is: @BindingAdapter(value = {"paletteImageUrl", "placeholder", "imageId", "paletteId"}, requireAll = false) public static void bindImageWithPalette(View container, String url, Drawable drawable, int imageId, int paletteId) { ImageView imageView = (ImageView) container.findViewById(imageId); ViewGroup palette = (ViewGroup) container.findViewById(paletteId); if (TextUtils.isEmpty(url)) { if (drawable != null) imageView.setImageDrawable(drawable); palette.setBackgroundColor(container.getResources().getColor(R.color.grey_600)); for (int i = 0; i < palette.getChildCount(); i++) { View child = palette.getChildAt(i); if (child instanceof TextView) ((TextView) child).setTextColor(Color.WHITE); } return; } GlidePalette<Drawable> glidePalette = GlidePalette.with(url) .use(GlidePalette.Profile.MUTED) .intoBackground(palette) .crossfade(true); for (int i = 0; i < palette.getChildCount(); i++) { View child = palette.getChildAt(i); if (child instanceof TextView) glidePalette .intoTextColor((TextView) child, GlidePalette.Swatch.TITLE_TEXT_COLOR); } setGlideImage(imageView, url, drawable, null, glidePalette); }   The code is pretty obvious. The method checks passed URL for nullability. If null, it sets the placeholder drawable to the image view and default colors to the text views and the palette. The GlidePalette object is generated using the initializer method with which takes the image URL. The request is passed to the method setGlideImage which loads the image and passes the GlidePalette to the GlideApp as a listener. Accordingly, the palette is generated and the colors are set to the label and text views accordingly. The container view in the XML…

Continue ReadingUsing Android Palette with Glide in Open Event Organizer Android App
Read more about the article Binding Images Dynamically in Open Event Orga App

Binding Images Dynamically in Open Event Orga App

In Open Event Orga App (Github Repo), we used Picasso to load images from URLs and display in ImageViews. Picasso is easy to use, lightweight, and extremely configurable but there has been no new release of the library since 2015. We were using Picasso in binding adapters in order to dynamically load images using POJO properties in the layout XML itself using Android Data Binding. But this configuration was a little buggy. The first time the app was opened, Picasso fetched the image but it was not applied to the ImageView. When the device was rotated or the activity was resumed, it loaded just fine. This was a critical issue and we tried many things to fix it but none of it quite fit our needs. We considered moving on to other Image Loading libraries like Glide, etc but it was too heavy on the size and functionality for our needs. The last resort was to update the library to develop version using Sonatype’s snapshots Repository. Now, the Picasso v2.6.0-SNAPSHOT is very stable but not released to the maven central repository, and a newer develop version v3.0.0-SNAPSHOT was launched too. So we figured we should use that. This blog will outline the steps to include the develop version of Picasso, configuring it for our needs and making it work with Android Data Binding. Setting up Dependencies Firstly, we need to include the sonatype repository in the repositories block of our app/build.gradle repositories { ... maven { url 'https://oss.sonatype.org/content/repositories/snapshots/' } }   Then we need to replace the Picasso dependency entry to this: compile 'com.squareup.picasso:picasso:3.0.0-SNAPSHOT'   Note that if you used Jake Wharton’s OkHttp3 Downloader for Picasso, you won’t need it now, so you need to remove it from the dependency block And you need to use this to import the downloader import com.squareup.picasso.OkHttp3Downloader;   Next, we set up our Picasso DI this way Picasso providesPicasso(Context context, OkHttpClient client) { Picasso picasso = new Picasso.Builder(context) .downloader(new OkHttp3Downloader(client)) .build(); picasso.setLoggingEnabled(true); return picasso; }   Set the singleton instance in our application: Picasso.setSingletonInstance(picasso);   And we are ready to use it. Creating Adapters Circular Image Adapter We show event logos as circular images, so we needed to create a binding adapter for that: @BindingAdapter("circleImageUrl") public static void bindCircularImage(ImageView imageView, String url) { if(TextUtils.isEmpty(url)) { imageView.setImageResource(R.drawable.ic_photo_shutter); return; } Picasso.with() .load(Uri.parse(url)) .error(R.drawable.ic_photo_shutter) .placeholder(R.drawable.ic_photo_shutter) .transform(new CircleTransform()) .tag(MainActivity.class) .into(imageView); }   If the URL is empty, we just show the default photo, and otherwise we load the image into the view using standard CircleTransform Note that there is no context argument in the with method. This was implemented in Picasso recently where they removed the need for context for loading images. Now, they use a Dummy ContentProvider to get application context, which is inspired by how Firebase does it. Now, we can just normally use this binding in layout to load the event thumbnail like this <ImageView android:layout_width="@dimen/image_small" android:layout_height="@dimen/image_small" android:contentDescription="@string/event_thumbnail" app:circleImageUrl="@{event.thumbnailImageUrl}" />   This gives us a layout like this: Next we need to load the header…

Continue ReadingBinding Images Dynamically in Open Event Orga App
Read more about the article Accessing Child Component’s API in Loklak Search

Accessing Child Component’s API in Loklak Search

Loklak search being an angular application, comprises of components. Components provide us a way to organize the application in a more consistent way, along with providing the ability to reuse code in the application. Each component has two type of API’s public and private. Public API is the API which it exposes to the outer world for manipulating the working of the component, while private API is something which is local to the component and cannot be directly accessed by the outside world. Now when this distinction between the two is clear, it is important to state the need of these API’s, and why are they required in loklak search. The components can never live in isolation, i.e. they have to communicate with their parent to be able to function properly. Same is the case with components of loklak search. They have to interact with others to make the application work. So how this, interaction looks like, The rule of thumb here is, data flows down, events flow up. This is the core idea of all the SPA frameworks of modern times, unidirectional data flow, and these interactions can be seen everywhere in loklak search. <feed-header    [query]="query"    (searchEvent)="doSearch($event)"></feed-header> This is how a simple component’s API looks in loklak search. Here our component is FeedHeader and it exposes some of it’s API as inputs and outputs. export class FeedHeaderComponent {  @Input() query: string;  @Output() searchEvent: EventEmitter<string> = new EventEmitter<string>();   // Other methods and properties of the component } The FeedHeaderComponent ‘s class defines some inputs which it takes. These inputs are the data given to the component. Here the input is a simple query property, and the parent at the time of instantiating the component, passes the value to it’s child as [query]="query". This enables the one direction of API, from parent to child. Now, we also need a way for parent to be able to events generated by the child on interaction with user. For example, here we need to have a way to tell the parent to perform a search whenever user presses search button. For this the Output property searchEvent is used. The search event can be emitted by the child component independently. While the parent, if it wants to listen to child components simply do so by binding to the event and running a corresponding function whenever event is emitted (searchEvent)="doSearch($event)". Here the event which parent listens to is searchEvent and whenever such an event is emitted by the child a function doSearch is run by the parent. Thus this completes the event flow, from child to parent. Now it is worth noticing that all these inputs for data and outputs for events is provided by the child component itself. They are the API of the child and parent’s job is just to bind to these inputs and outputs to bind to data and listen to events. This allows the component interactions in both directions. @ViewChild and triggering child’s methods The inputs are important to carry data…

Continue ReadingAccessing Child Component’s API in Loklak Search
Read more about the article Implementing Attendee Detail BottomSheet UI in Open Event Orga App

Implementing Attendee Detail BottomSheet UI in Open Event Orga App

In Open Event Orga App (Github Repo), we allow the option to check the attendee details before checking him/her in or out. Originally, a dialog was shown showing the attendee details, which did not contain much information about the attendee, ticket or the order. The disadvantage of such design was also that it was tied to only one view. We couldn’t show the check in dialog elsewhere in the app, like during QR scanning. So we had to switch back to the attendee view for showing the check in dialog. We decided to create a usable detached component in the form of a bottom sheet containing all required information. This blog will outline the procedure we employed to design the bottom sheet UI. The attendee check in dialog looked like this: So, first we decide what we need to show on the check in bottom sheet: Attendee Name Attendee Email Attendee Check In Status Order Status ( Completed, Pending, etc ) TIcket Type ( Free, Paid, Donation ) Ticket Price Order Date Invoice Number Order ‘Paid Via’ As we are using Android Data Binding in our layout, we’ll start by including the variables required in the layout. Besides the obvious attendee variable, we need presenter instance to handle the check in and check out of the attendee and DateUtils class to parse the order date. Additionally, to handle the visibility of views, we need to include the View class too <data> <import type="org.fossasia.openevent.app.utils.DateUtils" /> <import type="android.view.View" /> <variable name="presenter" type="org.fossasia.openevent.app.event.checkin.contract.IAttendeeCheckInPresenter" /> <variable name="checkinAttendee" type="org.fossasia.openevent.app.data.models.Attendee" /> </data>   Then, we make the root layout to be CoordinatorLayout and add a NestedScrollView inside it, which contains a vertical linear layout in it. This vertical linear layout will contain our fields. Note: For brevity, I’ll skip most of the layout attributes from the blog and only show the ones that correspond to the text Firstly, we show the attendee name: <TextView style="@style/TextAppearance.AppCompat.Headline" android:text='@{attendee.firstName + " " + attendee.lastName }' tools:text="Name" />   The perks of using data binding can be seen here, as we are using string concatenation in layout itself. Furthermore, data binding also handles null checks for us if we add a question mark at the end of the variable name ( attendee.firstName? ). But our server ensures that both these fields are not null, so we skip that part. Next up, we display the attendee email <TextView android:text="@{ checkinAttendee.email }" tools:text="xyz@example.com" />   And then the check in status of the attendee <TextView android:text="@{ checkinAttendee.checkedIn ? @string/checked_in : @string/checked_out }" android:textColor="@{ checkinAttendee.checkedIn ? @color/light_green_500 : @color/red_500 }" tools:text="CHECKED IN" />   Notice that we dynamically change the color and text based on the check in status of the attendee Now we begin showing the fields with icons to their left. You can use Compound Drawable to achieve this effect, but we use vector drawables which are incompatible with compound drawables on older versions of Android, so we use a horizontal LinearLayout instead. The first field is the order status denoting…

Continue ReadingImplementing Attendee Detail BottomSheet UI in Open Event Orga App
Read more about the article Adding Settings and Contact Info Route to Open Event Frontend

Adding Settings and Contact Info Route to Open Event Frontend

In Open Event Frontend, while dealing with an issue, we had to create the ‘contact-info’ route as a subroute of the ‘settings’ route. We have given the user a facility to update his/her information thereby allowing them to change it whenever they want. Thus to generate the route, we are using ember cli: ember g route settings/contact-info Thus, the above command will generate three files: routes/settings/contact-info.js templates/settings/contact-info.hbs tests/unit/routes/settings/contact-info-test.js 1) contact-info.hbs In this file, we have a form which we have made a component for easy use. Thus following is the content of the contact-info.hbs file: {{settings/contact-info-section}} Thus ultimately, we are having a component called ‘contact-info-section’ which contains our markup for the contact-info form. To generate the component, we do: ember g component settings/contact-info-section This command will generate two files: 1. templates/components/contact-info-section.hbs 2. components/contact-info-section.js Following is the markup in contact-info-section.hbs: <form class="ui form" {{action 'submit' on='submit'}} novalidate> <div class="field"> <label>{{t 'Email'}}</label> {{input type='email' name='email' value=email}} </div> <div class="field"> <label>{{t 'Phone'}}</label> {{input type='text' name='phone' value=phone}} </div> <button class="ui teal button" type="submit">{{t 'Save'}}</button> </form> In the form, we are having two fields for inputs ‘Email’ and ‘Phone’ respectively. We are using Ember input helpers so as to achieve easy data binding. The name is used as an identifier for the validation. We have one submit button at the bottom which saves the information that the user wants to update. The contact-info-section.js file contains all the validation rules which validate the form when the user submits it. If a user enters any field empty, the form prompts the user with a message. Following is an example of the validation rules for the email field: email: { identifier : 'email', rules : [ { type : 'empty', prompt : this.l10n.t('Please enter your email ID') }, { type : 'email', prompt : this.l10n.t('Please enter a valid email ID') } ] } Similar rules are there for the ‘phone’ field input. 2) contact-info.js The contact-info.js renders our route. Thus it contains the ‘titletoken’ method which returns the ‘titletoken’ method which returns the page title. Thus, after doing all the things above, we get the following as a result. Resources: Ember input helpers Semantic UI form validation Blog post by Daniel Lavigne about ‘Learning Ember.js Routes’ Source code: https://github.com/fossasia/open-event-frontend contact-info.hbs contact-info-section.hbs contact-info.js contact-info-section.js

Continue ReadingAdding Settings and Contact Info Route to Open Event Frontend
Read more about the article Dynamic Ticket Analysis UI using Data Binding in Open Event Android Orga App

Dynamic Ticket Analysis UI using Data Binding in Open Event Android Orga App

Any event manager application has the responsibility to show the analytics about the event to the organiser and in Open Event Android Orga App (Github Repo), we wanted to achieve a way to display the analytics of total and sold tickets with the data present to us. To analyse, we have a list of tickets, which are divided into 3 categories: Free Paid Donation Our goal was to show information about total tickets and the amount of sold tickets per category. This blog will focus on the dynamic UI creation for the ticket analysis component of the Event Details Dashboard using Android Layout Data Binding. By using Data Binding, we not only reduced the amount of Java Boilerplate code we would have to write, but also accomplished UI reuse in just XML which wouldn’t have been possible without it. You’ll see in a moment what I mean. Properties So first, we’d need to define some properties which will be bound in the UI. These properties are declared in the Event model and their type is ObservableLong provided by the Android DataBinding package. The reason why we are using these instead of primitives is because these fields being Observable, will update the UI as soon as they are updated, without requiring the programmer to set the View Property at all. There are six fields, 3 for total tickets of each type and 3 for sold tickets public final ObservableLong freeTickets = new ObservableLong(); public final ObservableLong paidTickets = new ObservableLong(); public final ObservableLong donationTickets = new ObservableLong(); public final ObservableLong soldFreeTickets = new ObservableLong(); public final ObservableLong soldPaidTickets = new ObservableLong(); public final ObservableLong soldDonationTickets = new ObservableLong(); Some more advantages we get from using these are the batch view update and the use of computed properties in UI. Imagine having a TextView display the amount of free tickets and a progress bar showing the percentage of free tickets sold. Traditionally, you’d have to set the text and compute the percentage and set the progress bar as the data changes, whereas you can just use the fields in layout as is in both TextView and ProgressBar with the computations required and they’ll work in harmony. We have leveraged this feature to show the analytics component of tickets with a Ticket Type Circular Progress Bar Sold Tickets Total Tickets All using the XML layout and databinding Ticket Component For each ticket component, we have 4 variables, namely Ticket Type Name Total Amount Completed Amount (Sold Tickets) Color First 3 are fairly self explanatory, the color attribute we used in our component needs a little bit of description. We decided to give each ticket category its own color for circular progress bar for aesthetics. So, we need each component to have its own color attribute too. But this is not a normal android color ID or a hex. We needed 2 variants of the same color to show in the circular progress to discern the total and completed part. As we are using…

Continue ReadingDynamic Ticket Analysis UI using Data Binding in Open Event Android Orga App