An Intro To Flutter

Share if the site was helpful

An Intro To Flutter

When Google I/O came and went in May one of the topics that captured a lot of interest was Flutter. Offering a whole new option for cross platform code, Flutter has been gaining traction over the past few years. I talked about it briefly a few weeks ago, but let’s dive more into the details of why it may be worth learning.

What is Flutter?

First, let’s get a quick primer of what Flutter actually is.  It’s a toolkit developed in 2017 by Google that allows you to write code for both Android and iOS devices.  You can write code once, and then implement it anywhere.  And by anywhere, I mean Android, iOS, web, and desktop.  Already if you’re a freelancer I’m sure you see some appeal here!

It’s written in Dart which hasn’t been too popular of a language in the past, but Flutter is breaking that trend.  It’s been featured at I/O for a few years straight now, and Google uses it for internal apps, so it’s not going away any time soon.  The framework revolves around widgets.  Everything in a Flutter app is a widget.  Widgets describe what a view should look like given its current state, and when that state changes a widget rebuilds its description.  It sounds kind of foreign until you dive in.

Let’s see some code!

I won’t waste time going through how to set up Flutter on your computer.  Here’s a good link to walk you through that (don’t worry it’s super simple).  For my personal use I’ve been using Flutter in Visual Studio Code, but you can also develop in other IDE’s such as Android Studio if you’re more comfortable with those. To get started run the command flutter create hello_world.  This will take care of everything for you creating a new application named hello_world.  To run it, type cd hello_worldto enter that directory, and then type flutter runto kick things off.

Congratulations!  You’re officially looking at your first flutter app. Whether you ran it on an iPhone or an Android device (or somewhere else) you should see an app that looks like this:

So what made this app? Well, this is from the default code that Flutter made for us.  In your navigation sidebar you should see folders for things such as android, ios, and lib.  There are some others as well, but I point these out because at its core you’ll work in the lib folder.  And the others will allow you to transport that code into iOS and Android phones. That’s REALLY oversimplifying it, but it’s not wrong!

main.dart:

Let’s open the lib folder, and inside we’ll see one file named main.dart.  This is the core of your app right now.  If you open up main.dart you’ll see what is creating the widgets currently showing on your phone.  For anyone just reading and not following along, here’s what it looks like:

In here we can see pretty hefty comments explaining everything.  The app starts by calling the method runApp() and passing in an instance of our class MyApp.  And as we can see right below that, MyApp is a StatelessWidget.  There are stateful and stateless widgets in Flutter, and we’ll go into them down the road, but for now just know what a widget is.

One really cool thing about Flutter is hot reloading.  When you want to rerun an app and see any changes you’ve made, you only have to recompile widgets that have changed their state.  The end result of this is incredibly fast reload speeds (milliseconds). Go ahead and try this out.  Under theprimarySwatchattribute change it from Colors.blue to Colors.red. Once you’ve done that save the project and in the terminal press “r”. Instantly you’ll see the theme of your app change from blue to red.  It’s really that simple to reload!

I’ve loved my experience thus far with Flutter because of the way it is structured and hot-reloading. There’s a whole world of development to explore, but if you get started and want to let us know what you like/dislike about it let us know in the comments below!

 

 

Google I/O Revisited

Share if the site was helpful

Google I/O Revisited

Last week we wrote about Google I/Ocoming to an end.  We highlighted some of the cool new features that were unveiled and explored upcoming technologies.  There was tons to show on stage, but of course it’s not magic.  Every tech innovation has logic working under the hood.  And as developer’s Google I/O is the perfect place to be to see how some of this logic works.

From A Developer’s POV:

First off, there’s a ton of other topics covered, but we’ll mainly be focusing on Android development in this post.  But don’t worry.  That still leaves us with tons of talking material!  Let’s start with the most fundamental topic of Android’s OS.  We saw Android Q up on the big stage at I/O, and with it are some new things that developers are going to need to consider when writing their code.

Permission changes are a big one.  An entire talk was dedicated to privacy changestaking place on Q, and immediately after it was another talk discussing location permission. In the past when you wanted access to a user’s location for your app you simple asked for it and they said yes or no. Q brings a 3rdoption into the mix.  It’s actually been around for a while on iOS devices, but starting on Q user’s will have two options to allow an app access to their location.  They can either say yes all the time, or they can grant permission only when an app is in use.  This way if there’s an app you don’t think should be tracking you when you’re not using it…well it won’t!

There were also sessions talking about new Q features such as gesture navigation and dark mode.  Yes, believe it or not Android is ditching the back button! Another iOS style move, but given time we may think it’s for the best.

