Forem: Karan Shah

Google Launches Flutter 2.0: Let's Dig Into Its Basics

Karan Shah — Tue, 27 Apr 2021 09:12:45 +0000

Google announced the release of Flutter 2.0 in an event titled “Flutter Engage,” marking a huge milestone after Flutter 1.0, with the significant development of the UI software development kit. This new update has brought several new features and fixes that are major improvements over the previous version.

This article will explore all the new widgets and added features of Flutter 2.0. You will get a more detailed understanding of the Flutter 2.0 release's most significant changes by walking through this article.

But let’s brush up on the basics first!

What is Flutter?

Flutter is an open-source UI software development kit. Google launched the official version of Flutter in 2015. All the Flutter apps are usually written in Dart language and few other languages for more advanced features in the app. The Flutter platform was initially developed for applications targeting the iOS and Android platforms.

Flutter is the only SDK that offers reactive views without any JavaScript bridge. It compiles your source to machine code with the support of hot reload to get the productivity of interpreted environments. Flutter offered a comprehensive set of features to build web and mobile applications.

Flutter is an open ecosystem with a strong developer community that keeps adding to the core framework and extending it further. With Flutter 2.0, Google has broadened the functioning of Flutter from a mobile framework to a portable framework. This change has given all the apps the opportunity to run on multiple platforms without any hassle.

What's new in Flutter 2.0?

The major improvements in this release include a new client architecture, app bundling, the new navigation layout, and a more unified user experience across multiple platforms. Flutter's client architecture offers a unified client API to define UI's behaviours and build apps that can run on desktop, mobile, or web.

This launch of Flutter 2.0 has also changed the community name from DevTools to FlutterDev Tools. This community works relentlessly, especially to overcome debugging. It will enable the profiling tools to be run in the browser, installed from Visual Studio Code, IntelliJ, Command-Line, and Android Studio to help developers debug by checking for exceptions. Also, this tool is capable of identifying images that have a higher resolution.

Now, let’s dive deeper to explore Flutter 2.0. in detail:

Operating systems and browsers

Before Flutter 2.0 release, the app owners and developers used Flutter 1.0 only for Android and iOS app development projects. However, now with Flutter 2.0, the developers can use the same codebase to port native apps to five operating systems, i.e., iOS, Android, Windows, macOS, and Linux.

Flutter 2.0 developed web experiences for more browsers such as Safari, Chrome, Edge, and Firefox. Flutter has also extended its application even in TVs, cars, and smart home appliances for providing a more holistic digital experience in the computing world.

Flutter 2.0 on the web

One of the most prominent announcements in the Flutter 2 launch was the production-quality support for the web. The early development of the web was massively document-centric. However, with Flutter 2.0, the web-developed platform has been enriched with the state of the art APIs. This allows the development of advanced apps with hardware-driven 2D and 3D graphics and flexible layout.

Flutter’s web support now offers a highly app-centric framework. It helps to build modern webs through these innovative features and approaches. The Google team has released stable web support by making significant progress by performance optimization. They have added a new CanvasKit-powered rendering engine built with WebAssembly for programming languages, enabling deployment on the web and server applications.

The development team has further extended Flutter with text autofill, control over address bar URLs and routing, and PWA manifests. They added keyboard shortcuts, interactive scrollbars, screen reader support for accessibility, increased default content density in desktop modes on macOS, Windows, and Chrome OS. This feature empowers the tool to offer the best of the web platform to clients.

Flutter 2 on desktops

Unlike the previous version that stuck with mobile devices and the web platform. Flutter 2.0 has extended to other device types such as desktops, foldable, and embedded devices. Google has partnered with three industry giants to increase Flutter’s portability in the future.

Canonical is one of the partners responsible for bringing Flutter to desktop, with engineers contributing code to support development and deployment on Linux. Canonical needs to deliver a firm and delightful experience on a wide variety of hardware configurations.

Microsoft is another constant partner continuing to expand its support to Flutter by offering high-quality Windows support. Microsoft contributes to the Flutter engine by supporting foldable Android devices. These devices require new design patterns from the apps that can either expand content and design appropriately.

The third partner is Toyota – an automotive manufacturer planning to bring exclusive digital experience to vehicles by building infotainment systems powered by Flutter. Toyota has partnered with Flutter for its high performance, consistency, fast iteration and developer ergonomics, and, most importantly, smartphone-tier touch mechanics. Flutter’s embedder API will be used for in-vehicle system development.

New Widgets

Flutter offers a large variety of widgets to the developers. It’s by combining this different widget that developers can build the complete UI smoothly. Flutter widgets include a structural element (such as button or menu), stylistic element (such as font or colour scheme), layout aspect (such as padding), and much more.

Google has introduced new capabilities for developers by creating a new widget type customized for various elements. Flutter 2.0 reflects the prominent improvements focusing on the developer's experience. Apart from a new out-of-the-box SDK process, new widgets are being developed in Flutter now and then.

These new widgets are available for both iOS, Android, Windows, macOS, and Linux. This extensive pool of widgets is one of the most important pieces of the development toolkit. These Flutter widgets are bundled with the app design to perform specific functions in order.

For example, the updated scrollbar widget offers top-notch interactiveness in the desktop app. The desktop application also shows down the track; the mouse hovers in the scroll bar along with the option of app customization as per their preferences.

Google Mobile Ads and Plugins For Flutter

Google also launched the beta release of Google Mobile Ads for Flutter. This new Software development kit works with AdMob and AdManager to offer various ad formats, banner, native, interstitial, and rewarded video ads. A demo SDK project initiated for a few customers, such as Sua Música- the largest music platform for independent artists in Latin America, has been extended for broader adoption.

Flutter 2.0 has also updated Flutter plug-ins for several core Firebase services such as Authentication, Cloud Functions, Cloud Storage, Cloud Firestore, Cloud Messaging, and Crashlytics. Hence Mobile Ads and Plug-ins will be a new exclusive release that everyone will be looking forward to.

How Is Dart Boosting Flutter 2.0?

Like before, the new Flutter developer tool is powered by Dart. The most significant advantage of Flutter 2.0 is the portability of the app to different platforms. This easy transition to platforms is possible only through Dart. With its unique features, Dart helps to bring in multiple advantages for building apps such as:

Easy portability with efficient compilers for high-performance Intel and ARM machine code for mobile and desktop.
Optimised JavaScript output for web applications.
Iterative development with hot reload on desktop and mobile
Enabled asynchronous and concurrent patterns with modern UI programming.
Top-notch performance across all of the mentioned platforms
Sound - null safety guaranteeing at runtime and development stage.

The advantages mentioned above make Dart one of the fastest-growing languages on GitHub. Flutter 2.0 supports sound null safety that is a significant addition to the Dart language, further strengthening the type system by distinguishing nullable types from non-nullable types. It has the potential to eradicate null reference exceptions that can only contain null values if the developer expressly chooses.

This feature allows the developers to avoid any null error crashes of the apps during development. By integrating the null checks many errors can be traced in the type system during app building. The developer can incrementally add it to the code at their pace with available migration tools.

The Importance Of Flutter 2.0

The current state of the Flutter is quite significant in the market. There have been many successful examples of Flutter that highlight Flutter’s commitment to app development. A few of the many popular apps built using the Flutter framework are Alibaba, Reflectly, Hamilton Musical, Hookle, Watemaniac, etc.

Flutter is built on top of Google’s Android support library and is available for all central operating systems and browsers. The open-source community of Flutter brings in more diversity and added features for the developers.

There are more than 150,000 Flutter apps on the Play Store alone, and these apps get a free upgrade with Flutter 2 as they can simply port their ready code to desktop and web without a rewrite. Google is building apps with Dart and Flutter, such as Stadia, Google One, and the Google Nest Hub.

Google Pay also switched to Flutter for its extensive list of benefits along with productivity and quality. By unifying the codebase, the Google Pay team removed many feature disparities between platforms by eliminating over half a million lines of code. Flutter provided a uniform best-in-class development experience to the team with the Just-in-Time compiler with hot reload.

While Flutter is available on a free tier, it has partnered with many industry leaders to offer an excellent development framework by increasing portability. There are more than 15,000 packages for Flutter in the market from giant companies like Amazon, Adobe, Microsoft, eBay, Square, Alibaba, etc. These companies access key packages like Sentry, Lottie, and SVG, and Flutter Favorite packages such as google_fonts, sign_in_with_apple, SQLite, and geolocator.

Summing up

We have tried to give you a glimpse into a few prominent features of Flutter 2.0 in this article. We hope now you have a brief idea of all the significant changes in Flutter 2.0. This framework is tremendously efficient and flexible, so it may be time for you to know more about using it in your projects.

If you have other valuable resources to add, then feel free to do so in the comment section below.

Flutter for Web: An Ultimate Guide

Karan Shah — Thu, 27 Aug 2020 13:04:19 +0000

Flutter is Google's UI library that was initially launched to develop native, performant, and beautiful mobile applications. However, the vision behind Flutter isn't restricted to just mobile apps, it's to build user interfaces for any and every screen.

If you go to flutter.dev, you will see the following:

Flutter is actively working towards extending the same codebase towards anything with a screen: Android, iOS, Web, and Desktop seamlessly.

With some extra effort - you can essentially use the same codebase to create apps for responsive web (competing with SPA frameworks such as React, Angular, and Vue) and for the Desktop (competing with Electron and Qt) and hopefully embedded devices and more in future.

Creating multiple applications (called targets in Flutter) from a single codebase isn't a simple feat. React Native too promised the world with it's "Write Once, Run Anywhere" tagline but as developers would attest, this is far from reality.

FYI: Flutter for Web is still in Beta, though merged into the main Flutter codebase.

How is Flutter for Web different?

