{"id":2395,"date":"2020-10-13T11:22:08","date_gmt":"2020-10-13T11:22:08","guid":{"rendered":"https:\/\/devexperts.com\/blog\/?p=2395"},"modified":"2022-08-11T16:26:52","modified_gmt":"2022-08-11T16:26:52","slug":"flutter-flutter-little-bat-is-cross-platform-development-finally-for-everyone","status":"publish","type":"post","link":"https:\/\/devexperts.com\/blog\/flutter-flutter-little-bat-is-cross-platform-development-finally-for-everyone\/","title":{"rendered":"Flutter, Flutter Little Bat: Is Cross-Platform Development Finally for Everyone?"},"content":{"rendered":"\n
<\/picture><\/figure><\/div>\n\n\n\n

We\u2019ve recently seen lot of discussion concerning Flutter, specifically, whether it\u2019s the new silver bullet (spoiler alert: it’s not) of mobile development, or if it\u2019s just another awful cross-platform framework that allows developers to build sub-par applications, while putting in little to no effort (second spoiler alert: you will<\/em> have a bad app with minimal effort, but the framework isn\u2019t to blame). I\u2019ve decided to write a few words on Flutter, as well as cross-platform approaches overall and how they fit in with Fintech and trading apps in particular. Let\u2019s see how they stack up. <\/p>\n\n\n\n

For starters, Flutter is a mobile cross-platform development framework that in theory, allows you to write the app once and run it on multiple platforms, mainly, iOS and Android. From there, you could write a web app using the same codebase, but I\u2019ll try to stick to mobile to keep it simple for now. <\/p>\n\n\n\n

Given that the idea is pretty promising, Flutter is not the first attempt to make it work. Today, Microsoft has Xamarin, Facebook has ReactNative, even Devexperts used to have a cross-platform framework with a less fancy name, called MOBUI at one point in time. So, Google decided they needed their own technology, targeting the same goal, but that addressed a few of the weakest points of cross-platform development.<\/p>\n\n\n\n

So, let\u2019s have a brief look under the hood. <\/p>\n\n\n\n

Flutter compiles into the native binaries on both platforms. These binaries are then called from the respective application wrapper, which then provides your app with the canvas to draw on, as well as all the inputs you’d typically receive from the user or the external world. This is sort of a gamedev-style approach to the interaction with the underlying OS, aside from the framework built on top of that.<\/p>\n\n\n\n

The thing to mention is that Flutter uses the Dart programming language. It\u2019s not widely used in the industry, but that\u2019s no problem. Syntax-wise, Dart is absolutely familiar to anyone who knows Java, Kotlin or Swift. Of course it has some minor, convenient features; but that said, it does not prevent developers from figuring out how the code works right away.<\/p>\n\n\n\n

On top of that, Flutter provides developers with a rich and beautiful UI kit, including a set of ready-to-go widgets. Even though none of them have anything to do with the native controls, they are designed to look exactly like the native ones. So we have both Material(Android-like) and Cupertino(iOS-like) controls. More on that later.<\/p>\n\n\n\n

What does this all mean in practice? Several things:<\/p>\n\n\n\n

  1. The UI can be super fast and responsive, given the framework\u2019s low operational overhead.<\/li>
  2. There is no \u201cmagic\u201d happening, unlike ReactNative or Xamarin \u2013 no virtual machine, no intermediate code generation \u2013 the code written is the code run. Which is good news both in terms of debugging and performance profiling.<\/li>
  3. It is pretty easy to kick-start application development using Flutter. Moreover, it\u2019s simple to sketch a great (and even native)-looking UI for both platforms.<\/li><\/ol>\n\n\n\n

    But let\u2019s get back to Dart. Aside from the syntax, I didn’t mention one thing yet: Dart is a single-threaded language. It is designed to operate on top of the event loop, allowing you to perform asynchronous operations. For the most part, that\u2019s what developers need. This approach not only simplifies memory management, but also guards you against all the concurrency problems developers can face. <\/p>\n\n\n\n

    While that all sounds good as it addresses a lot of the development pain, it’s still not a one-size-fits-all solution. The thing is, the simpler your application, the higher the chances technology like Flutter will fit your use case. Here I would totally agree with Juhani Lehtim\u00e4ki from Snapp, who gives us this awesome diagram:<\/p>\n\n\n\n

    \"\"
    The simpler your application, the higher the chances technology like Flutter will fit your use case. Credit: Juhani Lehtim\u00e4ki, https:\/\/medium.com\/snapp-mobile\/the-fundamental-problems-with-cross-platform-frameworks-cea57ac18fef<\/figcaption><\/figure>\n\n\n\n

    And this is not a bad thing at all. Today we are seeing a widespread demand for super simple apps. If the industry becomes capable of creating these apps cheaper and faster, more businesses will be able to afford a modern and sleek app \u2013 and more importantly, to support it over a period of time without paying for two separate apps individually.<\/p>\n\n\n\n

    On the topic of more sophisticated mobile solutions, let’s have a look at what does not work so well to the right of the orange dashed line.<\/p>\n\n\n\n

    The first topic would be the single-threaded asynchronous approach versus concurrency. The first one will definitely work if your app doesn\u2019t load or compute the data dynamically. It might be an app consisting of pre-composed static content, or a basic fetch-and-display application. For instance we have a list of <some things>, each one has a separate page with the details and actions. We load this list once, and work with it. We can change the filter and reload the list once in a while, but that does not change the picture dramatically.<\/p>\n\n\n\n

    Now, imagine the other extreme: real-time data streaming to the app, changing the values multiple times a second. Also imagine having a mathematical model that combines both user input and the streaming data and updates the values of a number of the fields on the screen, as well as their existence. Now you live in my world! <\/p>\n\n\n\n

    In order to achieve this while making the process fast and fluid, you need a number of things. First, an asynchronous data transfer protocol. You need a way to explicitly specify which logic can run on the main thread, and which might be unpredictably slow and must be moved out. Second, you need a way to orchestrate all this. In other words, you need more control. Flutter wasn\u2019t designed for this. <\/p>\n\n\n\n

    Could you still do it? Oh you could. You could work with multiple Isolates. Or you could write this natively and leverage the interop, which is workable in this case. The main hesitation is whether this approach would pay off. To put it simply, this is a tool that doesn’t fit the use case. All these \u201coverly complex\u201d multithreading concepts, such as shared memory, atomic transactions, synchronization, concurrent algorithms and data structures, are here for a reason. In the real world, we have tons of cases where the developer needs them to create a working code. As the complexity of the app grows, the probability you\u2019ll need more control becomes more and more significant.<\/p>\n\n\n\n