DEV Community: Moses Karunia

Simply Responsive

Moses Karunia — Tue, 08 Dec 2020 15:58:47 +0000

Hello guys, so I just published my first open source library for flutter.

This is a mobile-first widget to help us build a responsive app across mobile, tablet, and desktop with ease. Unlike the CSS 12 grid system, The design of simply_responsive is based on 3-columns design of a desktop website. This has an advantage of being simpler to use than the CSS 12 grid system, at the cost of reduced possible flexibilities. I try to make this library as tested as possible.

And, since it's responsive, it'll be no need for you to lock the orientation of your app to portrait only!

Example

SimplyResponsiveBody(
  LayoutConfig.build(MediaQuery.of(context).size.width),
  leftChild: ListView(
    children: [
      Text('Home'),
      Text('Profile'),
      Text('Sign Out'),
    ]
  ),
  centerChild: ListView(
    children: [
      Text('Lorem Ipsum'),
      Text('Lorem ipsum dolor sit amet')
    ]
  ),
  rightChild: ListView(
    children: [
      Text('Tap to like')
      Text('Tap to dislike')
    ]
  )
)

Just by writing that code, you can make it responsive across screen sizes and orientation.

Basically, the centerChild is the widget which will appears everytime (although not required).

The left column is usually used to display navigational menus. On this early release, the widget will just hide the left column if the screen is not enough (usually in mobile portrait). You should put it in the drawer if that's the case.

The right column is usually used to display additional content (Like Editor Basics on DEV). On this early release, the widget will just hide the right column if the screen is not enough (usually in mobile portrait and tablet if left column is visible). You should put it in the endDrawer if that's the case.

There's also a two-column mode if you pass centerFlex to 0, and set the centerChild to null.

Feel free to ask any question and give any criticism and suggestion! Thank you.

https://pub.dev/packages/simply_responsive

Introduction to Simply Responsive Design

Moses Karunia — Fri, 27 Nov 2020 11:31:35 +0000

There are a lot of device screen sizes right now. While it's mostly a good thing to give users options, we, as developer (and designer) often suffers (lol) because we need to support those different screen sizes.

There is a popular choice in the 12 grid system in the web development world. But in the app development world, 12 grid responsive system also not that popular (wonder why).

The example of this is the iphone and ipad app. There are quite a lot "ipad" apps out there when downloaded, only displays the layout in the cropped "iphone" view, which is sucks.

Enter the Simply Responsive Design.

Simply Responsive Design is a term I coined (what a creative name right?) myself. This design system derives / inspired from Material Design mostly, and I build it in the context of me, as a flutter developer.

Unlike the 12 grid system, a Simply Responsive Design (or SRD), only assumes there are 3 maximum columns on the screen, along with fixed top and bottom bar / app bar. This simplification has both advantage and disadvantage. Basically, SRD trades flexibility for development speed.

SRD has 3 kind of screen sizes in mind:

Mobile (< 600px width)
Tablet (600 - 767px width)
Desktop (>= 768px width)

As you can see, the UI (or widgets in flutter) placements, are kinda predictable across screen sizes. This makes your development speed faster and easy, if in the beginning of a project, you already make a custom scaffold to abstract out the logic. This way, it will be much easier for subsequent codes to be responsive out of the box.

/// Prototype of SRD as an abstracted out flutter widget
return SimplyResponsiveScaffold(
  title: 'MyTitle'
  leftContents: <Widget>[],
  centerContents: <Widget>[],
  rightContents: <Widget>[],
);

With that widget, no matter what screen size your app is running on, The SimplyResponsiveScaffold will automatically determines where your left, or center, or right should be placed based on the screen size.

(This also make your app works automatically when rotated)

=====

That's it for the introduction part of Simply Responsive Design. In the future articles, I'm going add in-depth explanation of UI elements interactions SRD. I also plan to write a custom flutter library to make it easier to implement SRD.

Thank you and see you in the next article!

Fixing Flutter iOS build fail

Moses Karunia — Sun, 16 Aug 2020 19:26:37 +0000

I have sour experiences on configuring your iOS Flutter build, since I have no experience whatsoever in iOS. But after reading some articles on the internet, I found that many iOS devs also think iOS deployment is kinda hard to do. Often I did shadow punching on google before finding random stranger post a nice pointer.

This article mainly meant as reference in case someone (or myself in the future), hit some roadblock in order to make one. Most credits also go to guys who originally post these solutions I found on the internet. I cannot add any reference to you, because it lost in my search history. You can comment below if you want to be mentioned, though.

