DEV Community: Thierry

Free Maker accounts for Stream

Thierry — Wed, 17 Mar 2021 21:03:11 +0000

As some of you know I've been working on my startup Stream for about 5 years now. We've just raised a large series B and it enabled us to make Stream free for hobby/side projects. We announced it today and I'm pretty excited to see what people will build :)

Stream is available for iOS, Android, React, RN and Flutter. I think the Flutter SDK is especially interesting for side projects. It's been amazing to see what small teams can ship on that platform.

Pusher Chatkit Migration

Thierry — Mon, 23 Mar 2020 18:11:28 +0000

I just read the news about Pusher Chatkit shutting down. They are only giving people 30 days to migrate their data so this is going to get a little hectic.

Our chat platform is a great alternative to Chatkit so I've started creating a guide on how to migrate from Pusher Chatkit to Stream. It's not finished yet, bit of a WIP. If anyone needs help feel free to reach out.

Corona projects?

Thierry — Sat, 14 Mar 2020 19:46:47 +0000

I suspect that quite a few of us are working on projects related to corona virus. If you need chat or activity feed technology for a non-profit project that's helping to mitigate the coronavirus impact DM me and I'll set up a free Stream account. EDtech, telemedicine, DMV, groceries, social distancing, contact research. Anything goes #flattenthecurve

There's quite a few cool projects popping up so far:

Build a WhatsApp Clone on Android With Kotlin – Part 1

Thierry — Fri, 31 Jan 2020 15:07:01 +0000

Android development has come a long way over the last few years. The Jetpack components significantly speed up development. In this tutorial, we’ll build a functional clone of WhatsApp with Kotlin. Building a messaging app used to be difficult; in this tutorial, you’ll get a chat experience up and running in roughly 20 minutes. The first part of this tutorial focuses on the chat functionality of WhatsApp, and in part 2, we’ll cover audio and video calling. Time to get started!

If you get lost during this tutorial you can have a look at:

The end result will look similar to this:

Clone the WhatsApp Starter Repo

Start by cloning the starter branch of the WhatsApp Clone Github repo:

git clone -b starter git@github.com:GetStream/WhatsApp-Clone-Android.git

The starter branch sets up a few simple things so you can skip the boilerplate:

Dependencies in the build.gradle files
Colors
Menu items
Drawables

Open the WhatsApp-Clone-Android directory in Android Studio and wait for the Gradle sync to complete. For this tutorial, you’ll want to use the Pixel 3 / API Level 29 Emulator for testing. After you’ve got that setup run the application. You should now see this empty screen:

Setup the Home Screen

As a first step, we’re going to create the home screen of your app. Which will look like this:

As an experienced Android developer, you’ll see a few things in this screen:

In this tutorial, we’ll follow Google’s recommendation of having 1 activity and many fragments. We’ll connect the fragments using the navigation component. Let’s get started.

Open up activity_main.xml and replace the TextView tag with a NavHostFragment:

The app:navGraph property tells the navigation component to use your navigation/nav_graph.xml file for navigation. Let’s take a moment to review the contents of nav_graph.xml:

Note how @id/nav_home is specified as the startDestination in the navigation tag. This makes the navigation component automatically load the homeFragment. As a next step, we’re going to make the homeFragment look like WhatsApp.

Open up fragment_home.xml and replace the contents with this:

The TabLayout provided by the material UI package combined with the ViewPager2 gives you the helpful swipeable tabs that you see in the WhatsApp interface. The FloatingActionButton handles the UI for creating a new conversation.

As a next step open up com.example.whatsappclone.ui.home.HomeFragment.kt
You’ll see an empty fragment class with a TODO. Let’s start by updating the constructor to point to the R.layout.fragment_home layout. Update the HomeFragment class to look like this:

class HomeFragment : Fragment(R.layout.fragment_home) {
}

This short syntax for the fragment creation is enabled by the androidx.navigation:navigation-fragment-ktx dependency. It's a nice improvement compared to overwriting the onCreate method. If you run your app, you’ll see the following UI:

The tabs are working, but the viewPager and the toolbar aren’t setup yet. Go back to com.example.whatsappclone.ui.home.HomeFragment.kt and update it to match this:

This looks like much code, but it’s pretty simple once you take a moment to review. The viewPager2 requires an adapter. We’ve set up this adapter to return an emptyFragment for tabs 0, 2, and 3 and return a ChannelListFragment for tab number 1.

The loop over the tabs just below getColorStateList handles the tint for the camera icon. This makes sure that it looks gray when it’s not selected and white when active.

The TabLayoutMediator connects the viewpager 2 with the tab UI. Try rerunning the app, and you’ll see it now looks much closer to the WhatsApp interface. The toolbar is rendering, and you can swipe through the tabs.

Channel List

