Contents

    Project Idea

    • Supporting the worldwide Flutter community with open source solutions developed by Surf.

    The Solution

    Surf has been working with Flutter since 2019. By publishing articles and podcasts, we actively take part in the life of the expert community. We not only use the framework but also strive to make it better and more up-to-date. Thanks to our initiative, we have brought together a strong team of Flutter developers. This team is the one responsible for the first Flutter-powered banking app in Europe.

    In addition to that, we put considerable effort into improving the process of development itself; we write libraries and create open-access repositories. In this case, we elaborated on one of these projects — a library called Elementary.

    Our most ambitious project, however, is Surf Gear. It is a collection of libraries (ranging from architectural patterns to full UI components) aimed at making the life of a Flutter developer simpler.

    We try to be extremely open. That’s why our coding standards are public and accessible on GitHub. Today, they are used not only by our colleagues, but the Flutter community at large.

    The meaning and history behind Surf Gear

    Surf Gear is a set of libraries and tools that we use in Flutter development. All solutions are in compliance with our quality standards and are maintained and upgraded by the Surf team. As for the quality standards, we established those ourselves and wrote them into our in-house instructions, thus providing a uniform style and making it easier to search for the things you need.

    Over the course of the time we spent working with Flutter, we have created and tested numerous solutions, which have now gained widespread use all over the world. To make them even easier to use, we have analyzed which solutions are most popular among the members of the community and gathered them into a coherent, classified system called Surf Gear. This became a window display of sorts, showcasing quality products for Flutter development. Any developer can tap into our system and find the perfect solution to match their task.

    The system is under ongoing maintenance: we continue to fix bugs and upgrade packages. Third-party developers occasionally send us requests and suggestions, and we add these functionalities into a package, provided that the request is reasonable.

    Surf Gear under the hood

    Surf Gear is based on the concept of open-source software. It’s a growth area for developers; they can both help the expert community and contribute to the technology.

    Surf makes projects for businesses, which means we address the most pressing consumer needs. As a result, we gradually put together a library of out-of-the-box solutions, which we then decided to share with everyone. To give the process a little structure, we have produced a set of in-house instructions.

    In addition to that, we have worked out a structure for an ideal repository. It has to include the following: 

    • Readme — a short description in text. We have created a guide on writing a good readme: what blocks to include and what information to give. A readme is designed to address basic questions.
    • Changelog — a log of changes made to a project. We use version control systems and adhere to conventional commits (an agreement on how to write messages about the latest changes in code).
    • Simple examples. These help programmers understand quickly whether a package addresses the need they have. The messages have to be concise, precise, and to the point. According to statistics, most developers look for examples as soon as they come across a new library or package.
    • Tests. Writing tests is one of the crucial tasks when it comes to setting up a repository. With each update, it is vital to avoid package degradation. And that is tricky to achieve without testing. All packages that make it to Surf Gear are covered with tests.

    A test is the most reliable way to ensure you won’t make it worse for the people who trust you and use your solutions.

    • Automation tests. We run automation tests against each tool in Surf Gear via GitHub Actions. This is done in order to assess quality objectively. Each section—documents, testing, examples—undergoes assessment.

    One of the key requirements we set for every solution suggested to the community is its usefulness. 

    The solutions available in Surf Gear

    Analytics

    This interface helps handle various analytical services in a unified way. Its main components are:

    • AnalyticAction takes note of each action valuable for analytics. Typically, it’s events like “pressing a button” or “opening a screen”. The main criterion here is the ability to process AnalyticActionPerformer.
    • AnalyticActionPerformer performs specific actions. It is used to encapsulate ways of handling a specific analytical service. It is usually implemented by converting AnalyticAction into a specific format and using a third-party library.
    • AnalyticService is a common entry point for several AnalyticActionPerformers.

    Bottom Sheet

    One of our most popular solutions, this one is a small bottom sheet you can find in almost every mobile app, from banking apps to e-commerce. Flutter provides a standard Bottom Sheet with scrollable content. However, the functionality provided in the standard solution wasn’t enough for us. That’s why we created a wrapper: added anchor links and expanded the capabilities of the standard Flutter solution. The sheet can now stop at the middle or the end of the screen. For example, with our solution, users can open the keyboard at the bottom of the screen and still see the scrollable bottom sheet. Thanks to that, users can type in the information, which stays visible rather than hidden behind the keyboard.  

    Essentially, there are 2 types of BottomSheets:

    • BottomSheet—a classic version, 
    • StickyBottomSheet—a sheet with a small header above.

    OTP autofill

    OTP is a one-time password. We built a plugin to trace text messages a service sends for registration and authentication purposes. To receive this code, native development has a number of dedicated plugins. The native part analyzes the text message, extracts the code data needed for the autocomplete and sends it to the developer.

    Push Notification

    A library designed to implement push notifications. This one helps process the incoming notifications, show them to a user and direct them to a specific page in your app. It already has the essential configurations you will need to handle push notifications. Namely:

    • a processing strategy for incoming push notifications,
    • specifications for iOS and Android,
    • an entity called Notificator designed to request notification permission (on iOS only) and display the notifications,
    • developers can set the timer for notification delivery,
    • they can also keep track of user location.

    All you have to do is configure it for your app. We use this library in retail apps and the app we built for the YouTube publisher.

    Surf Lint Rules

    This one is a set of rules for a static analyzer. Such rules are safety measures regarding programming in a specific language. We based it on frequently made mistakes. 

    It has automated mechanics to help developers find issues in code: analyze it and highlight alerts. Such language-specific options help find bugs. There’s also an option of adding even stricter rules: sets of actions that shouldn’t be taken.

    We have our own set of requirements so as to write cleaner code and avoid common errors. Most of them we can find while we’re still writing code. This approach is good for development: if you follow a strict algorithm right from the start, you can avoid most of the minor errors. 

    Surf Logger

    This one is a recorder that provides information on events in code. Logging (creating records of) entities is considered good practice. With Surf Logger, developers can keep records of all events and actions. Developers can specify which string to mark and log and then examine the received information. Among other things, the data gathered can then be sent to the console to examine the error.

    Surf Util

    These are small solutions incorporated into a single package and used in many of our projects as baseline supplementary utilities. For example, with one of the utilities, developers can easily disable the overscroll icon denoting the end of a page.

    Swipe Refresh

    This one is a widget that implements refreshing a page with a swipe. This tool is designed to configure one of the most frequent actions in any app. When users swipe the screen down, they see a page refresh icon, and the app loads new data.

    This widget can do the following:

    • refresh the state of a page (refresh),
    • identify scroll refresh,
    • refresh a page in line with Material,
    • refresh a page in line with Cupertino.

    Render Metrics

    This package helps obtain coordinates on screen. 

    With Render Metrics, developers can do the following:

    • obtain a full set of coordinates of a specific widget at any point in time,
    • calculate the difference in location between widgets.

    Bottom inset obserever

    This is a handy utility designed to observe various platform states. It provides various ways to observe what appears at the bottom of the screen. For instance, once the keyboard pops up, it occupies a specific place on the screen, covering the bottom part of it.

    The Result

    In each of our projects, we use something from Surf Gear. That is exactly how it came into being: we gathered our most popular solutions and analyzed what we use most often. We established strict requirements and brought each of our packages into compliance with those. While analyzing the product, we looked at it in terms of benefits and community requests.

    Contact us
    Let’s discuss your project together
    CEO photo white

    Vladi Makeew

    CEO of Surf
    Drop a file here or click to upload
      Hidden span