Please note that most problem can be solved by creating a new flutter project using the latest stable version, copy-pasting the content of iOS/, and applying manually-made changes (like adding permission on info.plist, firebase-related adjustments, etc)

I'll try to keep this article updated in future Flutter, iOS & XCode releases.

Works well on:

MacOS Catalina 10.15.6
Flutter 1.20.2
Dart 2.7.0
XCode 11.6
iPadOS 13.6.1 (iPad 10.2 - 2019)
iOS Deployment 9.0 (The one set in ios/Podfile as platform :ios, '9.0')

Use the latest STABLE release

Why? Because, it's nice if you can shave down your potential problems by using stable releases.

e.g. XCode version, iPadOS / iOS version, flutter version etc.

Frameworks, Libraries and Embedded Content

iOS Project Structure

Pay attention on the content under Flutter/ and Runner/

Targets > Runner > Build Phases

Run Script

The content should EXACTLY be

/bin/sh "$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" build
/bin/sh "$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" embed

With ONLY "Show environment variables in build log" checked.

Compile Sources, Link binary with libraries, Copy Bundle Resources and Embed Frameworks

Thin Library

Content should EXACTLY be:

/bin/sh "$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" embed
/bin/sh "$FLUTTER_ROOT/packages/flutter_tools/bin/xcode_backend.sh" thin

(NOT embed_and_thin)

With ONLY "Show environment variables in build log" checked.

Targets > Runner > Build Settings

All > Linking > Other Linker Flags

This is the snippet of my package.yaml if you are wondering (because sometimes build fails because of certain release of a library in your dependency)

Note that I didn't use any ^ to prefix the version to make things more certain.

environment:
  sdk: ">=2.7.0 <3.0.0"
  flutter: 1.20.2

dependencies:
  flutter:
    sdk: flutter

  material_design_icons_flutter: 4.0.5345
  cupertino_icons: 0.1.3
  google_fonts: 0.3.2
  get_it: 4.0.2
  equatable: 1.2.0
  dartz: 0.9.1
  meta: 1.1.8
  json_annotation: 3.0.1
  google_sign_in: 4.5.1
  sign_in_with_apple: 
  firebase_core: 0.4.4
  firebase_auth: 0.15.4
  firebase_messaging: 6.0.16
  firebase_analytics: 5.0.16
  graphql: 3.0.2
  flutter_bloc: 6.0.1
  qr_flutter: 3.2.0
  jaguar_jwt: 2.1.6
  barcode_scan: 3.0.1
  dio: 3.0.9
  image_cropper: 1.2.3
  image_picker: 0.6.7+4
  intl: 0.16.1
  stream_transform: 1.2.0
  flare_flutter: 2.0.3
  flutter_svg: 0.18.0
  shared_preferences: 0.5.7+3
  collection: 1.14.13
  flutter_local_notifications: 1.4.4+2
  pattern_formatter: 1.0.2
  hydrated_bloc: 6.0.1
  url_launcher: 5.5.0
  pull_to_refresh: 1.6.0
  copy_with_extension: ">=1.2.0 <2.0.0"
  flame: 0.24.0
  flutter_i18n: 0.17.0
  flutter_neumorphic: 3.0.1
  package_info: 0.4.1
  extended_image: 1.1.0

dev_dependencies:
  flutter_test:
    sdk: flutter
  mockito: 4.1.1
  build_runner: 1.10.1
  json_serializable: 3.3.0
  bloc_test: 7.0.0
  copy_with_extension_gen: ">=1.2.0 <2.0.0"
  flutter_launcher_icons: 0.7.5

That's all I think are important, if you wanna know any other configs, feel free to lemme know in the comment. I'll let you know if I know the answer.

Hope this saves your time!

Managing deeply-nested Flutter files

Moses Karunia — Fri, 07 Aug 2020 07:26:47 +0000

One of many common problems a Flutter developer might face is that their widget files are easy to get crazily deeply-nested. This pose a problem because a deeply nested widgets are relatively harder to read.

One of the solution is to break it into separate, smaller chunk of widget. This way, you can maximize readability by containerizing each widget based on its functionality.

That's a good solution, but for me it's not optimal, because now, there are a lot of separate one-use widgets scattered in our project folder. One of the problem is it makes my naming harder, and it clutters my VS Code autocomplete.

So, it'll be better if we can break our deeply-nested widget file, without it clutters our IDE / editor autocomplete.