Next, we’re going to render a list of channels/conversations. First, open up the empty fragment_channel_list.xml layout and replace it with this content:

We are using the ChannelListView which is a custom view provided by Stream. This view makes it easy to render a list of channels.

Note: You can also build your channel list view using the underlying API client. (But that’s more work, so we’re not doing it in this tutorial).

Next op up ChannelListFragment.kt. You’ll see an empty fragment. Replace the file’s content with this:

A few things to note in the above ChannelListFragment. We’re instantiating the Stream client and connecting a user. After that we configure the channelList component using viewModel.setChannelFilter(filter). In the tutorial, we’re using the example API key provided by Stream. Note that this example account is wiped regularly. So if you’re building a production app, you’ll want to register to get your own Stream Chat API key.

We’re also using the modern Kotlin syntax for getting a viewModel which is pretty nifty:

val viewModel: ChannelListViewModel by viewModels()

Last, observe how we’re using the navigation component and Kotlin safe args to navigate from the channel list to the channel. The HomeFragmentDirections class is auto-generated from nav_graph.xml, and Android knows how to navigate between the various views using the defined actions in nav_graph.xml. The argument tags in nav_graph.xml ensure type safety:

Time to run your application. The resulting code should render an app that looks like this:

Channel UI

You’ll notice that if you click on a channel, you see an empty page. In this next step, we’re going to implement the chat/channel interface. The channel UI will look like this:

This UI is a MessageListView and a custom message input. For the message input view, we’ll use two-way databindings.

As a first step, open up the empty fragment_channel.xml and replace the content with:

Next, open up the ChannelFragment.kt file and replace its contents with this:

package com.example.whatsappclone.ui.channel

A few things to note in the above code. We are instantiating a Stream channel object using the safe args passed by the Navigation Component:

var channel = client.channel(args.channelType, args.channelId)

And we are creating a viewChannel based on that

If you run the app you’ll now see a channel list with a very minimalistic message input view:

Custom Message Input View & Data Binding

In this section of the tutorial, we’ll build our message input view. This is a great use case for Google’s live data two-way data-binding feature. Note how the design changes slightly if the user has entered text. This first image shows the layout when no text is entered:

The next image displays the layout when the user entered the text. Note how the icon changed from "record" into "send". Additionally, the camera icon disappeared:

Open the empty view_message_input.xml layout and update it to match this content:

Most of this layout will be familiar to you now. There is a floating action button (FAB) for the voice record icon and a constraint layout with a background for the message input and buttons. The most exciting bit is this tag on the EditText view:

android:text="@={viewModel.messageInputText}"

The @= syntax creates a double way binding between viewModel.messageInputText and the edit text element. As soon as one of the items changes, the other changes as well. Now that we have the double way binding setup, we can use it to:

Change the voice icon into a send icon
Remove the camera icon

Note how we import two utility methods using the data’s import tag:

Next, we apply the view utility method on the take picture button:

android:visibility="@{TextUtils.isEmpty(viewModel.messageInputText) ? View.VISIBLE : View.GONE}"

That line causes the android visibility to be set to GONE whenever the user types a message. For the floating action button, we switch the icon like this:

android:src="@{TextUtils.isEmpty(viewModel.messageInputText) ? @drawable/ic_mic_black_24dp : @drawable/ic_send_black_24dp}"

Now that we have the layout ready let's create our own custom message input view. Open the file com.example.whatsappclone.ui.views.MessageInputView.kt and update it to match this content:

Next, open up fragment_channel.xml and replace the EditText node with this:

https://gist.github.com/nparsons08/df9da66e2dc467587849f716d9f36980

Last, open up ChannelFragment.kt and uncomment this line:

//binding.messageInputView.setViewModel(viewModel!!, this)

Now when you run your app, you’ll see a functional and much better-looking message input. Data binding is a compelling concept. You can learn more about it in this tutorial.

Channel List ViewHolder

The Channel List already looks quite good. Let’s see if we can give it a little upgrade though. We’re going to use a custom viewHolder to customize the design.

Open the file CustomChannelListItemViewHolder.kt and replace the empty viewholder with the following code:

The above code updated the date format to be closer to WhatsApp’s layout. To use this viewHolder, we need to create a viewHolderFactory and apply it to the ChannelList view.

Open the file CustomViewHolderFactory.kt and replace it with the following code:

As the last step, we need to tell the ChannelList view about the custom view holder. Open ChannelListFragment.kt and uncomment this line:

// adapter.setViewHolderFactory(CustomViewHolderFactory())

If you run the app, the date format of the channel list will now look like WhatsApp’s format. If you got stuck at any point during this tutorial, note that you can always find the full source code on GitHub.

Customizing the Stream Chat Android SDK

The Views and ViewModels provided by stream-chat-android make it extremely simple to add chat to your application. Depending on your use case, there are several options available to customize the UI.

