Global Search in Open Event Android

In the Open Event Android app we only had a single data source for searching in each page that was the content on the page itself. But it turned out that users want to search data across an event and therefore across different screens in the app. Global search solves this problem. We have recently implemented  global search in Open Event Android that enables the user to search data from the different pages i.e Tracks, Speakers, Locations etc all in a single page. This helps the user in obtaining his desired result in less time. In this blog I am describing how we implemented the feature in the app using JAVA and XML.

Implementing the Search

The first step of the work is to to add the search icon on the homescreen. We have done this with an id R.id.action_search_home.

@Override
public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
   super.onCreateOptionsMenu(menu, inflater);
   inflater.inflate(R.menu.menu_home, menu);
   // Get the SearchView and set the searchable configuration
   SearchManager searchManager = (SearchManager)getContext().    getSystemService(Context.SEARCH_SERVICE);
   searchView = (SearchView) menu.findItem(R.id.action_search_home).getActionView();
  // Assumes current activity is the searchable activity
 searchView.setSearchableInfo(searchManager.getSearchableInfo(
getActivity().getComponentName()));
searchView.setIconifiedByDefault(true); 
}

What is being done here is that the search icon on the top right of the home screen  is being designated a searchable component which is responsible for the setup of the search widget on the Toolbar of the app.

@Override
 public boolean onCreateOptionsMenu(Menu menu) {
    MenuInflater inflater = getMenuInflater();
    inflater.inflate(R.menu.menu_home, menu);
    SearchManager searchManager =
            (SearchManager) getSystemService(Context.SEARCH_SERVICE);
    searchView = (SearchView) menu.findItem(R.id.action_search_home).getActionView();
    searchView.setSearchableInfo(
            searchManager.getSearchableInfo(getComponentName()));
 
    searchView.setOnQueryTextListener(this);
    if (searchText != null) {
        searchView.setQuery(searchText, true);
    }
    return true; }

We can see that a queryTextListener has been setup in this function which is responsible to trigger a function whenever a query in the SearchView changes.

Example of a Searchable Component

<?xml version="1.0" encoding="utf-8"?>
 <searchable xmlns:android="http://schemas.android.com/apk/res/android"
    android:hint="@string/global_search_hint"
    android:label="@string/app_name" />

For More Info : https://developer.android.com/guide/topics/search/searchable-config.html

If this searchable component is inserted into the manifest in the required destination activity’s body the destination activity is set and intent filter must be set in this activity to tell whether or not the activity is searchable.

Manifest Code for SearchActivity

<activity
        android:name=".activities.SearchActivity"
        android:launchMode="singleTop"
        android:label="Search App"
        android:parentActivityName=".activities.MainActivity">
    <intent-filter>
        <action android:name="android.intent.action.SEARCH" />
    </intent-filter>
    <meta-data
        android:name="android.app.searchable"
        android:resource="@xml/searchable" />
 </activity>

And the attribute  android:launchMode=”singleTop is very important as if we want to search multiple times in the SearchActivity all the instances of our SearchActivity would get stored on the call stack which is not needed and would also eat up a lot of memory.

Handling the Intent to the SearchActivity

We basically need to do a standard if check in order to check if the intent is of type ACTION_SEARCH.

if (Intent.ACTION_SEARCH.equals(getIntent().getAction())) {
    handleIntent(getIntent());
 }
@Override
 protected void onNewIntent(Intent intent) {
    super.onNewIntent(intent);
    handleIntent(intent);
 }
 public void handleIntent(Intent intent) {
    final String query = intent.getStringExtra(SearchManager.QUERY);
    searchQuery(query);
 }

The function searchQuery is called within handleIntent in order to search for the text that we received from the Homescreen.

SearchView Trigger Functions

Next we need to add two main functions in order to get the search working:

  • onQueryTextChange
  • onQueryTextSubmit

The function names are self-explanatory. Now we will move on to the code implementation of the given functions.

@Override
 public boolean onQueryTextChange(String query) {
    if(query!=null) {
        searchQuery(query);
        searchText = query;
    }
    else{
        results.clear();
        handleVisibility();
    }
   return true;
 }
 
 @Override
 public boolean onQueryTextSubmit(String query) {
    searchView.clearFocus();
    return true;
 }

The role of the searchView.clearFocus() inside the above code snippet is to remove the keyboard popup from the screen to enable the user to have a clear view of the search result.

Here the main search logic is being handled by the function called searchQuery which I’ll talking about now.

Search Logic