New Ways to Develop:

The topic that has interested me the most since the end of I/O has been Flutter.  And if you haven’t heard of it before, here’s where to get started.  Flutter is an incredibly cool toolkit to help you write one codebase and run it on both iOS and Android apps.  Yep, write it once, ship it twice.  It was developed by Google in 2017 and since then the company has not stopped pushing it, so it doesn’t look like it’s about to fade away.  It allows for fast development, flexible UI’s and a new way of thinking while you code.

My favorite feature it the hot-reload.  Since you only have to compile changes you’ve made in the code, rerunning your app is insanely fast.  By insanely fast I mean less than a second.  This can allow for a whole new approach to coding as you constantly tweak minute things and hit run to instantly see how they change your app’s appearance.  Exploring it is a great way to learn.  I’ll be writing a post later this week in extensive detail on what Flutter has to offer because it’s so cool.

New Ways to Share:

From a developer’s standpoint there is more to life than just code.  You have to do something with the finished product, right?  There are people you need to share it with. Whether those are friends, work associates, or the world, the more options available to share your app the better.

We saw some cool things come in this realm at the talk “Customizable Delivery With the App Bundle and Easy Sharing of Test Builds”.  First, we saw how shrinking your app can dramatically increase the number of downloads that you get (1% increase for every 3MB your app sheds).  And with this we saw how to do just this by adopting App Bundles.

My favorite part of this talk though was about sharing test builds.  Taking things one step further than Alpha and Beta testing, you can now “upload” a build to the store and share the url with anyone you would like. The build is only accessible via that link though and doesn’t register as your regular app on the Play Store, so your secret is still safe if you’re doing internal testing.  Let’s say you want everyone at the office to give the new version a go before rubber stamping it.  This is designed for just that.

That’s a Wrap!

Wrapping up there were tons and tons of cool features from a development standpoint covered this year. And Google employees went over how to develop each one of them on stage in liver demos.  I would highly recommend checking out some of the footage if you haven’t yet.

What was your favorite part of Google I/O 2019?  Let us know in the comments below!

 

Starting the Reactive Journey

Share if the site was helpful

Starting the Reactive Journey

If you’re an Android developer, then odds are you’ve heard of RxJava.  It’s a popular library that utilizes the observer pattern.  Rx (ReactiveX) allows us to program reactively, meaning our code can be executed as events happen.  It’s tough to fully wrap your head around it at first, but once you get it your codebase can become more efficient and clean.

The Observer Pattern:

The Observer pattern (and RxJava) revolves around three key concepts.  The three O’s: observables, observers, and operators.  When combined these three allow us to emit information, modify it, and then react to it.  The best way to think about the observable pattern is to consider everything a stream. Data starts at the top of a stream and flows downhill.  On its way down things can happen to it to modify the data, and then at the bottom of the hill we use the data.

This is a high-level view of how the observer pattern works.  Think of observables as the top of the stream, operators changing the data on its way down, and observers as the bottom of the hill.  Ok, maybe this analogy will make a little more sense after you learn a little more about each of these O’s.

Observables:

An observable is something that can be observed.  It is something that emits data that we can react to.  A good example that already exists in Android is a button.  Whenever a button is pressed by the user it emits data. That data is basically just saying “I was pressed”, but it’s still data emitted from an observable!  What we do with that data is our option and none of the observable’s concern (think about the standard Android button; it just knows it was pressed, we write the logic for what it does).

So an observable is…literally something that is observable.  Real life examples could be a movie playing or a singer singing. These are things we could watch happen, but they don’t really impact us until we observe them.  Which brings us to the bottom of the stream.

Observers:

We’ll skip over operators right now and jump straight to observers because they are essential to this paradigm. So we have a movie playing already (the observable), and once we turn on the TV to watch it we have become the observer. The data (movie) is coming to us and we can react to it however we want.  Likewise, with an observer in Android we can write a function to react to the data an observable emits.

In the RxJava world observables don’t always have to emit just one piece of data, that’s the beauty of it.  They can emit thousands and thousands of pieces of data, and then observers can react to each and every piece of data if they see fit.  And just like multiple people can watch one tv, multiple observers can observe one observable.

Wrapping Up:

It’s a lot of “o” words I know, but the concept is pretty simple.  Observables emit data, observers react to it.  We’ll dive into plenty of code in part 2, so stay tuned for that as well as examples of how operators come into the mix!  RxJava takes a little while to get down, but once you do it’s too addictive to quit!

en English
X