The most common tweaks are handled using properties. This allows you to, for instance, change the message colors. The tutorial used this approach in fragment_channel.xml to customize the colors and background:

<com.getstream.sdk.chat.view.MessageListView
            android:id="@+id/messageList"
            android:layout_width="match_parent"
            android:layout_height="0dp"
            android:layout_marginBottom="10dp"
            android:background="@color/channel_background"
            app:layout_constraintBottom_toTopOf="@+id/messageInputView"
            app:layout_constraintEnd_toEndOf="parent"
            app:layout_constraintStart_toStartOf="parent"
            app:layout_constraintTop_toBottomOf="@+id/toolbar"
            app:streamMessageBackgroundColorMine="@color/message_yours"
            app:streamMessageBackgroundColorTheirs="@color/message_theirs"
            />

The views allow you to specify your layout, enabling you to make simple layout changes.
For more considerable UI changes, you can use your ViewHolder. In this tutorial, we used that approach for customizing the ChannelListView.
Alternatively, you can also use the low-level client to build your UI or your view models. In this tutorial, we did that for the MessageInputView.

With these 4 levels of customizations, you can build any chat or messaging experience. The Android Chat Docs cover the chat SDK in more detail.

Final Thoughts

I hope you enjoyed this tutorial. It’s incredible how quickly you can build an app like WhatsApp these days. Kotlin and Android Jetpack have been a significant step forward for the Android ecosystem. Looking at a successful app like WhatsApp and trying to build it is a great way to learn. For a real app, you’ll, of course, want to come up with something new and different. You can use a similar approach to build any chat or messaging experience. Here are a few links to help out if you got stuck along the way or want to learn more:

Stream also has tutorials available for iOS Chat, React Chat, and React Native Chat in case you need to support multiple platforms.

Note: Part 2 of this tutorial is expected to go live in February and will explain how to add video and voice calls to your app.

Happy Chatting!

Styled Components vs CSS

Thierry — Mon, 16 Dec 2019 18:44:13 +0000

Trying to figure out the distribution between CSS fans and styled-components. Let us know which one you prefer:

https://github.com/GetStream/stream-chat-react/issues/100

React Hooks

Thierry — Tue, 10 Dec 2019 22:24:10 +0000

Curious how everyone's experiences have been using React Hooks. Do you prefer writing functional components instead of using classes? Are you still using Redux, or relying on custom hooks?

A New Kind of Android Fragmentation

Thierry — Tue, 29 Oct 2019 13:44:58 +0000

It has been about 5 years since I have been able to spend a dedicated chunk of time working solely on Android development. One of our competitors shut down their product a few months ago, causing a huge inflow of customers all asking for an Android Chat SDK. Unfortunately, our Android team was behind on schedule. #startuplife Long story short, I had the pleasure of doing some Android development again.

It was cool to see how much the ecosystem improved. The constraint layout is really easy to work with and much more performant than the older layouts. The new livedata system reduces quite a bit of boilerplate code. Room is a nice abstraction over SQLlite and the concept of viewmodels (while simple) is quite elegant.

One type of fragmentation became much worse though. If you’re a library author you now have to think about:

Java or Kotlin
Java Callbacks, Android RX observables and/or Kotlin Coroutines
Architecture components: MVVM, MVI, MVP, MVP or MVC?
Proguard
AndroidX

Yes, you can argue that Java and Kotlin are compatible. At the end of the day, you still have 2 sets of docs and halve the people that use your library won’t be happy with the language you choose. If you look at the stats Kotlin still seems much smaller for new apps than Java: https://www.appbrain.com/stats/libraries/details/kotlin/kotlin.

It’s cool to see how Room and Retrofit deal with the callback vs observable difference. If you look at iOS development though there is much less fragmentation.

Android development has improved a lot over the last 5 years. For a library author fragmentation became worse though. I wonder why Google has this wait and see attitude instead of just ensuring that there is 1 best way to do all of these things...

Thoughts on Layer’s API Shutdown

Thierry — Thu, 25 Jul 2019 21:38:43 +0000

Over the past days, we’ve been happily migrating disgruntled Layer customers over to Stream. The surprising announcement of the shutdown of their API on October 30th has been pretty amazing for our growth.

However, as a developer, it annoys me to see a company get bought up and then have their product shut down in such a short amount of time. All those customers placed their trust in a product, a team, and a vision. Shutting it down, especially so soon after acquiring it, seems and feels like a betrayal to those customers. I personally feel that by acquiring a company and customer base, you have an ethical obligation to do everything you can to continue to service those customers, or at least provide a nice exit strategy for them.

For context, here’s the full email from Layer:

We are Sunsetting the Layer Platform

We will be sunsetting the Layer Platform and API on October 30th, 2019.