private void searchQuery(String constraint) {
 
    results.clear();
 
    if (!TextUtils.isEmpty(constraint)) {
        String query = constraint.toLowerCase(Locale.getDefault());
        addResultsFromTracks(query);
        addResultsFromSpeakers(query);
        addResultsFromLocations(query);
    }
 }
//THESE ARE SOME VARIABLES FOR REFERENCE
//This is the custom recycler view adapter that has been defined for the search
private GlobalSearchAdapter globalSearchAdapter;
 //This stores the results in an Object Array
 private List<Object> result

We are assuming that we have POJO’s(Plain Old Java Objects) for Tracks , Speakers , and Locations and for the Result Type Header.

The code posted below performs the function of getting the required results from the list of tracks. All the results are being fetched asynchronously from Realm and here we have also attached a header for the result type to denote whether the result is of type Track , Speaker or Location. We also see that we have added a changeListener to notify us if any changes have occurred in the set of results.

Similarly this is being done for all the result types that we need i.e Tracks, Locations and Speakers.

public void addResultsFromTracks(String queryString) {

   RealmResults<Track> filteredTracks = realm.where(Track.class)
                                        .like("name", queryString,                     Case.INSENSITIVE).findAllSortedAsync("name");
      filteredTracks.addChangeListener(tracks -> {

       if(tracks.size()>0){
            results.add("Tracks");
        }
       results.addAll(tracks);
       globalSearchAdapter.notifyDataSetChanged();
       Timber.d("Filtering done total results %d", tracks.size());
       handleVisibility();
});}

We now have a “Global Search” feature in the Open Event Android app. Users had asked for this feature and a learning for us is, that it would have been even better to do more tests with users when we developed the first versions. So, we could have included this feedback and implemented Global Search earlier on.

Resources

Continue ReadingGlobal Search in Open Event Android

Adding a Two Pane Layout to the Open Event Android App

Android gadgets are found in various screen sizes and densities. It is here where fragments make planning the layouts for phones and tablets simple.  We can progressively include and expel sections from an activity which makes it conceivable to plan adaptable UIs.

Generally a single pane design is favored for telephones and multi-pane formats are utilized for tablets with a specific end goal to use the additional space which is found in tablets. The Open Event Android App on tablet view appeared to be identical for a versatile client and accordingly it had a considerable measure of free space which could be used for effective UI for tablet clients. A two-pane design is utilized for the application where the navigation view is on the left side while the item clicked on the navigation view is on the right side.

  1. Steps involved for incorporating a two-pane layout

The steps that need to be followed for the app to support a two-pane layout are as follows:

  1. Create a layout-sw600dp (for small tablet users) or layout-sw720dp (for large tablet users) in the res directory.
  2. The name of files should be same for those within layout/ and layout-sw600dp/ to provide a support for a two-pane layout.

The layout/activity_main.xml structure of the app looks like this:

The layout-sw600dp/activity_main.xml structure of the app looks like this:

  1. Now in the MainActivity.java file of the app we took a boolean variable mTwoPane which was true if during runtime findViewById(R.id.drawer) didn’t exist as a drawerlayout is used as a root view for the activity_main.xml in layout/ folder but not in layout-sw600dp folder.
  2. All the parts of the MainActivity.java which had a drawerlayout variable were now put in an “if” condition checking if the mTwoPane boolean value is false then execute the statement otherwise set the drawerlayout to lock mode.

This helped us accomplishing a two-pane layout in the tablet layout of the app thus helping in using the extra space in a more efficient manner.

Related Links:
Continue ReadingAdding a Two Pane Layout to the Open Event Android App

Using Getter and Setter to set Properties and Manipulate Responses to Templates in Ember JS on Open Event Front-end

In the Open Event Front-end our aim is to make it work on all devices regardless of screen size. We need the UI to be responsive. One feature of the system is that users can change system images. The idea in this issue was to enable users to select a ‘topic’ from the left side menu that would trigger an action which dynamically changes the right part of the page. For example, we could show ‘subTopics’ and their respective images based on the data given in the dictionary in Open Event Frontend project. Open Event Frontend has some static data files which are called dictionaries. They contain Javascript Objects which are used throughout the project. The solution I am implementing here is to get the data from the template, set it as a property of the Ember object with the help of setter, and use it again with the help of getter to manipulate our response to the template. Thus in a controller, we can perform manipulation of the data which we want to return to the template.

In Open Event Front-end we have a dictionary (event.js) which we are using to load our topics into the left side menu.

 