To understand this, first, you need to understand how Flutter works for Mobile Apps and how it is unique. Mobile apps are a visual interface that interacts with a backend via APIs, similarly, Flutter Web and Desktop are applications that communicate with a backend via APIs (thus server-side rendering with Flutter isn't possible).

Flutter (Mobile) uses its own rendering engine called Skia - this gives the SDK complete control over every pixel of the screen and it does this with accuracy and performance.

Furthermore, Flutter has its own widgets (which you can find on pub.dev) built completely with Dart - enabling the framework to deliver high performing native apps.

The rendering engine, Skia, that Flutter uses for mobile was built originally for Chrome.

Flutter for Web Architecture

Flutter does something similar for the Web, it uses the entire screen as a canvas and creates its own HTML elements thus giving it complete control over every pixel. This is rendered with standard-based web technologies i.e. HTML/CSS and Javascript. Thus, you can actually use all of the features of Flutter including animations, routing, etc without the need for separate code.

Flutter for Web has two different rendering engines that developers can choose from, namely:

DomCanvas
CanvasKit

DomCavas is essentially an HTML DOM-based model that combines HTML/CSS/JS and the Canvas API to build, layout, and paint Flutter widgets on the web. Flutter for Web, which started with this strategy, as of now uses DomCanvas by default.

CanvasKit, by Skia, in contrast, uses WebAssembly and WebGL, which enables the browser to take advantage of hardware acceleration. This improves the ability to render complex and intensive graphics efficiently. CanvasKit is still being worked on, so be wary of using it in production.

While CanvasKit seems to be the right place to go, there is one major drawback - its initial payload which can go upwards of 8MB before the user can even see the application. Unless users are aware of this beforehand - most won't stick around to wait for the app to load.

How is the performance for Flutter for Web?

At the beginning of 2019, Flutter for Web was originally in a separate repo of its own. This repo merged into the official flutter branch on Sept 10, 2019, with the launch of Flutter v1.9. The Flutter team is very active and is making rapid progress to boost performance and bring the Web to a stable release. In my opinion, while the current version isn't production-ready yet - I'm hopeful it will happen very soon.

The performance of a web application is measured by primarily two things. The first is the ability to render and manipulate large amounts of data and the second is transitions, effects, and animations.

Dart is able to handle long lists flawlessly and I was able to scroll through 100k records in a breeze. In general, Flutter for Web satisfies the former requirement but pales in comparison to modern JS frameworks in the latter.

As mentioned earlier, there are two rendering engines that developers are free to choose from. Testing with our To-Do application - we found the following:

When built with DomCanvas, the app had a total payload of 1.8MB, out of which main.dart.js was the major contributor of 1.6 MB
When built with Canvaskit, the app had an initial total payload of 8.1MB! a whopping 450% more than the default. The main.dart.js actually shrank a little to 1.5MB but the new web assembly file, canvaskit.wasm called from canvaskit.js took up more than 6MB of space.

This additional bulk size for Canvaskit enhances its performance by leaps and bounds. Now, it's up to you to decide if your users will wait for the additional time to get better user experience.

Comparison of the Two Rendering Engines

All in All, in terms of performance - Flutter has a long way to go to match up to modern JS libraries and frameworks such as ReactJS, Angular, and Vue; but it can prove beneficial in many scenarios.

Unique Arsenal: Adaptive Design

Flutter for Web has a trick up its sleeve that most JS frameworks can't replicate easily. It is the ability to deliver customized versions for the Web depending on the underlying OS - just like it does for Android and iOS.

We tried out our to-do app on a Mac and a Windows machine and depending on the underlying OS, it served up different variants of the same. Feel free to check it out yourself here: https://todo.solutelabs.com/#/

Take for example of a small case below, you will see a different back button and alignment for the header text on a MacOS v/s Windows.

Flutter for Web on Windows v/s MacOS

You could however use the same design across both if you would like to enforce consistency by defining app-level traits on these widgets - but I feel that this could really improve the experience of the user in many ways. Furthermore, there are no payload size savings if you choose to go with a specific style only such as a Material design.

You may wonder as to how this is possible! In reality, the dart components which are adaptive don't require any extra effort at all. Just like how Flutter adapts to the mobile devices, it adapts to the web as well.

You can read about the general platform-specific adaptations here:

https://flutter.dev/docs/resources/platform-adaptations

The above-mentioned adaptations are specific to mobile devices and are automatically enforced by Flutter. In case you want to enforce a particular Style on all three platforms, you will just need to use a different Widget. For example, when you might want to use a Switch component ( i.e. to enable/disable feature) :

Use MaterialSwitch, and it will render the switch in material style on any platform
If you want it to be adaptive, use Switch.adaptive

Hence, adaptations on Flutter for Web can happen in three ways:

Adapting automatically based on the widgets used
Using one variant across all platforms (like the switch example above)
Use app-level trails to define a variant for a specific target

My recommendation is to always go with the first - gives the best user experience and has the least effort involved out of the three.

How do you create responsive layouts for Flutter for Web?

We have seen the power of Adaptive Designs on Flutter, it's time to understand as to how responsive designs are created on Flutter.

While creating a responsive UI, we need to first identify and understand a few product requirements such as:

Do we have a different design for Web & Mobile?
Do we have a common design across web & mobile that scales visually?
At what sizes does the design scale?
Do we have a similar design but need a few components that switch between different sizes?

One would ideally have similar designs (I say similar because things like calendar, back buttons, scroll, etc should be adaptive as explained before) across Mobile and Web but since the web real estate is much larger, one should ideally take advantage of the same.

Flutter provides many widgets that help us with layouts & resizing widgets with respect to device size. When we want a common design that accommodates properly within the available size, such widgets help us do that.

Let's explore some of them:

MediaQuery

MediaQuery helps us identify device size, orientation, edge paddings (In case of devices with Notch), and other useful information at runtime.

Using this information we can make certain decisions regarding widgets layouts.

e.g.

GirdView column numbers.
Switch the component based on available width, like the Header menu in web view that converts into an overflow menu when it cannot accommodate in available width.
Master/details flow based on device orientation

LayoutBuilder

While MediaQuery helps with detecting the overall device size, LayoutBuilder helps us to identify how much space the child widgets will have. It gives BoxConstraints that have information on available minimum and maximum sizes.

There are quite a few more widgets available that also help with other through processes like Aspect ratio based, relative sizing, constrained sizes.

If we want a custom design for Mobile & web or for even granular sizes. We have multiple approaches available to achieve.

If we want to support two layouts, the most simple way would be to define App Level traits

enum UITrait { compact, regular }
mixin UITraitsMixin {
 UITrait deriveWidthTrait(BuildContext context) {
   final width = MediaQuery.of(context).size.width;
   if (width <= 600) {
    return UITrait.compact;
   } else {
    return UITrait.regular;
   }
 }
}

Later while creating any widget, we check the current value of UITrait & render the widget accordingly. Upon resizing the screen widget will be rebuilt & we should be able to see the layout changes.

We can check the live demo here:

https://todo.solutelabs.com/#/home

And the code for the same here:

https://github.com/solutelabs/todo-app

Now, within a particular UI; let's say for a web to support different sizes, we can use a mix & match approach with inbuilt widgets to achieve a more responsive design.

If we want more granular control (rather two designs Web & Mobile), Material has standard guidelines across technologies to create responsive UI, which is called Material breakpoint.

It basically creates more screen breakpoints & helps us to justify UI to satisfy each of those breakpoints.

In order to achieve this in Flutter, there is a package available responsive_framework | Flutter Package.

It has an AutoScale feature, that shrinks and expands your layout proportionally, preserving the exact look of your UI. This eliminates the need to manually adapt layouts to mobile, tablet, and desktop.

It allows both Scaling & Resizing of widgets. Flutter, by default, supports resizing with screen size changes as we saw in the above gif. The primary difference between them would be as below

Resizing - the AppBar's width is double.infinity so it stretches to fill the available width. The Toolbar height is fixed and stays 56dp.
Scaling - the AppBar's width stretches to fill the available width. The height scales proportionally using an aspect ratio automatically calculated from the nearest ResponsiveBreakpoint. As the width increases, the height increases proportionally.

The package also allows configuration to which breakpoint it should scale & when it should resize.

There are a couple of ways responsive design works. One approach could be to have different designs for different device types, that may use common or different components based on the device - or there could be the common design that scales on proportionally on the different sized devices.

Although, as we saw earlier, Flutter provides in-built widgets to deal with such problems. We can control how Widgets should size them as children & also how they should have layouts. We also saw an example of responsive design as well as implementation. Later we saw a package that helps us simulate such a process easily & reduce the common problems of responsiveness.

Embedded Interactive Content

One really interesting way to use Flutter for Web is to integrate a whole/parts of an application within an existing web application. It is possible to load the entire web application or even a particular route of the same within an existing application.

This is possible by inserting the entire Flutter app inside an HTML div. The Flutter app obviously would have to be hosted somewhere. Something simple such as the below would work.

<div>
  <object type="text/html" data="https://todo.solutelabs.com/#/" width="800px" height="600px" style="overflow:auto;border:5px ridge blue"> </object>
</div>

Flutter doesn't add any "X-Frame-Options" inside the application headers so it works out-of-the-box. Having said that, you can conversely stop the loading of your app inside someone else's browser by working with the CDN you use. We use Netlify and Codemagic as CDNs for most of our projects, you can set custom headers on Netlify here - a simple google search for setting custom headers in most cases would suffice.

Not having any X-Frame-Options could be bad for your website as it could lead to clickjacking but you could probably make use of the SAMEORIGIN directive as shown here.

While the app I have has only one public page so it's the one I've loaded - one can possibly load any public page that is configured within the router. This can lead to some interesting use cases, such as:

Add quizzes, challenges, etc into static content such as a blog
Allowing people to play small games which were created for the Mobile
Incorporate public dashboards across Web and Mobile seamlessly

Should you consider going to production with Flutter for Web?

While it might be impractical for someone to build an eCommerce store with Flutter Mobile and then port it to Web (at least in the current state), there are still places wherein Flutter could be a good fit, such as:

You already have a mobile app in a place built entirely in Flutter and want to give your users a web app to operate the same application. Probably a B2B application with lots of data.
You don't have a product yet and are expecting most users to use the mobile app. But, at the same time, you want to give the flexibility of using it on a web device to users who won't abandon your product if they find issues with the web app.
You want to create interactive pieces of content that are already available on the mobile end and don't want to spend time developing the same thing on the web (for which SEO isn't important). For example, a personal finance app's dashboard could be made available on the Web assuming all the entries are essentially done through the mobile app.

There are almost no known names that have their web applications powered entirely by Flutter for Web. All I could find were some portfolio sites and some small ones such as:

Flutter builds everything into one object - one Android Activity, a single iOS View, or in case of Web - a single HTML element. Because of this, you can't play around with the HTML/DOM freely. So if you're looking to add a web developer to your team to add a few scripts or make a few tweaks on top of what Flutter has built - you're out of luck!

Everything in Flutter for Web has to be made from pure Dart functions or if you're integrating third-party SDKs, you will have to create your own widget for web also known as Federated Plugins.

Flutter for Web has its share of pros and cons at the moment and I'm hoping that the team at Google is working furiously to overcome them. I've listed down a list that will help you make that decision.

FYI: If you can't make that decision for yourself, you can always reach out to us :)

GatsbyJS vs NextJS — Which one to choose when?

Karan Shah — Mon, 27 Jul 2020 07:53:05 +0000

“Gatsby.JS vs Next.JS — what would you prefer if I give you a choice?”

I ask such questions to our web developers as they use the frameworks and libraries everyday to code everything from simple to complex functionalities. But, I asked this question recently because of some recent developments. Before I move on this comparison between GatsbyJS and NextJS, let’s find out when they come into the picture.

There has never been a better time in history to build a website. If you prefer to use a simple drag and drop interface, there are websites like wix.com and Godaddy that help you build one in a matter of minutes.

If you are building a bit sophisticated website, one that handles user data and has a few pieces of custom-built content, you must be familiar with frameworks such as WordPress. With speed becoming an important parameter to ranking, newer websites built as Server Side Rendering with Static Site Generation have become commonplace. Technologies like Next.JS, Gatsby.JS, Jekyll, Hugo among others are used to power such sites.

While Gatsby.JS and Next.JS are at the forefront of these technologies, developers have debated online about their preferred framework. The choice has been relatively simple — Gatsby.JS if you are building a static website where the content doesn’t change too often, and Next.JS if it is a complicated site that interacts with a server a lot.

But there have been recent developments that have tipped the scales in favor of one of these frameworks, leaving developers confused as to which one to choose. What are these developments, and which framework should you choose to build your website? Read on to find out.

What is GatsbyJS?

Before I dive into the argument of Next.JS v Gatsby.JS, I shall take a brief look at what exactly is GatsbyJS.

