Library

In a React application I am working on we are using the Material UI component library, but immediately realized it’s table component did not have the features we needed. Many of the available grid components had the features we needed like sorting, filtering, search, and adjusting column order and size. However, there were only a few components that had the features we needed like exporting to excel and row grouping. Of those few, only ag-Grid had a built-in option for material theme styling. With a little css the grid was styled very similar to the Material UI table.

Another stand-out feature was the ability to pass through the gridOptions a context object that would be available to any custom cell renderer that you implement. This enabled us to pass props that included event handlers that could update the state of a parent component or launch async actions thus giving us the ability to make the grid even more interactive. For example, we were able to integrate commenting through the grid. Here is the table component code and the result.

Ag-Grid is an excellent choice to use as your data grid component. It has all the powerful features you would expect from a solid grid component such as multi-sort and search and essentially every aspect of the grid is customizable so it was easy to adapt to design changes. If you choose ag-Grid you are likely to have a smoother development process.

So look. The mobile world is booming, and the world says everyone has to have a mobile application. The problem is, you may not have the time, money, or resources to make the leap to a native mobile application. So what do you do? Do you go hybrid? Well, maybe, but that has it’s own can of worms. Do you just say forget it and do nothing? HECK NO!!!!!! Do you say, well I already have a web application, maybe I should just optimize it for mobile? This is a very good option. You can still use the resources you have in house while also using much of the same codebase. There is just one problem…It’s still not native. Now that’s not a huge problem when it comes to your application functionality, because you may not need any native device features, but it does pose a problem when it comes down to user experience.

Native vs Web (Mobile UX)

Discovery

So native applications get all the cool stuff. A user can go to the Google Play Store and search for the app they want, then click on install, and BOOM!!!!! Now your shiny new app is sitting on the user’s home screen in all of it’s glory, and that app continues to be at their fingertips until they uninstall it. Now historically with a web app, a user may use Android’s Google Search widget to find a web app or they may just enter the web app’s url in a browser. At this point, they may decide to bookmark the url or just do nothing. This forces them to open up their browser, and enter the web app’s url every time they want to use your web app, and that’s definitely not as easy as just clicking an icon on your home screen.

Engagement

Do you remember how you re­-engaged users when it came to web apps? Through email. You sent out an email saying “Hey User, We love you. Come back”. At that point you hope it made it through the spam filter, and you hope it didn’t get buried in the thousands of other emails they received. What about native apps? Well, you just send them a push notification. Push notifications are quick and straight to the point, and let’s not forget they are touch magnets. I think it’s built in all humans DNA to check and touch every push notification we receive. With a push notification you really don’t have to worry about if a user has seen your message. Mostly likely they have, and if they don’t re-­engage, then it’s probably because your app just isn’t that good :). At any rate. Native applications have it easy when it comes to engaging users.

User Interface

Yo! Web apps are dope when it comes to amazing user interfaces, even in the mobile browser. The problem has always been in how web apps have been presented, basically in the center of a browser that already has it’s own design. Native applications get the luxury of having their own shell which makes for a tight and cohesive design.

So the question now becomes. How do we get a Native Android experience without having a native app?

If you’re a “beast mode” developer you’re probably here because you said to yourself. “I want to build a real time communication app without proprietary technologies”. Now if you’re a novice developer you probably said “I want a chat app, and I want it now”. In any case you are in the right place. I’m going to show you how to build FaceTime in an hour….Ok not really, but I will show a quick and easy way to get a video chat application going. So lets start this thing off right! With the all important question that starts every blog. “What is ___”?

What is WebRTC?

WebRTC is the same as many other technologies looking to solve the problem of how to do real time communication in the browser. For example, under the hood WebRTC is doing the same things that Adobe did with RTMFP. The main difference is WebRTC is not proprietary, and doesn’t require a plugin.

The three APIs that really make WebRTC tick are:

GetUserMedia (camera and microphone access)

PeerConnection (sending and receiving media)

DataChannels (sending non-media directly between clients)

Does this stuff work for native mobile applications?

So were you like me a few years ago when that shiny new toy called WebRTC came to be? You got really excited, while shedding tears of joy, but then you searched for…”WebRTC on mobile”. Yeah my heart dropped too. Nothing. Today things are different. There are now core libraries that Google uses for Chrome that allows for different build targets including Objective-C and Java. What’s really awesome is there are now build scripts out there that make compiling for these targets easier.