This is where I used part and part of directive.

This is an example of how I structure my files:

File: lib/widgets/my_widget/my_widget.dart

/// Import declarations

part 'my_top_widget.w.dart';
part 'my_center_widget.w.dart';
part 'my_bottom_widget.w.dart';

class MyWidget extends StatelessWidget {
  @override
  Widget build (BuildContext context) {
    return Scaffold (
      body: LayoutBuilder(
        build: (context, boxConstraints) {
          return ListView(
            children: <Widget> [
              _$MyFirstSubwidget();
              _$MySecondSubwidget();
            ],
          );
        }
      );
    );
  }
}

File: lib/widgets/my_widget/my_first_widget.w.dart

/// A "Part of" file cannot have its own import declarations

part of 'my_widget.dart';

class _$MyFirstWidget extends StatelessWidget {
  @override
  Widget build (BuildContext context) {
    // TODO: Return widget
  }
}

File: lib/widgets/my_widget/my_second_widget.w.dart

/// A "Part of" file cannot have its own import declarations

part of 'my_widget.dart';

class _$MySecondWidget extends StatelessWidget {
  @override
  Widget build (BuildContext context) {
    // TODO: Return widget
  }
}

Here are the steps:

Put the complex widget into its own folder (my_widget/my_widget.dart)
Prefixing the sub-widgets name with _$ (You don't need the dollar $ sign. It's just my way to differ it with a class-level private. The key is to make it private with _)
Postfix sub-widget file name with *.w.dart. It's just my personal convention to say that a widget is a sub-widget of another widget.

I would also like to add, that by postfixing your sub-widget files with *.w.dart, you can also make similar separate file for your helper function with *.u.dart, where u stands for utility. Again, you can choose whatever postfix you like.

Bonus advantage is, by using this approach, you can easily move the sub-widget out of the folder in case you need it to use it in another main widget. (Too many early refactors are not good)

Hope this tip helps you make flutter files more readable.

Cheers!

Cover image provided by www.freepik.com

Enum in typescript

Moses Karunia — Thu, 31 Oct 2019 12:25:56 +0000

Changelog:

6 Nov 2019: Added type for better developer experience.

I know we can use typescript's enum, but, the difficulty arises when I'm receiving string in REST, and want to validate the property value in the request.

This is the way I write my enums:

// ===== DECLARATION =====

type TerrainEnum = 'MEADOW' | 'OCEAN' | 'FOREST';

class Terrain {
  public static readonly Meadow = 'MEADOW';
  public static readonly Ocean = 'OCEAN';
  public static readonly Forest = 'FOREST';

  public static isValid = (value: string): boolean => (
    value === Terrain.Meadow ||
    value === Terrain.Ocean ||
    value === Terrain.Forest
  );
}

// ===== USAGE =====

// Validate
Terrain.isValid(value);

// In function parameter
const myFunction = (terrain: TerrainEnum): void => {}

I think this way you have a built-in input validations, simply by calling isValid().

I'm interested in what you guys think. Maybe we can find any better option out there.

So, what's your preferred way to write enums? And what's the reason behind yours?

Write cleaner function's optional parameters

Moses Karunia — Tue, 29 Oct 2019 06:08:41 +0000

Clean all the codes!

Update:

Code typo fixed.
Adding default value to optional to make it easier to destructure.

Normally, we can put the optionals last in our function declaration. This way we can simply omit it from our calls when we don't need it.

// Declaration
const myFunction = (param1: string, param2: number, param3?: string, param4?: number) { }

// Call
myFunction("Call me maybe", 12345);

But, there's a time where we need to assign param4 without param3.

myFunction("Call me maybe", 12345, undefined, 67890);

I think that's messy, because we are forced to write undefined first. This is getting incrementally annoying if there're more than 1 undefined in-between. (especially if you are a bit OCD like me)

So, I then remember how the flutter team handles optional parameters, and I think it makes my typescript code much cleaner.

// Declaration
const myFunction = (param1: string, param2: number, 
  optionals: { param3?: string, param4?: number } = { }) { }

// Call 1
myFunction("Call me maybe", 12345, { param4: 67890 });

// Call 2
myFunction("Call me maybe", 12345);

And to make things better, we can destructure our optionals first, instead of prefixing everything with optionals..

const myFunction = (param1: string, param2: number, 
  optionals: { param3?: string, param4?: number } = { }) { 
  const { param3, param4 } = optionals;

  // Write any code here
};