Gatsby combines the best part of React, GraphQL, and react-router to give you a static site generator that is very developer-friendly. Gatsby produces static HTML files that will load directly from a CDN. Too fast? Okay, I will slow it down.

Gatsby.JS is used to build a website that generates static HTML beforehand which can be stored around the world on CDNs for faster access. It does not use a server or a Database on queries such as loading your blog.

Image Source

More than a static site generator, I like to call Gatsby a modern front-end framework that provides incredibly fast page-loads using a bunch of features such as asset optimization, server-side rendering, data prefetching, code splitting, among others.

Now that you know what Gatsby is let's see how its rival, Next.JS, measures up.

What is Next.JS?

Next.JS is a tool used to build server-side rendered websites that generate the HTML dynamically every time a new request comes to it, using a server. Next.js is perfect for building what are called dynamic websites. i.e., websites that are rendered server-side.

Next is used to build websites that interact a lot with the server, using features like Hot Code Reloading, Single File components, Automatic Code Splitting, etc. to help you build beautiful React websites.

Image Source

Both Next.Js and Gatsby.Js are React Frameworks that have been around for quite some time now, and each of them has their own strengths and weaknesses.

Let's take a look at some of the things that are common in these frameworks.

Similarities between Gatsby.Js and Next.Js

Developer experience: Both Gatsby and Next come with extensive documentation that helps in developing features over an existing app. You don't have to learn everything from scratch, and a basic understanding of React is the only prerequisite that both the frameworks have.
Powerful websites: Both Gatsby and Next are used to build high-performance websites with very good Lighthouse scores, if well-built, of course. The websites are SEO friendly since both deliver pre-rendered HTML.
Cool Features: Hot Reloading is a feature that most developers love, and both Gatsby and Next come with Hot Reloading out-of-the-box. The other cool inbuilt features include Code Splitting, Prefetching, Routing, and Caching.

But the similarities end here. Both the frameworks are used for fundamentally different purposes, and we will take a look at when to use Gatsby and when to use Next.

Gatsby.JS - Master of Static websites:

While I have talked about what Gatsby is and some of the few similarities between Gatsby and Next, in this section, I will show you a particular area where Gatsby shines - Static websites.

A static website consists of a series of separate HTML pages, each page representing a physical webpage. Remember the old websites that did not have a lot of clickable elements? Those are static websites.

Different users visiting a static website will see the same content, and updates are not visible in real-time. A personal blog is a good example of a static website.

Image Credit

Since the number of pages is predictable and the content doesn't change, Gatsby is perfect for building these websites. Gatsby offers support from a variety of CMS systems, REST APIs, databases, and GraphQL.

A key difference between Gatsby and Next is the way they handle data. Gatsby separates the data and the website, meaning that members of your team other than developers can also edit data on the web page, which can then be compiled as the site during the runtime.

Connecting to a CMS via a plugin and the ability to update data without programming knowledge means Gatsby is the preferred framework for creating static websites. But things are slowly changing.

Next.Js- Used to build large, multi-user Websites.

If you are building a website with multiple users creating user accounts and then commenting on the content on the page, then Next.JS would be an ideal choice for you.

These websites have multiple users joining in at any instant, making it impossible to build a static website during runtime. The building time taken by Gatsby makes it a bad choice to build such websites.

With websites like this, you need to show unique, dynamic content to logged-in users. Server-Side rendering will help cater to different users based on authentication, and each user can see their content as soon as they create it on the website.

So on the surface, it looks like a simple choice - Gatsby for static web pages, which are simpler to build, and Next for large, multi-user websites. But like I mentioned at the beginning of this article, one of these platforms has the edge over the other one. Wondering which one?

Read on.

Next.JS - Catching up on the Static Site generation train.

NextJS 9.3 was released four months ago, and it now comes with Static Site Generation (SSG) support, meaning new data fetching methods.

These build time methods are called getStaticPaths and getStaticProps, and users can use them to build static websites, just like they would using Gatsby.

getStaticPaths - Used to generate a list of ids that the static website supports.

getStaticProps - Used to fetch data generated based on the ids.

Using this information, Next.JS will generate a page for each of these blog post ids, passing the data fetched from the external services down to the component.

Ticketmaster.com is an e-commerce website built using the Next.JS platform.

Since it combines the best of both static site generation and server-side rendering, Next.JS can be used to build the perfect e-commerce website. You can keep some parts of the website static, like your contact page or shipping information, and use the server to render pages containing dynamic content, like the product page.

Building Hybrid web apps - Next vs. Gatsby

If you are looking to build a hybrid web app where you need both - rendering the page UI using SSR and handling data to the CSR, Next.JS trumps over Gatsby.

Image Credit

Inside a single web application, you have both SSR for visitors and CSR for users who are logged in, and this type of app is best built using Next. Most of the pages today need to be optimized for Search Engines, and since the content is usually dynamic in these kinds of pages, Next.Js is the better option.

Not everything is available on Next.

Throughout this article, I have shown you the kind of framework that you need to choose based on your needs, and have leaned towards Next since it can handle both static websites and dynamic content.

But there are a few things users need to keep in mind before choosing Next.

Data security: With Gatsby, only the required data is taken from the source, which makes it more secure. Although one might argue that with Next, you have CMS's and API's that have private features, data is still present in the server, leaving open a chance for exploitation.
Infrastructure: With Next.JS, you need to invest in setting up servers with databases, maintenance, etc. Whereas with Gatsby, you can pre-render them on a build and use a CDN to create superfast websites.
Gatsby images: A neat Gatsby plugin, called gatsby-image, resizes your images at build time, meaning smaller screen devices like smartphones no longer have to download desktop-sized images. As a bonus, it lazy loads images meaning a further increase in web speed. This is not available with Next.JS.

Websites built using Gatsby.JS and Next. JS

Here is a small image showcasing major websites using Gatsby and Next.JS frameworks to build their websites.

I hope by now you get a brief idea about which React framework to use to build your website. If you have any further React questions or need help with building your website using React, feel free to get in touch with us.

Ten Virtual Conferences to attend in 2020

Karan Shah — Wed, 27 May 2020 07:09:06 +0000

2020 began with the promise of an excellent beginning for the decade ahead. But no one could have predicted that five months into the year, we would all be sitting in our homes, afraid of a deadly pandemic that is spreading across the globe.

While there were a lot of conferences scheduled for the year, the coronavirus episode means that most of them have been canceled. Thanks to the advancement in technology and better internet penetration, we have a lot of these conferences moving online.

Here is a list of ten virtual conferences you can attend in 2020.

1. DevSecCon24

DevSecCon 24 will combine DevOps and Security in a 24-hour virtual event that is hosted and also presided by practitioners. The USP of this event will be the talks around DevSecOps — the process of building security into the development process. Get the lowdown from the top industry experts and learn in a virtual environment how Security and Dev Ops go hand in hand in making continuously secure development a norm.

There is also a virtual expo where you get the chance to meet and interact with the sponsors, watch videos, and ask questions.

You will get the chance to understand how security can be implemented in the overall development process - ranging from customers to supply chain.

Website - https://www.devseccon.com/devseccon24-2020/
When: 15- 16 June 2020
Entry fee - Free

2. OpenDev -

This 3-day summit is an ideal place to meet and interact with the developers, users, and supporters of the open-source software. The virtual event this year is separated into three distinct categories - Large scale use of open infrastructure, Hardware Automation, and Containers in Production. Each day will deal with one of these topics.

Large Scale use of open infrastructure: This day will give a platform for users to share architecture and case studies, and work with developers to implement their open-source requirements directly. The event will deal with the challenges that you have to overcome when you have to deal with operating open infrastructure at scale.

The topics include centralized computing vs. distributed computing for NFV, scaling user stories, upgrades, etc.

Automation: During this event, viewers get a ringside view of operators as they discuss hardware limitations for cloud provisioning and challenges faced while networking, among other things.

Topics include networking, end-to-end hardware provisioning lifecycle for bare metal, and provide provision for cloud-based workloads by consuming bare metal infrastructure.

Containers in Production: Organizations today are developing architectures for a range of workloads, whether it is ranging from running containerized applications on bare metal or VMs. Users can use this event to discuss infrastructure requirements to support containers or collaborate directly with developers about their open source requirements.

Topics include security and isolation, bare metals, containers, using Openstack with containers, Telco, and network functions, among others.

Website - https://www.openstack.org/events/opendev-2020/
Dates - June 29 - July 1, July 20–22, August 10–12, 2020
Entry fee - Free

3. UX Writer conference

This virtual conference, brought to you by Welinske and Associates, aims to bring together UX writers from all across the world onto a single platform.

UX writers from different industries, and spread in different geographies, will all share what they know to the attendees in a series of Zoom conferences.

The speakers at this year's UX writer's conference include Torrey Podmajersky, who has written for the likes of Microsoft, and more recently, Google. Also speaking at this session will be Elly Searle, who founded the UX writing teams at CrowdStrike.

Website - https://uxwriterconference.com/
Dates - June 9–10, 2020
Entry Fee - $195

4. React Native Remote Conf 2020

This three-day remote conference is brought to you by the people behind React Native Radio podcast. React Native developers have the opportunity to network with some of the best minds in the business from across the world.

The participants have the luxury to stream any of the events, based on their convenience. On the first day, we have Christopher Chedeau, a Facebook Engineer, talking about the origins of React Native.

The speakers also include Tim Jung, who is an Engineer at Activision Blizzard. The regular speaker sessions will be interspersed with a networking hour, where developers have the chance to speak to other developers from around the world.

Website - https://reactnativeremoteconf.com/
Dates - July 29–31, 2020
Entry Fee - $75 per head

5. Ruby on Rails Railconf 2020

The online version of the popular Railsconf2020, a Ruby on Rails conference, canceled their in-person event scheduled earlier this year. But the organizers of Railsconf have managed to record all their interviews with the keynote speakers and put them online, which you can see on their website, railsconf.com.

Titled Railsconf 2020.2 Couch edition, the website gives access to all the speeches scheduled to happen this year, including the ones by David Heinemeier Hansson of Basecamp and Eileen M. Uchitelle of Github.

There are close to 33 speeches available on the website, enough to cover a couple of days on your calendar. The talks range from "Advanced ActionText" by Chris Oliver and "Wrangle your SQL with Arel" by Eric Hayes.

Website - https://railsconf.com/
Dates - Open
Entry Fee- Free

6. Apple WWDC 2020

Apple's World Wide Developer Conference 2020 is poised to be its most significant, looking to connect 23 million iOS developers in a week in June. The event will open doors for scores of developers from across the world to get early access to some of the new features in iOS, macOS, iPadOS, tvOS and watchOS.

The conference will also give developers an opportunity to interact with Apple engineers, prodding them about the new features they can expect with the next iPhone or iPad.

Apple has a strong and robust developer community, with roughly 23 million registered developers in more than 155 countries, and the WWDC aims to provide them with insights on how to turn their ideas into reality.

Website - https://developer.apple.com/wwdc20/?cid=CDM-DM-P0012725-448038&cp=em-P0012725-448038&sr=em
Dates - June 22, 2020
Entry Fee - Free

7. Stackconf online