export const eventTopics = {
'Auto, Boat & Air': [
'Air', 'Auto', 'Boat', 'Motorcycle/ATV', 'Other'
],
'Business & Professional': [
'Career', 'Design', 'Educators', 'Environment & Sustainability',
'Finance', 'Media', 'Non Profit & NGOs', 'Other', 'Real Estate',
'Sales & Marketing', 'Startups & Small Business'
],
'Charity & Causes': [
'Animal Welfare', 'Disaster Relief', 'Education',
'Environment', 'Healthcare', 'Human Rights',
'International Aid', 'Other', 'Poverty'
],
'Community & Culture': [
'City/Town', 'County', 'Heritage', 'LGBT', 'Language',
'Medieval', 'Nationality', 'Other', 'Renaissance', 'State'
]
};

                                                           event.js

To achieve this, on the click action of the topic in the left side menu, we have to somehow remember the topic and return the subtopics according to it from the dictionary dynamically.

Following this approach: A controller is needed to remember the topic selected from the left side rail. We set the properties on the controller to achieve this thing. This is where the ‘Getters’ and ‘Setters’ come to help.

 

import Ember from 'ember';
import { eventTopics } from 'open-event-frontend/utils/dictionary/event';
import { keys, uniqBy } from 'lodash';

const { Controller, computed } = Ember;

export default Controller.extend({
imageTopic: keys(eventTopics)[0],

topics: computed(function() {
return keys(eventTopics);
}),

imageObjects: computed('imageTopic', 'model', function() {
let subTopics = eventTopics[this.get('imageTopic')];
let filteredImageArray = this.get('model').filter(function(obj) {
return (subTopics.includes(obj.name));
});
filteredImageArray = uniqBy(filteredImageArray, 'name');
return filteredImageArray;
}),

actions: {
setImagePart(imageTopic) {
this.set('imageTopic', imageTopic);
},
openModal() {
this.set('isModalOpen', true);
}
}
});

                                             system-images.js(controller)

 