The platform, features, and functionality of our service will continue with no change from what it is today until that date, including access to export your data.

After October 30th, 2019, the Layer Platform and all services associated with Layer will be shut down in their entirety.

Our priorities are to maintain system uptime and ensure you are able to move off the platform as seamlessly as possible. No features or updates to our SDKs will be published and bugs not related to service uptime or core functionality may not be resolved.

There will be no part of Layer online past this date and no option to continue leveraging the Layer backend services. Similarly, there is no way to take the Layer backend service and self-host it or for us to provide it to you.

Why are we sunsetting the Layer Platform?

1) We do not have a team in place to properly diagnose and resolve the volume of bugs and issues that are arising from our customer base.

2) We do not have a team in place to keep our SDKs up to date, the reality is that critical bugs and failures that we can not resolve are inevitable, sooner or later.

3) While the security built into the Layer platform and organization very much persists, we do not have the team in place to adequately assist you in completing vendor audits or providing verifications as needed.

4) Our key hire running all server operations and infrastructure passed away suddenly and unexpectedly very recently. While we have plans to get additional help there for the remainder of the Layer service, we do not have a sustainable path to ensure system uptime and reliability long term.

5) Barring all of the above, Layer infrastructure costs are both very high and very fixed. We are currently operating the Layer platform at an unsustainable loss.

Closing things Out

On the business side, we definitely messed up and have learned a lot in the process. I know this likely puts you in an extremely tough position and I apologize that I did not have better news to share with you.

I also recognize the timeline is very tight, but it is that way for our mutual safety. What I would not want to happen is that I say we can continue to support you for 6 months and then 4 months from now, we have a critical outage that we can just not resolve with our team. That would put us both in a much, much worse position.

If I can assist in recommending a competitive service, please let me know the use-cases that are most relevant for you.

Thank you,

Shaun VanWeelden
Head of Layer

Migrating from one chat provider to another is rather cumbersome. Stream is trying to make it as easy as possible and offers a fully automated import of Layer data. Have a look at this Github Repo that explains how to export your Layer data and migrate to Stream. So, in theory, you can migrate in a couple of days. Three months feels like an awfully short time though. The dev teams might be busy with other projects, and perhaps they aren’t even actively working on some of these apps.

When Parse shutdown there was at least a clear migration path to competing services. They also provided an open-source solution. It makes sense that Layer doesn’t do that since their core product seems to have a lot of performance, cost and stability issues. Still, a prescribed path for migrating to other services would be ideal.

From the outside you wonder if the shutdown of Layer is caused by chasing hypergrowth. Layer raised $29.5 million and initially started out selling their product to developers and product owners. Once they found out that they couldn’t create the hyper-growth that VCs look for, they pivoted towards a more customer support/marketing vertical. Perhaps many of the technical debt and cost issues with their infrastructure could have been avoided with a slightly less aggressive growth strategy.

This shutdown reminded me a bit of the Parse story, or the Keen and Travis acquisition where most/all of the dev team were replaced.

Here’s a pledge from Stream, as long as I can do something about it we will not:

Raise overly large funding rounds which put the sustainability of the company at risk if crazy growth targets are not hit
Sell to companies that will shut down the product or strip down the development team

Now, I don’t want to be overly harsh with these companies. Sometimes you just don’t have any good options on the table. Especially in this case with one of Layer's team members tragically passing away. There are always events that you can't anticipate. With that caveat in mind, my co-founder Tommaso and I will do our utmost to focus on sustainable growth and ensure that the APIs continue to be available.

The best dev community

Thierry — Tue, 16 Jul 2019 17:50:59 +0000

Dev.to should clearly win the Noonies award for best dev community: https://noonies.hackernoon.com/award/cjxr8yn9weqhp0b129w4ygn5h

Layer webhook issues?

Thierry — Mon, 24 Jun 2019 19:30:54 +0000

Is anyone else experiencing issues with Layer webhooks? One of our customers syncs their Layer chat messages to Stream via webhooks. It seems that today (June 24th) all webhooks from the last 2 weeks were repeated. The end result is that they are sending push notifications/emails to their userbase repeatedly. So far Layer support has unfortunately been unresponsive on this issue. Not quite sure what's going on.

Redux in 2019?

Thierry — Wed, 12 Jun 2019 16:42:42 +0000

I noticed that many new projects adopt either GraphQL and/or React Hooks. Neither of these solve the same issues as Redux... On the other hand it does seem to reduce the need for using Redux. Here at Stream we're still using redux...

How do you all feel about Redux in 2019, do you think it's still useful/relevant?

Discord vs Slack

Thierry — Thu, 06 Jun 2019 03:13:55 +0000

As far as I know both Discord and Slack are using Electron. Somehow Discord's app feels much faster and responsive. Does anybody have some insights into how they achieved this?