Stackconf is a virtual tech conference about open source infrastructure, bridging the gap between development, operations, and testing and looking at it from multiple perspectives. The conference will give participants a look at how IT experts run their applications and how infrastructure in production has a massive influence on how they build their tech stack.

The team behind stackconf have been bringing together experts in the open-source field under one roof since 2009, and are expecting a large turnout this year.

Speakers include big names in the field, such as Aiko Klostermann of Thoughtworks and Ignat Korchagin from Cloudflare, along with 38 other experts over three days.

Website: https://stackconf.eu/
Dates - June 16,17,18 2020
Entry Fee - 99 Euros

8. DrupalCon Global 2020

Users of the popular Drupal Content management software have reason to cheer as Drupal has moved its conference that was scheduled to happen in Minneapolis into a fully virtual conference this year. DrupalCon aims to bring together developers and enthusiasts of Drupal, to share their thoughts and knowledge on open source software and enhanced digital experiences.

The conference also aims to provide networking opportunities to Drupal professionals. This year, DrupalCon will stick to its tradition of opening with Driesnote, where founder Dries Buytaert will chalk out Drupal's roadmap for the coming year.

Driesnote will be followed by presentations from industry experts, followed by a community connect the program to facilitate organic conversations between participants. Ticket holders will also get access to featured speaker content,on-demand event content, and attendee-only content in the content library.

Website - https://events.drupal.org/global2020
Dates - July 14–17, 2020
Entry Fee - $500

9. BrightonRuby 2020

This single-day conference, usually held in Brighton in July and organized by the vivacious Andy Croll, is moving online thanks to the coronavirus. Andy is putting together a group of Ruby experts in a series of video talks, a Podcast, and a book, all scheduled to arrive somewhere around mid-June this year.

The conference this year will be a mixture of Ruby, software engineering, and "me being an idiot," in Andy's own words.

In addition, 2 pounds out of every ticket sold will go to a Shelter, a charity for the homeless in the UK.

Website - https://brightonruby.com/
Dates - Mid June 2020
Entry Fee - 29 pounds

10. Hacking with Swift Live 2020

One of the world's largest Swift conferences will be held online this year in the third week of July 2020. This online iOS event will cover everything ranging from all the developments at WWDC 2020 to the current best practices while coding with Swift.

The conference aims to cover all the new frameworks of Apple, with tonnes of real-world examples and explanations. A hands-on coding challenge will help you sharpen your skills, and workshops will help you to learn the latest developments in Swift programming.

Networking is another key takeaway with this event since you have Swift programmers from all over the world discussing the latest trends in iOS development. To top things up, all the proceeds from the event this year will go to a charity, so you are learning and helping the world become a better place.

Website - https://www.hackingwithswift.com/live
Dates - 13,14, 15,16 July 2020
Entry Fee - 330 Euros for a regular ticket
500 Euros for an Individual sponsor

These are only some of the fantastic conferences happening this year. I might put out another list later this year. If you feel I missed out on something important - do let me know in the comments below!

Why do Developers love Ruby on Rails for Web Development?

Karan Shah — Mon, 18 May 2020 05:28:06 +0000

Ruby on Rails (RoR) for web development gained popularity among a huge chunk of web developers. It has been more than a decade and a half since Ruby made a splash on the web development scene. With its syntactic beauty and readability, ease of developing an MVP, and a robust online community, Ruby has now made strong inroads into the developer community.

Companies like Airbnb, Bloomberg, GitHub, and Crunchbase are all built on the RoR framework. According to this report, 3.3% of all websites we know use Ruby on Rails.

So what makes Ruby on Rails tick? I mean-

Why is Ruby on Rails the preferred choice among web developers?

Having close to half a decade’s experience in developing websites using RoR, we at SoluteLabs asked our own Ruby developers why they prefer the framework. Here are some snippets from our interview.

5 reasons why web developers love Ruby on Rails

1.RoR allows maintaining good quality code — Urmi Soni, Backend Developer- Ruby lover for 1.5 years

I am a relatively young team member here at SoluteLabs, but when talking about Ruby, I can go on for hours.

Ruby is a simple and beautiful language for development because it follows the convention over configuration principle. What this means is that wherever possible, we attempt to remove the need to configure things explicitly, and instead rely on defaults.

This makes adding components very easy. I also wonder how anyone can even think of using anything other than RoR for web development when Ruby supports all the functionalities like rapid development, RESTful app design, and the use of different libraries (gems).

The test automation feature of RoR helps in productive development. Maintaining good quality code is also easy throughout if we use RoR, due to its object-oriented nature.

It is Ruby on Rails for me, any day, anytime.

2.RoR uses MVC Architecture (MVC) — most convenient for web development

By Ekta Jayantilal Solanki- Backend Developer — Ruby supporter since 1.6 years

I have been working on Ruby on Rails ever since I joined SoluteLabs close to 2 years ago. RoR encourages fast development, which means we can write more code in less amount of time.

Since the framework is open-source, the library is huge, and all the knowledge you need is available free online. There is a tonne of tools that will also help in developing faster.

The architecture of RoR is convenient for us developers since it uses the MVC (Model -View- Controller) architecture. This means multiple developers can collaborate on a project and work together. MVC also means it is easier to debug the code since we have multiple levels properly written within the application.

Another big plus point I see with Ruby is that the Ruby code is easier to understand and is self-explanatory. This means that even if you have relatively inexperienced people coming on board, they can easily understand the code and be up and running in no time.

And lastly, Ruby code is easy to maintain, and there is a large community online that will support us in case of issues. RoR also allows scope for test automation, which is one of the biggest advantages.

In a nutshell, Ruby on Rails is a kick-ass framework that any developer will love with.

3.RoR enables rapid web development — Pratha Avashia — Senior Software Engineer — Ruby ninja for four years

I am a relatively older Ruby on Rails developer here at SoluteLabs and can give you a much more holistic view of why we all love the framework.

First and foremost, Ruby on Rails has simple English-like syntax, which makes programming really easy to understand for developers.

Convention over Configuration makes code much more organized. This means the number of decisions the programmer has to make and eliminates complexity.

Being open-source, RoR has a large group of developers and a big community online, which means you get responses to your queries on one of the many online forums.

Another often overseen feature of Rails is that it has a very strong focus on Testing. There are a lot of useful testing frameworks that help deliver quality products.

And lastly, no list of RoR advantages is complete without the mention of Ruby Gems. A gem is a module/ library that you can install and use in any project on your server. Ruby Gems help speed up the development process.

4.RoR enables easy code modification and migration — Krupa Suthar — Software Engineer- On the “Rails” road since 2017

Ruby on Rails is very close to my heart since I started my software engineering career at SoluteLabs with an RoR project.

I have been using Ruby for close to 3 years now and can vouch for the fact that it is one of the easiest frameworks to master.

Many people have said it already, but I am also a big fan of Convention over Configuration, which makes Ruby very organized.

RoR has very rich testing frameworks and in-built gems such as unittest, rsspect, cucumber, which help in pushing out a quality product. In addition to these, we can also create custom gems, which make the lives of developers easier.

Another often stated advantage of RoR that I am repeating is the immense community support you get for the framework. Any question I have, I first go to the online forums which are frequented by some of the expert users of Ruby. I usually get my queries answered in under ten minutes.

A key advantage of Ruby on Rails is that it is easy to modify and migrate code. Migration allows you to define changes in your database schema, making it possible to use a version control system to keep things synchronized.

So ease of use, gems, migration, and a large community. I would say that these are the advantages of RoR off the top of my head, and the primary reason why I use the RoR framework for web development.

5.RoR brings web development costs down — Ajay Babar, Backend Engineer — Ruby Ruby Ruby for three years now

Ask Ajay, a backend engineer at SoluteLabs which his preferred framework is, and he will sing the famous Kaiser Chefs song — Ruby ruby ruby ruby.

I have used Java’s spring boot and Python’s Django framework for backend development, but nothing comes close to the ease and versatility of Ruby on Rails.

All of them use the Model -View- Controller framework (MVC), but what sets Ruby apart, as my friends have already told you is the conventions over configuration paradigm.

The effort and time that this paradigm saves for the developers are immense.
Another area where Ruby on Rails shines is the speedy development process. Rather than writing 5–6 classes to develop one API in other frameworks, with RoR, you can write a single API much faster, which leads to cost savings.

There is also the support of a huge developer community for Rails, which makes troubleshooting easier.

And lastly, Ruby as a language is really readable and easy to understand. That’s why IT giants like Shopify and Basecamp use Ruby on Rails framework.

Do you also love to code in RoR? Send us your reason for using Ruby on Rails for web development in the comments section below. If you get lucky, we might give you a super-shoutout to you on our social media platforms.

BTW, if you missed out on our social media platforms, quickly follow them-
Github, Dribble, LinkedIn, Facebook, Twitter, Instagram, and Pinterest.

Design Sprints - How we use it!

Karan Shah — Tue, 07 Apr 2020 10:18:56 +0000

Design Sprints. Two words that catch any agile developer's imagination. We have heard about sprints, short work-cycles that are the cornerstone of any agile development cycle.

In this article, you will learn:

What is a "Design Sprint"?
How SoluteLabs runs a 5-day Design Sprint

So what is a "Design Sprint"?

Design, prototype, test and validate a product idea in five days! That's right. Five working days.

That's Design Sprint in a sentence for you.

The concept is relatively new, made popular by Jake Knapp and Google Ventures a few years ago. All decisions from sketch to prototype happen in a short span of five days - making it arguably one of the cheapest and fastest ways to validate product ideas or business strategies.

Design sprints encourage collaboration through making. They are an excellent way to bring different teams under the same roof and work towards a common vision.

Design sprints encourage sketching and original thinking, through experimentation. This translates into reduced costs to build a working prototype, which all companies can agree, is a good thing.

Here at Solutelabs, we have our own version of the Design Sprint, which is a 5-day exercise in getting your prototype up and running. Without further ado, let's jump right in!

The Pre Sprint Phase

Even before we jump into the sprint, we at Solutelabs get the most important person involved in the project - the customer. We do this by conducting thorough customer interviews.

We begin the interview by making the customer comfortable, asking a few basic questions about what business problem they are trying to solve. This is before we talk about products or prototypes, just to get the customer settled in.

We encourage the customer to "think out loud" in this phase. Ask all the questions we feel will help us build the prototype better. We take detailed notes in this phase, using post-it notes and our own whiteboards at the office to a great extent.

We also use this stage to decide on the sprint team. This mostly includes designers and developers who we know can afford to block out 5 days on their calendar.

We gather our sprint supplies (post-it notes, whitepaper, drawing board), send out happy thoughts and bam! We are ready for Monday.

Day #1 - Monday: The Mapping Day

Our week begins with what is arguably the most important day of the sprint - Monday. We beat the Monday morning blues by huddling into the director's room, where the whiteboard and the post-it notes are ready for us.

Monday is the brainstorming day, where we first debrief the team about our client and his chief pain points. We use the pointers we gained in the interview during the pre-sprint phase and convert them into actionable points that we jot down on the whiteboard.

Once we align the team with the clients' goals, it is now time to write down the long term goals. These may be the functionalities of the app that may or may not be covered in the prototype, but the customer would want to take a look at anyways.