{{#tabbed-navigation isVertical=true}}
{{#each topics as |topic|}}
<a href="#" class="link item {{if (eq imageTopic topic) 'active'}}" {{action 'setImagePart' topic}}>{{topic}}</a>
{{/each}}
{{/tabbed-navigation}}

                                          system-images.hbs(template)

When a link from the left side menu is clicked, an action named “setImagePart” is triggered and the controller listens to the action. Here, we are passing a parameter called ‘topic’ from the template and getting it in the controller as ‘imageTopic’. The next part of the action is to set the property of the object Controller i.e the “setImagePart” action sets the imageTopic (in this case overrides) property and sets it to the selected one. Thus, we now have the controller with the data selected from the left side menu saved in a property called imageTopic.

Now as we can see we have imported the eventTopics object from the dictionary.

Next task is to get the respected subtopics present in the dictionary. Now since we have set the ‘imageTopic’ property, we can access it to get the subtopics simply by getter “this.get(‘imageTopic’)”. Thus the subTopics (values of the eventTopics object) are returned.

Resources: https://guides.emberjs.com/v1.10.0/object-model/computed-properties/

Continue ReadingUsing Getter and Setter to set Properties and Manipulate Responses to Templates in Ember JS on Open Event Front-end

Open Event Server: Working with Migration Files

FOSSASIA‘s Open Event Server uses alembic migration files to handle all database operations and updations.  From creating tables to updating tables and database, all works with help of the migration files.
However, many a times we tend to miss out that automatically generated migration files mainly drops and adds columns rather than just changing them. One example of this would be:

def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.add_column('session', sa.Column('submission_date', sa.DateTime(), nullable=True))
    op.drop_column('session', 'date_of_submission')

Here, the idea was to change the has_session_speakers(string) to is_session_speakers_enabled (boolean), which resulted in the whole dropping of the column and creation of a new boolean column. We realize that, on doing so we have the whole data under  has_session_speakers lost.

How to solve that? Here are two ways we can follow up:

  • op.alter_column:
    ———————————-

When update is as simple as changing the column names, then we can use this. As discussed above, usually if we migrate directly after changing a column in our model, then the automatic migration created would drop the old column and create a new column with the changes. But on doing this in the production will cause huge loss of data which we don’t want. Suppose we want to just change the name of the column of start_time to starts_at. We don’t want the entire column to be dropped. So an alternative to this is using op.alter_column. The two main necessary parameters of the op.alter_column is the table name and the column which you are willing to alter. The other parameters include the new changes. Some of the commonly used parameters are:

  1. nullable Optional: specify True or False to alter the column’s nullability.
  2. new_column_name – Optional; specify a string name here to indicate the new name within a column rename operation.
  3. type_Optional: a TypeEngine type object to specify a change to the column’s type. For SQLAlchemy types that also indicate a constraint (i.e. Boolean, Enum), the constraint is also generated.
  4. autoincrement –  Optional: set the AUTO_INCREMENT flag of the column; currently understood by the MySQL dialect.
  5. existing_typeOptional: a TypeEngine type object to specify the previous type. This is required for all column alter operations that don’t otherwise specify a new type, as well as for when nullability is being changed on a column.

    So, for example, if you want to change a column name from “start_time” to “starts_at” in events table you would write:
    op.alter_column(‘events’, ‘start_time’, new_column_name=’starts_at’)
def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.alter_column('sessions_version', 'end_time', new_column_name='ends_at')
    op.alter_column('sessions_version', 'start_time', new_column_name='starts_at')
    op.alter_column('events_version', 'end_time', new_column_name='ends_at')
    op.alter_column('events_version', 'start_time', new_column_name='starts_at')


Here,
session_version and events_version are the tables name altering columns start_time to starts_at and end_time to ends_at with the op_alter_column parameter new_column_name.

  • op.execute:
    ——————–

Now with alter_column, most of the alteration in the column name or constraints or types is achievable. But there can be a separate scenario for changing the column properties. Suppose I change a table with column “aspect_ratio” which was a string column and had values “on” and “off” and want to convert the type to Boolean True/False. Just changing the column type using alte_column() function won’t work since we need to also modify the whole data. So, sometimes we need to execute raw SQL commands. To do that, we can use the op.execute() function.
The way it is done:

def upgrade():
    ### commands auto generated by Alembic - please adjust! ###
    op.execute("ALTER TABLE image_sizes ALTER full_aspect TYPE boolean USING CASE 
            full_aspect WHEN 'on' THEN TRUE ELSE FALSE END", execution_options=None)

    op.execute("ALTER TABLE image_sizes ALTER icon_aspect TYPE boolean USING CASE 
            icon_aspect WHEN 'on' THEN TRUE ELSE FALSE END", execution_options=None)

    op.execute("ALTER TABLE image_sizes ALTER thumbnail_aspect TYPE boolean USING CASE 
            thumbnail_aspect WHEN 'on' THEN TRUE ELSE FALSE END"execution_options=None)

For a little more advanced use of op.execute() command will be:

op.alter_column('events', 'type', new_column_name='event_type_id')
    op.alter_column('events_version', 'type', new_column_name='event_type_id')
    op.execute('INSERT INTO event_types(name, slug) SELECT DISTINCT event_type_id, 
                lower(replace(regexp_replace(event_type_id, \'& |,\', \'\', \'g\'),
                \' \', \'-\')) FROM events where not exists (SELECT 1 FROM event_types 
                where event_types.name=events.event_type_id) and event_type_id is not
                null;')
    op.execute('UPDATE events SET event_type_id = (SELECT id FROM event_types WHERE 
                event_types.name=events.event_type_id)')
    op.execute('ALTER TABLE events ALTER COLUMN event_type_id TYPE integer USING 
                event_type_id::integer')

In this example:

  • op.alter_column() renames the column type to event_type_id of events table
  • op.execute() does the following:
  • Inserts into column name of event_types table the value of event_type_idN (which previously contained the name of the event_type) from events table, and
  • Inserts into slug column of event_types table the value of event_type_id where all letters are changed to lowercase; “& ” and “,” to “”; and spaces to “-”.
    1. Checks whether a type with that name already exists so as to disallow any duplicate entries in the event_types table.
    2. Checks whether the event_type_id is null because name of event_types table cannot be null.

You can learn more on Alembic migrations here: http://alembic.zzzcomputing.com/en/latest/ops.html

Continue ReadingOpen Event Server: Working with Migration Files

Formatting of ISO8601Date.java class in Open Event Android App

ISO8601Date.java is an util class in Open Event Android App which comprises of all the required date manipulation functionalities required by the application to parse the dates from the api given in ISO8601 format. Previous implementation of the class consisted of functions which needed multiple lines of function call in the main code. Due to this reason the util class was formatted in a way so that the function call can be simplified and improve the quality of our codebase.

1. Previous Implementation of ISO8601Date.java class

The previous implementation of the ISO8601Date.java class had a number of functions needed for date manipulations in it. However when we used to call them in the code they used to take up several lines which demonstrated that we didn’t use the possibility of an util class to the best of our utilization.

An example illustrating this fact is given below:

Example 1: (In SessionListAdapter.java)

String date = ISO8601Date.getTimeZoneDateString(ISO8601Date.getDateObject(session.getStartTime())).split(",")[0] + "," +ISO8601Date.getTimeZoneDateString(ISO8601Date.getDateObject(session.getStartTime())).split(",")[1];

The principal case is from SessionListAdapter.java class where we are utilizing the ISO8601Date.java util class for finding the start time. It can be perceived how various lines including the split functions are utilized for the date manipulation.

2. Current Implementation of ISO8601Date.java class

The factors taken into account for the current implementation of the util class were:

  1. To ensure we write generic functions which can be used in multiple places in the app.
  2. The calling of the function is enough to do what is required.

These factors were the key points for rewriting the util class and ensuring the class is easy to use with enough commenting to explain what was going on in each function.  The idea was to write all the complex function calling code within the function itself.

With the present execution of the class the codebase got more basic as for each situation a straightforward one line call was sufficient to give the output we needed as demonstrated below:

Example 1: (In SessionListAdapter.java)

String date = ISO8601Date.getDateFromStartDateString(session.getStartTime());

Example 2: (In SessionDetailActivity.java)

String startTime = ISO8601Date.getTimeFromStartDateString(session.getStartTime());

The advantage now is, whenever we have to use a new function related to date manipulation we simply have to create one in the util class and provide a simple one line way of calling it in our main code to make the codebase look straightforward. The examples shown above are the same ones which were illustrated before. The multiple lines which they took for calling of a function didn’t make the util class to the best of our use. As we can see with current examples, the new class ensured the function handled the complex stuff within itself without delegating it to the main code.

Related Links

Continue ReadingFormatting of ISO8601Date.java class in Open Event Android App

Nested Routes in Ember JS in Open Event Frontend

When defining routes in ember, there is one very important thing to keep in mind. We should only nest our routes when our UI is nested. Sometimes it is necessary to display a template inside another template and here we use nested routes.

Let’s now learn how to create nested routes. We can take a look at the notifications page in our Open Event Frontend for better understanding.

Here the part in red is common to all the sub-routes of notification, thus one method of achieving this could be copy-pasting the same code in all the sub-routes. Obviously this is not the correct method and it increases the code redundancy.

The correct method here is, using nested routes.

ember generate route notifications
ember generate route notifications/index
ember generate route notifications/all

Here notification is the parent route and index, all are it’s nested or sub-routes. It can be seen in router.js in the given form

this.route(‘notifications’, function() {
   this.route(‘all’);
});

But wait we see no route for notifications/index…. did something go wrong ?

 

No. At every level of nesting, ember automatically creates a route for the path ‘/’ named index. So the above code snippet in router.js is equivalent to

this.route(‘notifications’, function() {

   this.route(‘index’,{ path: ‘/’});
   this.route(‘all’);
});

Now let’s have a look at our parent route ie /notifications. As stated above only the part in red has to be present here, So we have added semantic-ui’s header, buttons and used link-to helper to link them to respective route. An interesting thing to note here is that ‘Mark all read’ is not present in both its sub routes, so we need to check the route before displaying this button. We have checked the current route using session.currentRouteName and only when the current route is not notifications/all we display the button.

<h1 class=“ui header”>{{t ‘Notifications’}}</h1>
<div class=”ui divider”></div>
<div class=“row”>
 {{#link-to ‘notifications’}}
   <button class=“ui button”>{{t ‘Unread’}}</button>
 {{/link-to}}
 {{#link-to ‘notifications.all’}}
   <button class=“ui button”>{{t ‘All’}}</button>
 {{/link-to}}
 {{#if (not-includes session.currentRouteName ‘notifications.all’)}}
   <button class=“ui button right floated”>{{t ‘Mark all read’}}</button>
 {{/if}}
</div>
{{outlet}}

We have added the {{outlet}} helper in our notifications.hbs where we want our nested templates to be displayed. For understanding we can imagine this as the whole code of notifications/all is being copied into this outlet helper i.e notifications/all.hbs is rendered into the {{outlet}} of notifications.hbs

Let’s now have a look at our sub-route i.e notifications/all.hbs. We now know that this will be rendered in the red part stated below

We have added Semantic-Ui’s segments class for every notification. A blue colour has been added to the segments if the notification is not read. We have used Semantic-Ui’s grid class to structure the content inside each notifications. We are getting date object from js and to convert it into human readable format we have used moment like {{moment-from-now notification.createdAt}}

{{#each model as |notification|}}
 <div class=“ui segment {{unless notification.isRead ‘blue’}}”>
   <div class=“ui grid”>
     <div class=“row”>
       <div class=“eight wide column”>
         <h4 class=“ui header”>{{notification.title}}</h4>
         <p>{{notification.description}}</p>
       </div>
       <div class=“eight wide column right aligned”>
         <i class=“checkmark box icon”></i>
       </div>
     </div>
     <div class=“row”>
       <div class=“ten wide column”>
         <button class=“ui blue button”>{{t ‘View Session’}}</button>
       </div>
       <div class=“six wide column right aligned”>
         <p>{{moment-from-now notification.createdAt}}</p>
       </div>
     </div>
   </div>
 </div>
{{/each}}

We have reused notifications/all.hbs for index route by explicitly defining templateName: ‘notifications/all’, in notifications/index.js.

Additional Resources

Continue ReadingNested Routes in Ember JS in Open Event Frontend

Adding User Route in Ember.js to Admin UI of Open Event Frontend

The Users tab in Admin routes, lets the admin have a check on all the users who have ever used our website. We in Open-Event-Frontend have classified the users into active and deleted users. This way an admin has both present and past records.

To create the users page we’ll run the following command

ember generate route admin/users

This will create

This command will also add  this.route(‘users’);  to router.js

Now let’s understand the content of each of these files

  1. User.js

In admin/users.js we have used titletoken helper to set the title of the tab. Here we have created the user model and added attribute like name, email, status, systemRoles, eventRoles, createdAt and lastAccessedAt. We have returned this model from the js file to template.

import Ember from ’ember’;

const { Route } = Ember;

export default Route.extend({
 titleToken() {

     return this.l10n.t(‘User’);

 },
 model() {
   return [{
     name        : ‘Test name 1’,
     email       : ‘Testname1@gmail.com’,
     status      : ‘active’,
     systemRoles : [‘unverified user1’, ‘unverified user2’],
     eventRoles  : [
       {
         name  : ‘Organizer’,
         event : {
           name: ‘Event One’
         }
       },
       {
         name  : ‘Organizer’,
         event : {
           name: ‘Event Two’
         }
       }
     ],
     createdAt      : new Date(),
     lastAccessedAt : new Date()
   }];
 }
});

 

  1. User.hbs

In template we have created a table and added classes like stackable and compact. Stackable class makes the table responsive and stacks all the rows for devices with smaller screen size. Compact class helps to show more number of rows at a time.

Then in the template we iterate through the model using a loop. Here we have used other semantic-ui elements like ui ordered list , ui label, ui-popup inside the table. We are getting date object from js and to convert it into human readable format we have used moment like {{moment-from-now user.lastAccessedAt}}

 <table class=“ui compact stackable very basic table”>
   <thead>
     <tr>
       <th>{{t ‘Name’}}</th>
       <th>{{t ‘Email’}}</th>
       <th>{{t ‘Status’}}</th>
       <th>{{t ‘System Roles’}}</th>
       <th>{{t ‘Event Roles’}}</th>
       <th>{{t ‘User Links’}}</th>
       <th>{{t ‘Member Since’}}</th>
       <th>{{t ‘Last Access’}}</th>
       <th>{{t ‘Options’}}</th>
     </tr>
   </thead>
   <tbody>
     {{#each model as |user|}}
       <tr>
         <td>
           {{user.name}}
         </td>
         <td>
           {{user.email}}
         </td>
         <td>
           {{#if (eq user.status ‘active’)}}
             <div class=”ui green label”>{{t ‘Active’}}</div>
           {{else}}
             <div class=“ui red label”>{{t ‘Inactive’}}</div>
           {{/if}}
         </td>
         <td>
           <div class=”ui ordered list”>
             {{#each user.systemRoles as |systemRole|}}
               <div class=”item”>{{systemRole}}</div>
             {{/each}}
           </div>
         </td>
         <td>
           <div class=“ui ordered list”>
             {{#each user.eventRoles as |eventRole|}}
               <div class=“item”>{{eventRole.name}} ({{eventRole.event.name}})</div>
             {{/each}}
           </div>
         </td>
         <td>
           <div class=“ui ordered list”>
             <div class=“item”>
               <a href=‘#’ target=‘_blank’ rel=‘noopener’>{{t ‘Sessions’}}</a>
             </div>
             <div class=“item”>
               <a href=‘#’ target=‘_blank’ rel=‘noopener’>{{t ‘Events’}}</a>
             </div>
             <div class=“item”>
               <a href=‘#’ target=‘_blank’ rel=‘noopener’>{{t ‘Tickets’}}</a>
             </div>
             <div class=“item”>
               <a href=‘#’ target=‘_blank’ rel=‘noopener’>{{t ‘Settings’}}</a>
             </div>
           </div>
         </td>
         <td>
           {{moment-from-now user.createdAt}}
         </td>
         <td>
           {{moment-from-now user.lastAccessedAt}}
         </td>
         <td>
           <div class=“ui vertical compact basic buttons”>
             {{#ui-popup content=(t ‘View’) class=’ui icon button’ position=’left center’}}
               <i class=“unhide icon”></i>
             {{/ui-popup}}
             {{#ui-popup content=(t ‘Edit’) class=’ui icon button’ position=’left center’}}
               <i class=“edit icon”></i>
             {{/ui-popup}}
             {{#ui-popup content=(t ‘Delete’) class=’ui icon button’ position=’left center’}}
               <i class=“trash outline icon”></i>
             {{/ui-popup}}
           </div>
         </td>
       </tr>
     {{/each}}
   </tbody>
 </table>

 

  1. Users-test.js
ember timport { test } from ’ember-qunit’;
import moduleFor from ‘open-event-frontend/tests/helpers/unit-helper’;

moduleFor(‘route:admin/users’, ‘Unit | Route | admin/users’, []);

test(‘it exists’, function(assert) {
 let route = this.subject();
 assert.ok(route);
});

Here we can testing the existence of our route. These tests are run using the command ember test.

Our user page is ready now. You can see how the user’s information is available in a formatted manner on the page. We have achieved our goal, by using the above mentioned files.

Additional Resources

Continue ReadingAdding User Route in Ember.js to Admin UI of Open Event Frontend

Integration Testing of an Ember Component in Open Event Frontend

Open Event Frontend uses ember components which are reused several times throughout the project, making these components is one thing but we should also ensure they work as expected. To ensure this we need integration tests.How to write an integration test for event-map component? Three files are generated when we generate our event-map component from the command shell. They are namely:

event-map.js

event-map.hbs

event-map-test.js

We are familiar with the above three files as:

  1. event-map.js helps us to provide properties to our event-map.hbs
  2. event-map.hbs is where we define the structure of our component.
  3. event-map-test.js is where we define integration test for our component. Also, which is the current topic for discussion.

Testing

In order to test the rendering of the component, we define an integration test for that component. In integration tests we don’t have to launch our whole application and navigate to the location where our component is present. This makes it ideal for testing components. Have a look at the following sample integration test file.

import { test } from 'ember-qunit';
import moduleForComponent from 'open-event-frontend/tests/helpers/component-helper';
import hbs from 'htmlbars-inline-precompile';

moduleForComponent('public/event-map', 'Integration | Component | public/event map');

let event = Object.create({ latitude: 37.7833, longitude: -122.4167, locationName: 'Sample event location address' });

test('it renders', function(assert) {
  this.set('event', event);
  this.render(hbs `{{public/event-map event=event}}`);
  assert.equal(this.$('.address p').text(), 'Sample event location address');
});

So let’s break down this code line by line-

In the first line we have imported test from ‘ember-qunit’ (default unit testing helper suite     for Ember) which contains all the required test functions. For example, here we are using test function to check to check the rendering of our component. We can use test function multiple times to check multiple components.

Next, we are importing moduleForComponent from ‘open-event-frontend/tests/helpers/component-helper’ helper which helps in finding the component by its name.

Next,  we are importing hbs from ‘htmlbars-inline-precompile’ which basically imports precompile HTMLBars template strings within the tests via ES6 tagged template strings.

The moduleForComponent helper will find the component by name (event-map) and its template. The component we are testing here is a map-related. Therefore, to test this, we need to pass a dummy object consisting of latitude, longitude and locationName. The object data must render correctly in our app.

Inside our test function, this.set(‘event’, event) assigns a variable ( here event ) to our test context.

this.render (hbs `{{public/event-map event=event}}`) lets us create a new instance of the component by declaring the component in template syntax, as we would in our application.

assert.equal(this.$(‘.address p’).text(), ‘Sample event location address’) is basically a check between actual and expected arguments.

For a simple component like a table or a basic UI only component, it is not necessary to pass any object to the component. Only the rendered component can be tested as well. Apart from checking the component rendering we can perform tests on it by using test functions as described above. After writing the integration tests for components, simply run ember test –server on the terminal to see if all the tests have passed or not.      

Find out more about Integration testing in ember –

Ember guides, EmberIgniter

Continue ReadingIntegration Testing of an Ember Component in Open Event Frontend

Using Dynamic segments to Reduce Code Redundancy of Recurring HTML in Open Event ember Frontend

While developing web apps, at times we require the same HTML for different pages in our app. This leads to redundancy and low code-reusability. This can be well managed in ember.js by using dynamic segments in our routes.

In Open Event Front-end we have a route named /sessions where we want to show the details of the event’s sessions and we want to categorize the sessions in all, pending, accepted, confirmed and rejected sessions hence want to create the following subroutes under it.

events/<event-id>/sessions
events/<event-id>/sessions/pending
events/<event-id>/sessions/accepted
events/<event-id>/sessions/confirmed
events/<event-id>/sessions/rejected

All of these subroutes show different data based on the routes in a table with exactly same fields. So if we use dynamic segments, we can decrease code redundancy and increase code reusability. So let us see how to add these subroutes as dynamic segments.

Firstly, we have to add a dynamic part (pending, accepted, confirmed, rejected) under our URL /sessions . For this, edit the following code snippet to the router.js file. In place of list write the name of route handler which handles our subroutes and in place of session_status write any identifier you want as session_status is the dynamic part which changes according to subroutes. In our case it will be pending, accepted, confirmed or rejected.

     this.route('sessions', function() {
        this.route('list', { path: '/:session_status' });
      });

To display all the sessions in our /sessions route, we have to edit index route handler and return data from model hook. Now when we hit  /sessions end point, the template which we are using redundantly, i.e. list.hbs, gets data from a model hook of this route handler.

Next we need to define a model hook in our list.js file which returns data for the dynamic routes. In list.js, we would want to change the title of our page according to the dynamic segments. These dynamic segments are available under model hook in this route under param parameter. We are using this.set which sets the provided key or path to the value. Make this available in titleToken function and by applying simple switch case, we can change the title dynamically.

Till now, we could access our dynamic segments by manually changing the URL. Let’s add a link to do this transition automatically for us. For this, we edit our session.hbs file and provide links using a linkto helper. One thing to take care here is that we should pass the dynamic segments along with the link-to helper.

{{#link-to 'events.view.sessions.list' 'pending' class='item'}}

Here, pending is the dynamic segment which we are passing to our route handler. Similarly, we can make the links for all our dynamic segments. Also in this template, we should provide outlets for the common template i.e list.hbs which will be reused by other dynamic subroutes. And finally, we define our reusable template in list.hbs file.

Now when we hit on different links we are redirected to different routes which are using different data but same templates. Also, we can see this transition in our URL and title.

To know more about dynamic segments refer to Ember guide.

Continue ReadingUsing Dynamic segments to Reduce Code Redundancy of Recurring HTML in Open Event ember Frontend

Uploading Images via APIs in the Open Event Server

APIs help us to send and receive data in some particular data format that can then be used individually or integrated with a frontend UI. In our case, the entire API server is used to manage all the requests from the frontend and send back the necessary response. Usually, the application is to send simple form data which is then stored into the backend database and a valid jsonapi response is shown. However other than normal text, url, datetime data one very important data is media files, in our case event images, user images, slides, etc. In this blog, we will particularly deal with how we can upload images in the server using API.

Sending Data

Firstly, we need to decide how do we send the data in the post request of the API. So we are sending a base64 encoded string representing the image along with the image extension appended to it, for example, data:image/png;base64,iVBORw0KGgoAAAANS. This is a widely used format for showing images over the web. So when we send a POST request we send a json encoded body like:

{
    "data": "data:image/png;base64,iVBORw0KGgoAAAANS"
}

Converting Base64 Data to Image

There are 2 parts of the data in the string that we receive. The first part basically tells us the format of the image(.gif in this case) and string encoding(base64 in this case), the second part gives us the encoded string. So, from the first part, we extract the file extension for the image file to be created. We use uuid.uuid4() for a random filename.

filename = '{}.{}'.format(str(uuid.uuid4()).data.split(";")[0].split("/")[1])

Now to write the base64 encoded string as an image file, we first need to get only the encoded string part from the data and then decode it. We use string decode function of python for the decoding purpose. Then we write the data to the image file and save it.

file.write(data.split(",")[1].decode("base64")

API Response

Finally using whatever logic you are using for serving your static files, you generate the static file path for the image saved. And then create another json encoded response which returns you the url for the saved image in the server.

{
    "url": "https://xyz.storage.com/asd/fgh/hjk/1233456.png"
}

And there you have your image uploaded and served.

Continue ReadingUploading Images via APIs in the Open Event Server