UPDATE: I changed the optionals declaration from optionals?: {} to optionals: {} = {}. This way, you can safely destructure optionals even if it's undefined, because it will be replaced with empty object. Please note that the destructured values can still be undefined.

I think this will look cleaner no matter how many optional parameters we have. We can even still omit the optionals completely like before.

myFunction("Call me maybe", 12345);

Win-win for me!

So, what do you think? Maybe you have a better way to write optionals? Let us know!

Improve code readability with conditional safeguards

Moses Karunia — Tue, 15 Oct 2019 08:44:50 +0000

"You shall not pass!" - Gandalf the Grey, 2001

TL;DR

Define what your code supposed to do.
Write safeguards. One safeguard should define one specific condition.
Don't use else, if able.
Don't nest if, if able.

Conditional is one of basic fundamentals in programming. And the most basic of many kind of conditionals in programming, is if statement.

Writing an if statement is easy, but if we are not careful, it can easily leads to giant spaghetti code mess, hard to read and debug.

I think, there are (not limited to) two things can lead to messy codes:

Overnesting if statements
Unnecessary else statements

You might say, "Just write a comment to explain!"

Well, comments are great and can be helpful. But they should not be used to justify a messy code.

So this time, I'm going to share with you, about how I usually write my conditionals.

I don't know what the official name of it, LOL. But I think I first read it somewhere as SAFEGUARDING.

CASE STUDY

To do this, first, we need to determine what our function should do. To make it easier to explain, let's jump to code:

(Code is in Typescript)

Say we want to add a polymorph skill to our game. Therefore, we write this code:

export const polymorph = (caster: Person, target: Person) : Beast => {
  return new Beast(from: target);
}

Plain and simple. Now our target is polymorph-ed if we call the function.

But wait, not everyone should be able to cast polymorph! It will be broken if a knight is able to cast it.

So, let's safeguard it.

export const polymorph = (caster: Person, target: Person) : Beast => {
  try {
    if(caster.class !== 'WIZARD') {
      throw new Error('Only wizard can cast polymorph!');
    }

    return new Beast(from: target);
  } catch (error) {
      throw error;
  }
}

There you go! Now, only wizards can cast polymorph.

Hmm.

Btw, aren't wizards need 100 mana to cast polymorph? Well, let's add the mana cost to the logic.

export const polymorph = (caster: Person, target: Person) : Beast => {
  try {
    if(caster.class !== 'WIZARD' && caster.mana < 100) {

      if(caster.mana < 100) {
        throw new Error('Not enough mana!');
      }

      throw new Error('Only wizard can cast polymorph!');
    }

    return new Beast(from: target);
  } catch (error) {
      throw error;
  }
}

Umm. Nested if statement. Can we un-nest it?

export const polymorph = (caster: Person, target: Person) : Beast => {
  try {
    if(caster.class !== 'WIZARD') {
      throw new Error('Only wizard can cast polymorph!');
    }

    if(caster.mana < 100) {
      throw new Error('Not enough mana!');
    }

    return new Beast(from: target);
  } catch (error) {
      throw error;
  }
}

Ah nice.

I think it's better. Improved readability by separating each safeguard's concern.

Wait. How if our target is currently immune?

Alright, let's add the logic to our function.

export const polymorph = (caster: Person, target: Person) : Beast => {
  try {
    if(caster.class !== 'WIZARD') {
      throw new Error('Only wizard can cast polymorph!');
    }

    if(caster.mana < 100) {
      throw new Error('Not enough mana!');
    }

    if(target.isImmune) {
      throw new Error('Target is immune!');
    }

    return new Beast(from: target);
  } catch (error) {
      throw error;
  }
}

There you go, now polymorph can only cast by wizards, requires 100 mana, and cannot pierce immune targets.

And now, both of our players as well as the code maintainers are happy.

SUMMARY

Define what your code supposed to do. (It'll be better if we separate the concern of each functions)
Write safeguards. One safeguard should define one specific condition.
Don't use else, if able.
Don't nest if, if able.

CLOSING

What I really like about safeguard, is because it improve code readability and easier to define structured error messages.

It's like saying: "Ok, this is what the code should do. But, look at the safeguards! They prevents the code to function under wrong circumstances."

Oh, before anyone fire out their gun, I'm not against else statements. It's necessary sometimes. After all, it exists for a reason. But in some cases where we can omit it and improve code readability, why even bother to write it?

Less is more

NOTE

For you who don't know, throw-ing an error means stopping the function from continuing. It's similar like writing return;.