With the long term goals handy, we create a virtual map of the app from a design point of view and then zoom in to a particular problem that the client wants to solve. This is a simple sketch that shows how the customer is going to move through the app.

With the long term goals set and the map ready, we now move on to asking the experts. In this stage, we talk to expert developers who may or may not be part of the team who have solved similar problems before. This will help us better gauge the time and effort needed to build the prototype.

All through this phase, we will have the sprint team taking notes. Once we have asked the experts their take on the problem, we combine all the notes by posting them on the whiteboard.

The sprint team then sorts the notes into different categories and votes on the ones that they feel will be the most important to solve.

It is now the job of the project manager, usually one of our directors, to choose one specific part of the problem and filter it down using the questions from the interview phase. Once our target is fixed, we call it a day, and our Mapping Monday is done.

Day #2 - Sketch Tuesday

With all the talking and writing of the Monday behind us, we are now ready to begin Tuesday with a new agenda - create flow sketches. This is the stage where we bring in the designer(s), who will help us convert the ideas in the post-it notes into actionable sketches.

This is where we start conducting lightning demos.

What is a lightning demo?

You can think of a lightning demo as a small research session with your team. We give the team a short span of time (typically thirty minutes) to come up with three examples. By the end of the lightning demos, the teams will have three products that we can use as inspiration while building the prototype.

Once the lightning demos are done, we get a series of "inspirations" that the designers and developers can aim towards while building the prototype.

We then encourage the team to walk around the whiteboard, study all the post-it notes from Monday and the sketches from lightning demos. The sprint members jot these ideas down and then try and convert them into tangible ideas that can be built.

For instance, the idea can be a great landing page, like the one Shopify has.

The designer, at this point, creates a solution sketch, which is a good approximation of all the good ideas in a proper sketch format.

Even if some of our teammates are not good at drawing (a couple of developers are horrible at drawing, to be honest), we use Sketch Tuesdays not to create artistic sketches or product approximations, but rather visual representations of our member's thought process.

The Solution sketch is usually one idea that is expanded by each individual team member, where they explain how the app works in three frames, along with a catchy title that will help the teammates remember it.

And that's it! We are done with Sketch Tuesday.

Day #3 - Storyboard Wednesday

Mapping Mondays and Sketch Tuesdays lead us to the next part of our 5-day Design Sprint - Storyboard Wednesdays. Here, everybody gets to review the sketches made on Tuesday in silence.

These sketches include the crude ones made by the developers as well as the perfect solution sketches created by the designers.

Once all the sketches have been reviewed, the team members note down the components they feel will suit them best when building the prototype. The project manager then decides which ideas will actually go into the prototype and which ones will be saved for later.

Sometimes, our teammates come up with so many great ideas that there are two to three really good ideas that we want to prototype. In this case, we decide on building all these prototypes, instead of just one prototype for the customer.

Now the ideas are ready to go on to the storyboard. So we physically take down the best ideas from the wall, which maybe the solution sketch or the crude sketches, and pin them on to the storyboard so that we know what we are going to build.

And that pretty much wraps up Storyboard Wednesdays.

Day #4 - Prototyping Thursdays

Okay so by now we have freezed the ideas that we are going to work with, sketched them and put them up on the whiteboard.

On Thursdays, we usually get down and dirty by building the actual prototype, writing code, and making web elements to convert the idea on the storyboard into reality.

The process usually begins with the designer, who has taken up the duty of converting crude sketches into workable wireframes. The designer hands over the wireframes to the development team.

The objective of the developers is to build a realistic facade, something that the customers can look at and give feedback. We begin this by picking the right tools, which may include design tools like Photoshop or sketch and development tools such as Visual Studio.

Now the prototype may be too much to handle for one developer, so we divide the task into manageable chunks and assign each part of the prototype to a developer.

Once all the individual elements have been built, the project manager takes them all together to form a complete prototype. It is now time for the trial run. All of us huddle around the director as he tests the prototype to see if we have covered all the functionalities.

If we are happy with the working prototype, we then bring in the customer to give him a working demo. There are usually questions from the customer at this stage, along with important feedback. We take down all the feedback into notes and then get back to rebuilding the prototype accordingly.

And voila! We are done with prototype Thursdays!

Day #5 - Interview Fridays

We now come at the fifth and final day of our Design Sprint, after a hectic week of brainstorming, sketching, making wireframes, playing rock-paper-scissors to choose ideas, and finally, building the prototype.

On Friday, we pick up where we left off on Thursday, beginning again with the client interviews. By this stage, we have a good working prototype ready, and we will explain the features that we have built, in detail to the client.

As the interview progresses, our entire team takes notes, jotting down important feedback that they feel can be incorporated into the prototype. Client feedback is probably the most important part of the Sprint, with the best ideas originating there.

We compare the client feedback to the moodboards we created on Monday to see if all the features have been included in the prototype. In case we missed something, we quickly go back to the developers who are always ready to build new things.

This is one of the pit stops of our Design Sprint coming to an end since there is always a scope for improvement. As we gather client's feedback, we also develop screens in parallel, adding features that the client deems necessary.

The Design Sprint at Solutelabs is thus on an evolutionary path, and we are always happy to improve our process by bringing in new ideas.

Feel that you can improve our process? Write to us in the comments box below and we will incorporate it into our Design Sprint.

And, if you want to run a Design Sprint for your product, we're one message away.

Testing in an Agile World

Karan Shah — Tue, 21 Jan 2020 09:37:09 +0000

We have been testing our code ever since we've written it. It's an age-old paradigm to check the quality of software. As tools advance to enable us to ship products faster and better, our expectations rise too. In the world of agile development, we tend to focus more on the number of features that we can create (a.k.a. velocity) than an occasional bug.

A code's quality (something highly subjective, in my opinion) can't alone be determined by the number of bugs present - it depends on several other factors too. Technical Debt (bad code), if left unchecked, can have very disastrous consequences in the long run. But for this article, we'll stick with testing.

While there are many ways of testing code, I will discuss the ones that are prevalent in today's era, which are:

TLD - Test Last Development (a.k.a. Manual Testing): test after the code is written manually (Tested by a QA, not the developer)
Automated Testing - Write Automated Tests that can be executed against the code (not by the developer)
TDD - Test Driven Development, write test cases before code is written (the developer writes both)

Initially, most of the software would be created with waterfall models, i.e., your requirements would be gathered, analyzed, and frozen. The project would be divided up into milestones, and any change to the input requirements would need (usually expensive) change requests. This enabled managers to manage the work better; they would dice and slice the work and distribute it within the team.

But as we know, bugs have been around since the day software was written. Thus came into existence:

Manual Testing

As to how most code is still tested today, manual QA (Quality Analyst) plays a vital role in today's era and will continue to do so. There isn't any way that we can completely do away with it.

This form of testing (also known as traditional testing) is done by a different set of eyes than the one who wrote the code. This allows for a different perspective since we all know how good developers are at finding their bugs. Checking stuff manually is more important in frontend aspects of a project such as Web or Mobile to make sure it works correctly on different browsers and mobile devices.

Because developers in such processes were not made an integral part of the planning process, somewhere they did not take full responsibility for the code that they would write.

While this wasn't a significant overhead at first, as software grew more complicated - so did time involved in testing. This called out for ways to automate the process of testing. There, I think, people saw two ways out: Automation Testing and Test-Driven Development (TDD).

Automation Testing

When QAs got more efficient with using tools to track and monitor issues, they still had to do a lot of regression testing (testing everything) whenever there was a significant deployment or feature release.

This led to a lot of time inefficiency, and a feeling of not doing productive work (because of its redundancy). Thus testers started writing code to automate the tests they would typically do manually - and they still do.

But along came Agile, which changed the way people shipped code. Today, everyone seeks to go agile because they want to release products faster than ever before. This led to savings in terms of time and, therefore, costs.

Test Driven Development

TDD is a way of development in which developers write automated tests before they set out to write the code for the same. You could summarize the same in the following steps:

Understand Requirements/Stories and write Test Cases
Run the test cases (also called as a Test Suite) and watch them fail (The test must fail since it shows that scenario isn't dealt with)
Write code to make the test case pass
Re-run the test suite and make sure (read hope) that all the test cases pass
Refactor your code to remove redundant code

With TDD, the responsibility shifted back to the developer to make sure that the code performed as expected. The QA's responsibility shifted from just testing the product to helping write more test cases which the developer would have to work on

Ideally, with TDD, the role of the QA was made redundant, but an important thing was left out - perspective. Because people find it difficult to find holes in their software, we needed a second set of eyes to make sure everything was working smoothly.

Another consequence of writing TDD code was that the code had to be loosely couped for it to be tested throughly. This forced the developer to write code that was better separated - not from a habit, but compulsion.

Therefore, in Agile, a balance was stricken - while developers continued to write code in TDD - it didn't eliminate manual QA, it reduced dependency on it. At SoluteLabs, we follow the same - TDD with manual QA.

There are many other areas where testing can be done and is needed. Still, for most parts, while developing products for startups and enterprises, our focus has always been to ship as fast as possible with the highest standards in code quality.

Our experience with BDD is that it takes too much time, and with requirements changing often, it's not worth the investment.

Will Native Development be dead for good in 2020?

Karan Shah — Tue, 31 Dec 2019 12:05:15 +0000

With the advent of cross-platform toolings such as React Native and Flutter, does it make sense for companies to invest in multiple native apps on iOS and Android?

That's the reason why such questions have arisen-

"Will native apps die?

"Is native app development a dead-end career path?"

"Is native app development dying?"

And, more.

Well, we've got answers to all such questions.

In the mobile development space, there are many going all out with Flutter and React Native. Most of them claim that it could save up to 30–35% of your time (and thus costs) by working with Flutter or React Native. Let's analyze as to how much of this is really true, and does this apply to you?

TL; DR

It probably won't die - but will face fierce competition.

Long Version

We have developed more than 100 mobile apps in the past five years, many of which have gone viral, got funded, and ranked in top #10 lists. We started developing apps in 2010 with Objective-C in iOS and Java with Android and transitioned to Swift and, in recent years, to Kotlin.

We were satisfied with the tooling and didn't pick up Hybrid Apps (built on Cordova or any Web layer) as they reduced the User Experience to a great extent. We had started using AngularJS (1.x) in 2015 much before v1.0 was launched and then came along React - as it matured, we embraced it and are using it to power most of our frontend systems, including our website (built on GatsbyJS).

With React already being used in our production systems and clients wanting us to work in React Native, we decided to give it a go. While we were working on RN, in Dec 2018 - Flutter was launched!

The approach that flutter took was different from React Native, and it held a strong premise of overcoming the pitfalls that React Native (and other Cross-Platform apps had in general). Thus, I guess it's time to debunk some myths and establish some facts around mobile app development.

Myth #1: Your code can be 100% in React Native/Flutter

This is wishful thinking. Just like how humans are social animals, mobile apps these days can't be an island. Depending upon the product features, one will need to interface with a lot of third-party solutions to integrate within the apps - more so for cross-platform apps than native.

There are different libraries for error tracking, performance monitoring to very specialized tasks such as video conferencing, and chat tools. Most of these libraries provide first-class support for Native libraries, and then, if they deem essential - create wrappers for cross platforms.

Due to the very nature of how features are created and support is rolled out, cross-platforms continue to be second class citizens. Thus, if you're working on a cross-platform app, you will need to integrate with third-party SDKs. In doing so, you will need to write native code to interface with iOS and Android.

Depending upon your approach, you will have to choose between writing parts of your applications in native code or in Flutter/React - at times, causing more pain than ease.

Myth #2: Flutter is here to stay, now and forever

Huge corporations such as Google will never have a single strategy, and it has a history of knocking down projects (some even successful by many standards) if it doesn't live up to their expectations. Also, frontend libraries and frameworks are notorious for having a short life cycle.

In early 2016, Microsoft acquired Xamarin for $500–600 Million - and in my opinion, it wasn't a wise move (we can all be Warren Buffets in hindsight 😉). Microsoft dropped Xamarin like a hot potato in recent years and has instead moved its focus on Machine Learning.

Google's beloved AngularJS, once considered revolutionary came into existence, got a lot of fanfare, adoption, and then criticism all within a span of a few years.

Google is simultaneously also backing Kotlin, a language created by Jetbrains. Kotlin can create not only cross-platform native apps (like Flutter) but also can work on Web (Flutter supports it too) and backend systems too. A true promise of writing with one language on all platforms.

Considering the above, I would advise that if you're in a business wherein, you have a very long and extensive product roadmap, you should ideally choose something that will stand the test of time. But if you're a startup that can move fast, iterate, fail, and re-invent - I would suggest going with a framework that can save your time (and costs) - at least in the short run.

Myth #3: You will always save costs upwards of 30% while working with Flutter/RN

Yes, there are cost and time savings when it comes to working with cross-platform apps - not just in development, but also in QA and Project Management. But these benefits are assuming that you don't rely on too many third-party frameworks that have little to no support for your SDKs.

For example, because Google is promoting Flutter, Firebase as a native SDK, but giants such as Twilio and Stripe are yet to come out with official SDKs for Flutter.

There are some animation effects, gradients, and such which are not available in React Native despite it being in existence for a long time.

So sometimes getting these to work with your apps can be a pain but if you're looking to build apps that aren't heavily dependent on these services or if these SDKs form a minor portion of the app then yes, you will still save money working with Flutter/RN

Myth #4: My Flutter/RN team need not know any native development

O how I wish this were true! It would be foolhardy to take a beginner, not knowing any native development to work directly on Flutter/RN. If you're starting mobile development, learn Kotlin/Swift first - get a firm grip and then move on to Flutter/RN. (also to know RN, you will first need to get acquainted with React - not a short learning curve, eh!)

Again, depending on your application, you could do away with this requirement, but if you need support - you will have to get your hands dirty in native code or get help from other native developers on your team (if you're lucky to have some!)

And now, time for some facts!

Fact #1: Your Flutter app will be as performant as a native app

Flutter was built for performance, and our recent experience in building flutter apps has been a resounding success. We recently launched a Flutter app for the fifth-largest marine player in the world!

The only downside you can see upfront is the size of the apps developed in Flutter. They are usually 30MB+ (though it's not a deal-breaker for most considering increased bandwidth and internet penetration around the globe)

Fact #2: You will be able to ship apps faster

While it might look to a developer at a macro level that he's spending more time than needed sometimes while working with React Native/Flutter as opposed to native development - they do save time overall.

With Flutter, you're able to ship apps quicker, which means you can pack in more features in every sprint, so everyone's usually happy! :)

Fact #3: You can add Flutter to existing apps!

With the launch of v1.12 of Flutter, the "add to app" functionality has finally gone mainstream. Even within Solutelabs (and I'm sure other products too) - we have started pitching to clients about creating new features in Flutter.

Adding Flutter to existing apps would mean that your native development team would have to reskill themselves in Flutter. This could be a deterrent factor for some teams and might not be for some.

Conclusion

If you already have a native iOS or Android app and don't need many external SDKs, try adding flutter to the mix, it's easy to learn, and there are some excellent tutorials on Flutter out there!

And if you're starting from scratch, have a look at your app and see if it's heavily dependent on SDKs that don't have a Flutter/RN SDK. If not, and if you're starting - go for Flutter.

If you're already investing in RN or have invested a considerable amount in time, costs, and building a team on native development - stay on course!

7 Steps You Need To Ensure a Successful Product

Karan Shah — Fri, 27 Dec 2019 11:44:17 +0000

More than 90% of startups fail within the first 5 years

I know this might not be the best way to start a blog - but it's essential to understand that a lot of other factors go into making a successful product, and while some of those factors are in our hands, some are not. Things like location, luck, the timing of the product, etc. all play a role. But for the things that are in your control, you must exploit them to the fullest to increase your chances for success.

It's important to keep in mind that, as a founder (especially a startup), you can't just throw money at a problem and expect your business to succeed

Diligent and Disciplined

These do all of their homework, create an NDA, work on Mind Maps to Mock-ups. These people are also very meticulous about the work they do and usually have more experience in the industry they want to launch their startup.

Dreamy and Idealist

These founders usually come to us with just an idea in mind, most of them not even bothering to pen it down in a document. I believe this severely also limits their ability to talk to more vendors and effectively utilize their time.

Whatever the type, it always feels like a breath of fresh air when I hear founders talk about their ideas/products with such enthusiasm. It's one thing to talk about your idea - it's another to think through the details.

Whether you're a Startup Founder or an Enterprise Manager, I would suggest doing the following steps in mind before you approach an app development agency like ours.

Develop domain knowledge
Brainstorm your idea with Friends and Family
Perform Competitor Analysis
Create a Mind Map
Try creating a user journey and mock-ups
Gather feedback from potential users
Document Everything

While it might not be possible for every founder to hit all of the stuff mentioned above, it is imperative to hit at least 4–5 to increase your chances of building a successful product.

Let's dig deeper into each of them and see how it can affect everything: right from time and therefore costs involved, which could ultimately be a deciding factor for your startup.

1. Develop Domain Knowledge

Unless one hasn't experienced the pains of an end-user oneself, it's challenging to build an experience that will impress your end customer. It's like I can't even have a small ice cream truck if I've not eaten ice cream myself.
Things like:

Which flavors to choose?
What time of the day should I go?
What would the days of the week be slack? and so on

While you can learn all of these from experience, the same is not valid for product development. Changing features, going from one post to another, will cost you time and money, both of which are always in scarcity.

Sometimes, the task at hand might seem simple, but when you set out to build a successful product, you come across many junctions wherein you wouldn't know which path to take.

HACK: Get a Co-Founder on board who has the necessary domain knowledge. You can't hire your way out of this!

2. Brainstorm your Idea with Friends and Family

While founders themselves are usually very fond of their ideas, seldom can they take criticism from others, especially strangers. But when an idea is in its infancy, it's vital to talk to your near and dear ones so that they can provide the much needed valuable feedback.

Minor tweaks and small ideas often change the course of how entire startups are made or grow.

While in a way, founders need to be eternal optimists about their idea else, no-one else will including their team - at times, it's important to be pragmatic too.

3. Perform Competitor Analysis

Creating a product or a startup doesn't mean that you have to come up with an idea that is totally unique which hasn't been thought of ever. You can always learn from existing players, do better, expand in other geographies or domains and succeed.

Apple wasn't the first company to come up with a smartphone and we aren't the first agency as well 😁. While there is a first-mover advantage in some cases, remember that:

Execution is key

So assuming that you do have competitors or there are products which don't directly compete - learn from their mistakes and improve upon them. To learn more about this, you can head over to - Why Mobile App Development needs Rigorous Competitor Analysis.

4. Create a Mind Map

For the uninitiated, a Mind Map is a visual representation of your thoughts, ideas, and information. While mind maps can be created with tools, you can also create them on paper and iterate from there. I use a tool called XMind, give it a try!

Mind maps allow you to view the information that is scattered in your mind visually. By creating and iterating on the mind map, you become more focused on the flow of the app, the different use cases, and become more clear on the app in general.

Pro Tip: You can create mind maps for lots of different things, too, such as if you're a teacher, you can use it to design your curriculum, etc.

5. Try creating user journeys and mock-ups

After you're done brainstorming your idea and building your mind map, it's now time to bring your idea to life. Whether it's a mobile or a web app, try visualizing the flow of a user and put it on a piece of paper - This doesn't need to be perfect but try to be as detailed as possible.

You're not expected to create the final UI/UX of the application, but just like brainstorming and mind-mapping, this will allow you to get further clarity in how you want your customers to interact with your product. It may look intimidating at first, but it's a vital and essential step!

Pro Tip: If you are a little more tech-savvy, you can checkout wireframing tools like Balsamiq

6. Gather feedback from potential users

Hold on to your horses! Before you jump the gun, save some more time and effort by taking interviews and feedback on the wireframes you've created in the previous step.

You can either find real users scouting on forums like Reddit, Quora, or networking places like LinkedIn, AngelList, or even Facebook. Join groups, network with people, be mindful of their time, and maybe offer something in return - could be monetary like a $20 Amazon voucher for an hour of their time or maybe do something in return, be creative!

7. Document Everything

To ensure that you can reach out to better (and more) agencies, you must collate all of the information in one space. It's the final step before you proceed to decide which agency could be a perfect fit for you.

This banal step is crucial in getting your thoughts, ideas, and all the days of effort into one document. The document(s) will form the backbone of your app, and while it will keep evolving - it will serve as a reminder of what you set out to build. Maybe you can compare how far the app has come six months or a year after the development starts and see how similar (or different) the product has become from the original vision!

As I mentioned earlier, don't fret if you don't get all of these, but even if you hit four out of the above six steps, you should be good to go!

At SoluteLabs, we try to become real partners and help startup owners forge their path as we seek to impact lives daily. Get in touch if you want to know more!

Originally published on blog.solutelabs.com

Client-side Vs. Server-side Rendering: What to choose when?

Karan Shah — Tue, 17 Dec 2019 07:20:38 +0000

The web page rendering dilemma

The discussion about a web page rendering has come to light only in recent years. Earlier, the websites and web applications had a common strategy to follow. They prepared the HTML content to be sent to the browsers at the server-side; this content was then rendered as an HTML with CSS based styling on the browser.

With the advent of JavaScript frameworks, came in a completely different approach to web development. JavaScript frameworks brought in the possibility of shedding burden off the server.

With the power of JavaScript frameworks, it became possible to render dynamic content right from the browser by requesting just for the content that is required. The server, in this scenario, only served with the base HTML wrapper that was necessary. This transformation gave a seamless user experience to the visitors since there is very little time taken for loading the web page. Moreover, once loaded, the web page does not reload itself again.

In this article, we will discuss these technically different approaches on web page rendering. I will explain the major differences between each approach and suggest an approach for you.

Server-side rendering

Server-side rendering or SSR is the conventional way of rendering web pages on the browser. As discussed above, the traditional way of rendering dynamic web content follows the below steps:

The user sends a request to a website (usually via a browser)
The server checks the resource, compiles and prepares the HTML content after traversing through server-side scripts lying within the page.
This compiled HTML is sent to the client’s browser for further rendering and display.
The browser downloads the HTML and makes the site visible to the end-user
The browser then downloads the Javascript (JS) and as it executes the JS, it makes the page interactive

SSR Flow

In this process, all the burden of getting the dynamic content, converting it to HTML, and sending it to the browser remains on the server. Hence, this process is called server-side rendering (SSR).

This responsibility of rendering the complete HTML in advance comes with a burden on memory and processing power on the Server. This increases the page load time compared to the page load time for a static site where there is no dynamic content to render.

Client-side rendering

Client-side rendering or CSR is a different approach to how the web page is processed for display on the browser. In the CSR, the burden of compiling dynamic content and generate HTML for them is transferred to the client browser.

This approach is powered with JavaScript frameworks and libraries like ReactJS, VueJS, and Angular. The normal flow of web page rendering for a client-side rendering scenario follows the below steps:

The user sends a request to a website (usually via a browser)
Instead of a Server, a CDN (Content Delivery Network) can be used to serve static HTML, CSS and supporting files to the user
The browser downloads the HTML and then the JS, meanwhile the user sees a loading symbol
After the browser fetches the JS, it makes API requests via AJAX to fetch the dynamic content and processes it to render the final content
After the server responds, the final content is rendered using DOM processing on the client browser

CSR Flow

Since this process involves fetching and processing data on the client front, the process is called client-side rendering.

Client-side rendering (CSR) vs. Server-side rendering (SSR) - Comparison

Since both the approaches are different in the way the content is processed, each method has its benefits. Let us compare CSR vs. SSR from a user as well as the web perspective.

Web page load time

The web page load time is the time taken between when a request is sent to the server and when is it rendered on the browser. This is an important aspect when it comes to user experience (UX) for your website or web application. The web page load times for CSR v/s SSR are different in two scenarios:

First page load time

The first page load time is the average time taken when the user loads your website for the first time. On the first load, in CSR, the browser loads base HTML, CSS, and all the scripts required at once and then compile HTML to usable content on the browser.

This time usually is more than getting a pre-compiled HTML and the corresponding scripts from the server. Thus, SSR takes lesser time normally when it comes to the first page load time.

Second and further page load time

The second page load time is the average time taken to navigate from one page to another. In this scenario, since all the supporting scripts are loaded in advance for CSR, the load time is lesser for CSR (and thus better performance). It does not send a request to the server unless a lazy module JavaScript needs to be loaded.

However, for SSR, the complete request cycle followed in the first-page load is repeated. This means that there is hardly any impact on web page load time when it comes to SSR. Thus, in this scenario, CSR responds faster.

It is important to note here that the above inference does not consider network aspects in depth. We believe that the client and server have comparable bandwidth on the network.

Impact of Caching

Caching has become the need for the day now. To speed up heavy web applications, every browser, as well as the webserver, employs caching mechanisms to cache the reusable scripts on the client's machine. This improves the load time overall for CSR as well as SSR. However, a major benefit is available for CSR.

In CSR, as long as a lazy module loading is not required, practically CSR based web applications can run without the internet too! (unless you call an API for data). Once loaded, the app does not need to send requests to the server anymore. This allows the web application to be navigated, just like a simple desktop application.

In SSR, however, the request to the server is always sent. Hence, the page load time is undoubtedly higher for SSR compared to CSR. Caching does improve the content rendering speed even for SSR as the scripts would be retrieved by browser from the cache. Below image depicts how the browser handles a repeated request for a cached script-

Notice here that most of the scripts are loaded from the memory or disk cache. This improves the load time considerably and prevents excessive load on the server as well.

Impact on SEO

For a business website, optimizing it for search engines is essential. Search engines read and understand your websites using automated bots called crawlers. These crawlers are interested in the metadata of your website more than the actual content. Hence, it becomes vital that your web page reflects the right metadata for the search engines.

With CSR, the web page content is dynamically generated using JavaScript. This means the change of metadata from one page to another relies on JavaScript execution. In the past search engines preferred not to run JavaScript while crawlers crawled through the sites. However, with Google accepting to run JavaScript, the trend is changing.

With CSR, you need to utilize and make an additional effort to ensure that the page metadata changes from one page to the other. This calls for the use of plugins like React Helmet for ReactJS and the use of library modules like Meta from @angular/browser library for Angular framework. You need to put in extra efforts for the metadata to be set for each page and render it on the client-side.

With SSR, the complete page is compiled with the right metadata and sent to the frontend only after getting the final HTML content. This ensures the page metadata is always accurate irrespective of whether the crawler allows the use of JavaScript or not. This makes SSR a better solution to search-engine-optimized pages

Choosing the right path for you

Lesser choices are always the simplest. Conventionally, you had a single choice - SSR. With CSR coming into the picture, the question arises which one is the right one for your application or website. Let us understand where each of them is beneficial.

Dynamic content loading

A server normally resides on a machine with higher compute power and considerably higher networking speeds. With this speed and power, it never runs out of juice while processing the expected number of requests for processing. As a result, the fetching of content on the server front becomes comparatively faster.

Client machines, on the other end, have limited compute power and might take longer for fetching and rendering the dynamic content on the client-side. This means the overall time consumed to get the content rendered will be more. Thus, if your website involves repeated dynamic content rendering, SSR is a better choice over CSR.

Web application UX v/s Website UX

Although they appear almost the same, web applications and websites are two different formats of web content. A web application is a complete application that can be used for purposes like accounting, CRM, HR management, Project management, etc. A website, on the other hand, is informative content about the business.

A web application involves far more user interaction compared to a website since the user performs data entry and generate reports in a web application. In a scenario where user interaction is more, it is crucial to ensure that the clicks don't take long. So, CSR works better for web applications compared to SSR.

On the other hand, for a website, a customer is okay if the new web page loads on every click since the caching would typically take care of speeding up the rendering. Moreover, SSR also ensures the right metadata for crawlers - this makes SSR better for websites compared to CSR.

Best of Both Worlds

After going through the above, you might be wondering if there were a way to get the benefits of SSR's quick first loads and better SEO performance with a near-native feeling of a CSR. You're in luck! - There are frameworks that work on a hybrid approach such as Gatsby.

What it essentially does it that while the first page is always loaded with SSR, it caches the other pages after the load is done so the rest of the pages are pre-rendered and cached making it feel like you're using CSR approach on the subsequent pages! Check out our website, which is also built using Gatsby.

Conclusion

CSR and SSR are critical to the UX you plan to offer to your user. I hope this article helped you understand these concepts from a functional and practical point of view. The final choice is ultimately yours. Choose wisely considering the above factors. The wrong choice might cost you redevelopment of the entire website or web application too. The right choice might reduce your code management efforts in the future also.

Bootcamp 2019

Karan Shah — Thu, 12 Dec 2019 11:59:14 +0000

At SoluteLabs, we conducted a one-day workshop for our new joiners who will intern and hopefully turn into full-time employees in no time.

To ease their transition into this Corporate Jungle, we conduct a one-day workshop for them to play games, connect with each other, have good food and get to know first hand about what it means to join Solutelabs and how this marks an end to their (mostly carefree) university life!

A Developer's Guide to Flutter

Karan Shah — Thu, 28 Nov 2019 11:27:50 +0000

Since it's much-awaited launch, Flutter has caught a lot of attention, and we're excited about it too! I'm hoping that a massive chunk of non-game apps will transition to flutter, and in anticipation, we are therefore training our team on it as well.

Since there are new, but few, resources scattered over the internet to learn flutter - we've compiled our Flutter tutorial to get developers off their feet and start developing apps for Flutter.

In this Flutter guide for beginners, we will cover:

Flutter: What, How, and Why?
Setting up Flutter
Dart Basics
Flutter Basics
Widgets
Layouts
Interactive Widgets
Designing an app: Forms, Gestures, and Images
Lists & Navigation
Networking
JSON and Serialization
Dependency Management
State Management
Testing (Unit and Integration)

Flutter: What, How, and Why?

What is Flutter, and how is it different? Just remember this - Flutter was built to work for any device with a screen and works with:

iOS and Android
Web and Desktop (Mac, Windows, and Ubuntu) - Even support PWA
Auto
Raspberry Pi (POC stage)

Check out this video from Google; it's a great place to get a grasp - comparing Native Development, Hybrid App Development, React Native Development, and finally, Flutter App Development.

Here is the latest news on the launch of the new version of Flutter and Dart programming language-

Google Launched Flutter SDK 1.2 and Dart Programming Language 2.2 | by Milind Mevada | Learn v/s Unlearn | SoluteLabs

Milind Mevada ・ Apr 1, 2019 ・ 3 min read
blog.solutelabs.com

Setting up Flutter

Flutter is relatively straightforward to set up and depending on what OS you're using; you can check out the steps in this official Flutter tutorial:

https://flutter.dev/docs/get-started/install

But in case, you do run into something, check out here: https://github.com/flutter/flutter/wiki/Workarounds-for-common-issues#flutter-installation

The reason we ask that you setup Flutter before Dart is because when you install Flutter, you install Dart too, and while you can separately install dart, it would an unnecessary step. Flutter will decide which dart version will be used, so installing different dart version will be ambiguous as well.

Once you've downloaded and unzipped Flutter, you should see something like this on running the flutter command at the console:

If you're new to mobile development in general, you will need to download Xcode and Android Studio (and toolchain), as well. Once you've setup Flutter, scaffolding a new project is just one command.

Dart Basics

Flutter uses Dart language to build Apps. To understand why Flutter uses dart, check out my previous blog and down to the section - How Flutter was born

Flutter for your next ‘product’ idea — Everything you need to know | by Karan Shah | Learn v/s Unlearn | SoluteLabs

Karan Shah ・ May 25, 2020 ・ 12 min read
blog.solutelabs.com

Flutter and Chrome use the same rendering engine - SKIA. Instead of interacting with native APIs, it controls every pixel on the screen, which gives it the much necessary freedom from the legacy baggage as well as the performance it has.

Do give the official doc a read, but I found this one to be good at explaining dart

Why Flutter Uses Dart

P.S. You can follow up with dart updates on their medium account

Now, you know why Google choose Dart - so let's get your hands dirty!

Learn Dart

Check out the official docs of Dart language, a tour, and their language samples.

Once you have an overview, head over to http://jpryan.me/dartbyexample/ and do all the examples religiously.

Practice, Practice, Practice!

Edit your code on DartPad for starters and get a better grip. I'm sure you'll be up and running in no time!

After, you're done with dartbyexample, head over to exercism, and complete their dart track. It's trendy, so in case it's full, you can do the practice track too.

Dart | Exercism

Flutter Basics

Now that you're familiar with Dart, it's finally time to move on to Flutter

Let's start with the technical overview here:

Technical overview

And scaffold a new flutter app with:

$ flutter create app_name

And you should see something like this:

Open the project on the Android Studio, download the emulator, and an Android version if not done already and run the project - and et voila!

Understand as to how should you structure your project directory and understand which files are meant for which purpose

Flutter Project Structure

Now that you've setup flutter, it's time to do what all developers do! Use other's code 😆 - what I meant is to set up the package file: pubspec, written in YAML

The pubspec file

Widgets

Remember - Everything's a widget in Flutter

If you've not read the technical overview as we asked you before, go back and read it :) You will get a fair idea of what widgets are. Widgets come in two flavors: stateless and stateful

Stateless Widgets are those whose state doesn't change like a button or an image. As the name states, it doesn't change its state when an action is performed on the screen.

Check out the short video series, and it's documentation by Google to explore in-depth (I'm attaching the first video in the series).

When a widget needs to hold some state like a current page in PageView, the currently selected tab in a BottomNavigationBar, Stateful widgets are the right choice to make.

StatefulWidgets can hold the current state of a Widget. Instead of a widget build method, a Stateful widget has a State build method which calls each time we explicitly call setState.

And Similarly, check out the documentation (it has the video inside) for the stateful widgets here:

StatefulWidget class

Flutter 1.9 was released at GDD China with a host of new features and a mark that the community is multiplying (and that you can't ignore China now)

Layouts in Flutter

As we discussed earlier, everything is a widget in Flutter - including layout models.

Check out the documentation here:

Layouts in Flutter

Widgets such as the rows, columns, and grid are layout widgets (which we don't see on screen) that helps other visible widgets to arrange, constraints, and align.

⏰ Time for Codelab: Write your First Flutter App : Part-1

And, Some more Widgets!

Flutter comes with a suite of powerful basic Widgets such as Text, Column, Row, Stack, and Container. The basic widgets will help you creating custom views as you want.

If your app follows material design guidelines, Flutter has a lot to cover by default. Flutter provides several widgets that support Material Design. It includes widgets such as MaterialApp, AppBar, Scaffold, etc.

Flutter also includes the iOS-centric Cupertino component package. It covers widgets such as CupertinoApp, CupertinoNavigationBar, etc.

Interactive Widgets

So far, we have seen Widgets that display information on-screen or arrange other widgets. For the real app, it is equally essential to make the app interactive and get user's input in various forms like Gesture, taps, etc.

To achieve this, Flutter has numbers of StatefullWidgets such as Checkbox, Radio, Slider, InkWell, Form, and TextField, etc. These widgets are capable enough to maintain their state (e.g., Text we are entering in TextField, whether a CheckList is checked or not.)

Go and check out the below example to add Favorites/Non-Favorites functionality to your app.

Adding interactivity to your Flutter app

⏰ Time for Codelab: Write your First Flutter App : Part-2

As you have reached here, you should be clear with What is Widgets? and Types of Widget

Now you must be curious about what are all widgets available in Flutter?

So here is a Widget Catalog, Check all the Widgets that make Flutter development relaxed and Fun 😍

Widget catalog

Flutter Cookbook

And here we go, It's time to learn Flutter for real apps. I mean Apps that have Multiple screens, Images, Network dependency, and all.

So, Let's begin.

Designing an App

Check the below app illustration.

This Simple looking app has these features 👇

Navigation Drawer
https://flutter.dev/docs/cookbook/design/drawer
SnackBar
https://flutter.dev/docs/cookbook/design/snackbars
Custom Fonts (A Text have its own Style 😉)
https://flutter.dev/docs/cookbook/design/package-fonts
A Text-based on Orientation (Bigger fonts in Landscape)
https://flutter.dev/docs/cookbook/design/orientation
And, Multiple Tabs
https://flutter.dev/docs/cookbook/design/tabs

Note here: OrientationBuilder is independent of the device's orientation. Instead, It calculates the current Orientation by comparing the width and height available to the parent widget. To determine the device's orientation you can refer MediaQuery.of(context).orientation

Forms

Flutter has a Form widget that helps to build a form that efficiently manages the essential requirement of a Form, e.g., State of a Form, Validation, etc. Check out the complete guild in the below documentation.

Cookbook

Gestures

To get the user inputs and some-time to make the app super interactive, we maximize the use of Gestures. Flutter has pre-built widgets to cover this.

Adding Material Ripple Effect
https://flutter.dev/docs/cookbook/gestures/ripples
Handle Taps
https://flutter.dev/docs/cookbook/gestures/handling-taps
Swipe to Dismiss
https://flutter.dev/docs/cookbook/gestures/dismissible

Images

To make apps beautiful and engaging, we use Images. Flutter provides an Image widget to display an image in the Flutter app from various sources.

Display Images from Network

Display images from the internet

Display Image with Placeholder & with Fade-in Animation

Fade in images with a placeholder

Sometimes it's handy to Load image from network and cache it in local storage to make it quickly available next time.

Work with cached images

Showing more data using List

To accommodate more data, we use List to show them. The list can be horizontally or linearly.

Flutter has a GridView and ListView. These are basic widgets with different contractors to identify how they can be used.

Create a grid list

Create a grid list

Create list horizontally

Create a horizontal list

The list can have different types of Item. E.g., a header & items to it. Check here how you can cover such cases in ListView.

Create lists with different types of items

Floating app bar and Nested scrolling using SliverList

Place a floating app bar above a list .

Don't forget to check out this awesome article by Emily Fortuna to understand Slivers in depth

Sometimes we have predefined arbitrary items to be placed in a List. e.g., Setting categories. In ListView, you can pass custom items (in the form of Widgets) to its children.

Use lists

Sometimes a List has more items then the viewport of a screen. In such cases, it makes no sense to build all the items at once. Flutter has ListView.Builder that uses the Lazy rendering approach to create list items efficiently.

Work with long lists

If you have more items in a list and looking to paginate them. Here is a good article I found 👇

Flutter ListView Pagination for Infinite Scroll (Guide) | Learn v/s Unlearn | SoluteLabs

Aakash D. Mehta ・ May 25, 2020 ・ 3 min read
blog.solutelabs.com

Navigating between screens aka routes

Most apps contain multiple screens to display data in a well-organized manner.

In Flutter, we can do navigation-related operations using Navigator.
Check below diagram to understand how Flutter manages multiple routes, and later, we will discuss how to navigate up and forth between them.

Navigate to a new screen and back

Navigate to a new screen and back

Pass data to new screens and retrieve results.

Send data to a new screen

Return data from a screen

So far, what we have seen is suitable for small projects. But when the project grows, we want to manage all routes at a single place. Also, we might need to address below questions

How many routes we have?

How to initialize each route?

What data is required by each route? etc..

To manage all this efficiently, Flutter has named routes.

Navigate with named routes

Pass arguments in named routes.

Pass arguments to a named route

And, What about this animation while navigating to a new screen?

Animate a widget across screens

Animate a widget across screens

Networking

Most apps we come across nowadays, are generally connected with third party server and makes requests to the server to fetch or post data.

In Flutter, we can use Http as a third party pub to do such stuff.

http | Dart Package

Fetch data from the network

Fetch data from the internet

Make authenticated requests

Make authenticated requests

Work with web sockets

Work with WebSockets

Flutter has few more pubs available, which do such stuff more efficiently. Don't forget to take a look at the below pubs.

dio | Dart Package

chopper | Dart Package

Using JSON and Serialization

In Flutter, we generally have two strategies for JSON serialization. Manual parsing and automated serialization using code generation.

Runtime reflection is disabled in Flutter, resulting we cannot have libraries like GSON, Jackson or Moshi

Check out the full guide with both strategies here:

JSON and serialization

For manual parsing, don't forget to check out this online tool to auto-generate boilerplate for the model class.

Instantly parse JSON in any language | quicktype

Data Persistence

Sometimes we need to persist data in local memory to quickly available whenever we need them.

If you have a relatively small amount of data to be stored in a key-value pair. Consider using shared-preferences. Below is the detailed guide to achieving the same using Flutter.

Store key-value data on disk

You can also read and write files on disk.

Read and write files

If an app needs to persist a large amount of data and also it requires to query them. It is advised to use an SQLite database

Flutter app can use the SQLite database via sqflite pub.

Persist data with SQLite

For easy to use, reactive persistence, check out below pub. Moor is a wrapper around sqflite.

moor_flutter | Flutter Package

Dependency Management

We use so many pubs in the app. It's a great way to work collectively and share code across apps without having to develop everything from scratch.

You can find all the useful packages from here.

Dart packages

With multiple pubs, you might faces issues like conflicts in the version resolving. You can find all the best practices here to be followed while using pubs.

Using packages

And, with all this, you now have completed Flutter cookbook. 👏

An Art of State Management

Introduction

In a typical app, it is a common use-case that a change made at Point-A reflects some changes at Point-B. That is called State management. It can also be understood by the below illustration.

Flutter has multiple approaches that can efficiently manage the State of the app. Based on project size we can decide the appropriate techniques.

Here we will discuss a few of the possible techniques for State management.

setState way

Adding interactivity to your Flutter app

Basic State Management in Google Flutter | by Agung Surya | Medium

Agung Surya ・ Jul 23, 2018 ・ 4 min read
Medium

Inherited Widget

Check out the below video to understand, What is Inherited Widgets?

Also, Check out the complete list of articles here.

List of state management approaches

Remember "Theme.of(context);" and "Navigator.of(context);" you used earlier? That is using the same Inherited Widget concept to access data down in the widget tree.

The Provider Package

The provider is a mixture of DI (dependency injection) and State management built with widgets for widgets.

Official documentation of provider is too good to understand it in depth.

provider - Dart API docs

BLoC Pattern

BLoC is a Simple, Lightweight, and highly testable a predictable state management library for Dart.

Here is an official guide to: Bloc

I also found this good video series explaining BLoC pattern (with Accompanying article series)

There are also other popular State management techniques in the industry. Like Redux and Mobx.

Testing

When the app grows, it becomes hard to test every feature, and then it comes regression too. In such cases, automation testing is the way to go. It helps ensure that the app performs as expected before we release it.
And so we don't fall in such situations. 😆

Automation testing falls under three categories

A unit test tests a single function, method, or class.
A *widget test (in other UI frameworks referred to as component test) tests a single widget.
An *integration test tests a complete app or a large part of an app.

Check out the introduction to testing in Flutter here

Testing Flutter apps

Unit Testing

The goal of Unit testing is to test a particular Unit of code with Stub/mock dependencies. Verify the code works as expected in different scenarios. A unit test is very fast and doesn't require an actual device to execute.

An introduction to unit testing

While doing Unit tests, any dependent classes should be injectable, so that we can inject a mock or fake implementation of dependancy and verify if everything working as expected. Flutter has a mockito framework that helps to create a mock or fake implementation.

mockito | Dart Package

Widget Testing

Widget Testing (in Flutter) is a UI testing technique.
The goal of widget testing is to test if particular Widget UI looks as expected, and it's interactive. Widget testing doesn't require a physical device.

We could also test the properties of Widget, like Color, Size, Font Family, etc..
We can also perform user events like tap, gestures, entering text, etc.

An introduction to widget testing

Integration Testing

Integration test work in a pair. The goal here is to test how multiple units work together. Integration testing happens on a real device or emulators.

We can fire a series of User interaction events and expect UI rendering or unit codes to be executed properly.

An introduction to integration testing

BDD: Behavior-driven development

TDD or Unit Tests helps when a stakeholder has strong technical skills. BDD is all about writing a test case from the end user's perspective. This is written in a natural English language.

Testcase can be written in the below format:
Given: the initial context at the beginning of the scenario, in one or more clauses;
when: the event that triggers the scenario;
then: the expected outcome, in one or more clauses.

Internally, a behavior test cases can be a Unit test, widget test, or a combination of both.

BDD helps to understand software functionality from an end-user perspective and becomes a sort of functional documentation.

Flutter has a gherkin that helps us writing Behaviour Test cases.

gherkin | Dart Package

This guide covers all the basics that you would need to know to start with flutter and develop your apps! We hope this helps you on your journey to flutter.