Cross Platform Angular with Richard Sithole - AiA 425 - Adventures in Angular

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Speaker 1 (00:06):
Hey everybody, and welcome back to another episode of Adventures
in Angular. This week, I'm your host Charles max Wood,
and I'm here with Richard C.

Speaker 2 (00:15):
Torley. Richard, do you want to just say hello and
remind everybody who you are.

Speaker 3 (00:20):
Yes, thank you very much for having me again. Yeah.
So this is part two of our earlier episode that
we did a couple of weeks ago. My name is Richard.
I am a South African living in Berlin, Germany. Yes
i am. I'm part of a team working on a
ECM software we call an IOL. I like to tinkle

(00:46):
a logically a log with Angular projects. I love Angola.
I've been working on it for a couple of years now.
And yeah, I've also recently started writing about after I
discover along the way, and today would like shre some
of that with you guys.

Speaker 1 (01:02):
Yeah, and what we're talking about is you wrote an
article about how to write multiplatform apps in a single codebase,
which to me feels like a unicorn. And I told
you this before the episode, right, I mean, I remember
back when they first came out with Node right, and
then people were.

Speaker 2 (01:18):
Like, you can write one codebase and it'll work on
the front end and the back end, and that turned
out to be so not true.

Speaker 1 (01:25):
And then and then people were trying to make that
happen with media, and that also turned out to be
not true.

Speaker 2 (01:30):
Right, and then and then.

Speaker 1 (01:32):
People were like, oh, now we have electrons, so now
we can write desktop apps and web apps that are
exactly the same. And that turned out to be kind
of true, right, some of them can share, but not
all of it. But they were talking like, Oh, all
you have to do is kind of plug it electron
in and wow. And so yeah, I'm kind of curious
because it looks like it really works and just from

(01:53):
what I read on the article, So yeah, but before
we get into that, I'm kind of curious, like, what's
the story behind this?

Speaker 2 (01:59):
What know? Like, how did you get to writing this
article in particular?

Speaker 3 (02:04):
Well, first of all, I think I've mentioned this in
the past that always just spend your time and some
of the things that you enjoyed doing the most right,
And when it comes to writing an article, I think
one of the things or topics that you can write
about basically things that you work with on a daily basis.

(02:25):
So coincidentally, this topic that we're discussing today is something
that I do on my day to day job, which
is writing software for cross platforms. So we're talking about
a web app. We've got iOS, we've got Android and
as well as desk stop. But yeah, I think the
idea was speculating in my mind for a while now

(02:48):
and then eventually I just had to jump in and
just do it. And the very interesting stuff that I
discovered about myself during this process was that, you know,
I basically after I wrote the article, I looked at
it and I was like wow, and seeing the feedback
and analytics from the people that are reading it, you know,

(03:08):
I affirmed one thing that you know, I treasure or
I appreciate simplicity, which can be very hard to achieve,
especially in the field of software development, but very important
to strive for right as makes maintaining software much easier
in the long run. But yeah, I think one of
the favorite things that I really enjoyed in this process

(03:31):
of writing was the brainstorm brainstorming phase. And you can
think about, I don't know, if you've written some thesis
or things like that at at university. It can be
hard and discouraging at first, but once you latch onto
something which is exciting, it can be routing, it can
be eroding experience. So yeah, I think one thing maybe

(03:54):
I can mention for people that are thinking about jumping
in just find the great well put it this way, Like,
the thing that I find exciting when I read articles
is that most intriguing articles have a common theme. For instance,
they are usually an easy read. Regardless of the length
of the article, you just don't want to stop reading it, right,

(04:17):
And some things that go into creating such quality content
is the structure of your article as well as focus.
Write about something that is focused on either a specific
technology that you're interested in, or at least something that
is solving a problem that most people are interested in.
And in this case, Chuck, you've a bit skeptical about

(04:40):
this cross platform stuff, but yeah, we hopefully we can
dispel some of your myths that you might have had
in the past. And I've also included a link to
show Notes in the show notes a great article that
I came across before writing my article, and it was
a good motivator. It also has some great tips on
how to get started and what to consider before you

(05:01):
get thoughted.

Speaker 1 (05:02):
I thought I hit the on mute and I didn't,
so yeah, I sound smarter on mute. So anyway, Yeah,
I mean it makes a ton of sense what you're
talking about here, especially just in the sense of, you know,
keeping it simple, keeping it focused, keeping these articles together
in a way that makes it easy for people to
figure out and flow. But yeah, like you said, I'm

(05:23):
really curious to see how this platform thing works, and
dive in a little bit on, Yeah, just how much
code sharing there is, because as I've said before, I've
tried writing apps that share code across stuff, and I
just haven't had the experience where I was able to
share a ton of my code, right, And so sometimes

(05:44):
it was worth it, right because I didn't have to
rewrite certain level layers of stuff, and sometimes it was
just you know, this would have been way easier just
to write from scratch. So I'm a little curious though,
before we dive in though, when you say cross platform,
what you mean is is that it works on the desktop,
MO and web.

Speaker 3 (06:01):
Right, That's pretty much it. Yes, I mean, if you
look at like the scholarly definition of it in computing specifically,
cross platform software means computer software that is implemented on
multiple computing platforms, right, which means it must be able
to function on more than one computer architecture or operating

(06:24):
system for example. However, in web in web deev, this
typically means that you develop a web app which is
then somehow translated into source code which is able to
run on many platforms, and in most cases that means
native devices as you mentioned, could be Windows, Mac Os, Linux,

(06:46):
as well as mobile platforms, the most common one obviously
being iOS and an Android. So basically, cross platform software
development is the practice of actively writing software that will
work on more than one platform. However, developing such a
such applications can be time consuming because of different operating systems,

(07:10):
because different operating systems have different APIs right for example,
Linux uses a different API for application software than Windows does,
for example. But of course there are many cross platform
programming toolkits and environments which help facilitate the process. I
can think of one top of my head, React Native,

(07:30):
for example. I was checking out their GitHub pages that
the other day, and there's a list of platforms that
they claim to support. They include things like TVs, Android, TV, wearables,
ties and so forth. So there's definitely some liaps and bounds.

(07:51):
Like this, technology has improved and continues to improve. But
for today's topic and for my own personal experience, I
think we're going to zone in a little bit on
electron JS. Yeah, but then there's also other toolkits that
you can use that basically focus on specific platform for example,
gaming platforms and so forth. But yeah, all of this

(08:13):
sounds very very good, but of course it doesn't come
It does come with its own challenges. For example, testing
cross platform applications may be considerably more complicated and tedious.
As well as that, you have to deal with UI conventions,
right you think of you io is this pinch and
gestures and all these other things that you need to consider,

(08:36):
But there's good tooling out there that allows you to
to handle that complexity.

Speaker 2 (08:42):
Yeah, that makes sense.

Speaker 1 (08:43):
I have to say that as far as the cross
platform stuff goes, the system that I am most familiar
with is React Native. I've written a couple of apps
with it. I really like it. Some of the React
conventions are a little bit strange to me, but I
mean it works, and there are a lot of toolkits
that will get you started. So anyway, Yeah, as far

(09:06):
as any of that goes that, you know, that makes sense.
But and I think that's part of where I'm kind
of coming at this and going, yeah, it's not as
seamless as.

Speaker 2 (09:14):
People make it sound.

Speaker 1 (09:15):
Because if if you've written a React web app and
then you've tried to translate it into a React native app,
I mean you're gonna have the especially the UI layer,
which is what React is good at, it just doesn't
translate well from the web to my phone, right, it's

(09:38):
the underlying logic and stuff like that. And even then
how you go and access stuff off the web isn't
one hundred percent the same. It's rather similar, but it's
not completely the same. I mean, you can go use
Apollo on both, right, and that looks the same. But
if you're just hitting RESTful routes and stuff, that's not
always one hundred percent seamless in the same way either.

(10:00):
And so yeah, that that's kind of where I'm coming
from with this. Before before we dive into how to
do this, I want to just ask one more why question,
and that is, or I guess, not necessarily a why,
but a when, because some developers are gonna, you know,
they're going to want this, right, They're going to want
an app that kind of runs everywhere. And some apps
are fine just working on the web, right, And so

(10:22):
what I'm wondering is is, at what point do you
feel like developers need to start looking at this and going, oh,
I need to care about this, I need to worry
about this. I need to go and actually make my
app cross platform.

Speaker 3 (10:34):
Yeah, yeah, absolutely, that's a that's a very good question.
I mean, it's like for me, it's like whenever I
come across new tech and and you and I know
that in our space, like that seems feels like it's
happening almost on a weekly basis, right, So why why
should I care? Why should developers care about this? Well,

(10:54):
in the case of cross platform for me personally, it's
it's it's two things. It's time and it's money. Effort.
You can throw in effort there as well. So the
first thing that comes to mind is like code reusability.
By writing just one code, develop devs can easily target
multiple platforms. That's in itself just saves you a lot

(11:16):
of time and effort. But in terms of how quick
you you turn out these apps. So so you can imagine
a team maybe I don't know, three or five developers
supporting all these platforms. Of course, if you are diving
specifically or in a specific technology. It will take time
and it will take skills and effort. So for me,

(11:39):
it's you know, the pace or the the pace of
how quick you can develop. That also is something that
I consider. And then the third the third thing is
how well do you know your market? Where is your
target market? And where are those people? Most people these
days is you know, you know they've got a hand
a cell phone, they're using their mobiles. They you know

(12:00):
less if they're sitting at the office in front of
a desktop or the laptop, then you know they're accessing
most of apps via the mobile devices. So there's definitely
that advantage of greater market reach. And again what I've
mentioned does cost effective. It costs you liss to develop
for all platforms using the same five guys or girls

(12:22):
on that one code base. So yeah, these are the
benefits that I've personally seen on the field as well
as at my place of work.

Speaker 2 (12:29):
Yeah, that makes sense to me.

Speaker 1 (12:31):
I mean, and I like that you brought up the
market because a lot of times as developers, you know,
we're we we kind of ignore that piece of life, right,
so we we kind of go, oh, well, when we
want to provide this extra functionality for our users or
something like that, right, instead of actually, yeah, talking to

(12:52):
our business people and saying, okay, have you evaluated the
market for whether or not people even want this on
the desktop or on the mobile phone. I think the
mobile phone's kind of a slam dunk in most cases,
just because, Yeah, if you look at your web traffic,
sixty percent or more is going to be coming from
phones anyway. So having an app and having some kind

(13:16):
of cause, let's face it, offline web functionality, it works,
but most people don't expect it to work, and so
they're if they're offline, they're not going to use their
browser to hit your app. Absolutely, but if you have
a mobile mobile app and it can cash some of
the stuff and then make requests when it gets back

(13:37):
on the internet, you know you're going to be way
better off. And so yeah, I can definitely see that absolutely.
So what do you need to do this then? I
mean you mentioned Electron does Electron as far as I know,
just as desktop apps, So you're pulling something else in
for mobile or.

Speaker 3 (13:53):
Yeah, are looking at it. Yeah, that's pretty much exactly.
You've hit the nail on the head. So yes, Electron
as it is today. What it gives you when you
included into your project is exactly that support for your desktops.
So we're talking mac os, Windows and Linux, and you'll

(14:13):
be surprised it's easier than you think. In fact, this
reminds me of electron jaslogan. It says if you can
build a website, you can build a desktop app. Sometimes
that might sound a little bit far fetched, sounds very marketee,
you know, it's good that kind of vibe. But yeah,
I think the best way is to basically just get

(14:35):
your toes with and just really dive into it. But
for those who some of the listeners that maybe not
away of or have played around with this technology, electron
is basically it's a framework that allows you the developer
to create desktop application using the same tech that you
already use for building web apps. So that is JavaScript,

(14:58):
HTML and CSS right these applications. Basically, once you've built
your app using the tech that I've just mentioned this
it allows you to package and run directly on desktop
on this platform sat I've mentioned mac o is, Windows
and Linux. But it's one thing you I think listeners

(15:19):
need to keep in minds so that typically you create
a desktop app for a specific operating system right right,
using that that always is specific native application framework, whatever
it may be. But however, the Electron makes it possible
to write your application once using the web technologies that
you already know. So for me, it's no it really

(15:41):
is no brainer, and it was pretty easy to really
jump in and get started with it. Just to right
now it just sounds still more on the appstract, but
just to give you an example of some of the
apps that we're built using this tech trans as so,
I'm sure a bunch of developer have used vs code, Microsoft, Facebook, Messenger, Slack,

(16:05):
MS team Switch. All those apps were built using this technology.
So if you're looking for enough proof to see how
complex can you build application using this tech, so you
can really go crazy at it, you know what I mean? Yeah, So, so, yeah,
you mentioned one interesting thing that so yes, Electron gives

(16:26):
you the desktop support, but what about mobile for that?

Speaker 1 (16:30):
Hang on, I got I got questions, I got questions.
Don't go ahead yet, all right, So one thing is
is that, I mean, how much glue code is there
for desktop right, because I mean I can't imagine you
just say NPM install Electron and you're done, right. I'm
guessing there's a little more set up than that, but
it sounds like it's pretty minimal. But yeah, I mean,

(16:53):
how much are we looking at there.

Speaker 3 (16:54):
In terms of LOCs line of code? H I it's
not that much, to be honest. That to get you started.
You the biggest or the main driver for getting kicking
off this whole process is a It's called the main
main script, so you can think of it as an

(17:16):
Electron application is basically a no JS app right at
its core. So so building an app with Electron is
like building a no JAS application with a web interface
or just building web pages which seamlessly integrate with no JAS,
so depending on how you look at it. But just
to get into the meat of it at a higher

(17:37):
level there, I won't go too much introdital how it
works under the hood, but the key thing to keep
in mind is that Electron works on three key pillars.
The first one is a chromium for displaying web content
right so at the end of the day, you basically
it's just a browser. It's just a browser just wrapped
around a fency desktop. The second one is no Jazz,

(18:01):
the actual library. This allows you to work with the
local file system and the operating system for your target platforms.
And then also it's for more sophisticated software applications and
you can also tap into their customer APIs that's for
working with as neat to functions. So yeah, it's that straightforward.

(18:23):
I wouldn't say it's simple because it also depends on
exactly what your end goal is.

Speaker 2 (18:29):
Right now, that makes sense, I mean I can imagine that.

Speaker 1 (18:33):
Yeah, you can get into some stuff that's fairly OS specific,
right you know, the Windows does this and Linux does
it different or doesn't do it at all, or vice versa.
I guess the thing that I'm kind of imagining though
at the same time, though, is if you're going to
build an application that has the same experience on mobile, desktop,
and Web, you're probably going to be coding to the

(18:54):
most common denominator on all those lowest common denominator and
all those things, which is going to be the Web actually,
as far as just capability reaching into your machine and
things like that, and so you're not going to need
a lot of that functionality if it's just a straight
up hey, this is the same app on all.

Speaker 3 (19:09):
Three Yeah, No, absolutely, that is definitely it's a good point.
It's something that you'll need to consider. But what I
love about this cross platform support, especially with Node excuse me,
with Electron, it does have some very good documentation, very
detailed documentation, so if you ever feel kind of lost,

(19:32):
they pull you right back out very quickly. But I mean,
so if you want to real so how do I
get this desktop platform support, Like, how do I get started?

Speaker 2 (19:42):
So?

Speaker 3 (19:42):
As I mentioned that Electron app is essentially an OJS app,
so naturally the first step is to install Node. This
consumes obviously that you already have a web app project
already set up, so you're just pulling in a library
into your existing web app. Ex step is like within
other node jas app, Electron app uses a or uses

(20:07):
the peggete jacent file as its main entry point. So
you would need to add a script which points to
that main JS file that I mentioned, which is basically
like your your entry point. You're the thing that kickstarts
everything else. This main script, let's call it main jazz,
basifies the entropoint of your Electron application that will run

(20:30):
in the what they call main process. So yes, Electron
introduces a few new concepts as well as terminology which
is not so common in web there that may may
not be a good thing, but you know, it's something
that you at least need to be to be aware of. Yeah,
but maybe if you're I can just maybe mention the

(20:53):
two main terminologies that you should always keep in mind,
like whenever you're developing an electron app. These are the
main things that you'll be thinking about almost throughout the
death process. The first one is called I've already mentioned
it is the main process which is responsible for creating

(21:13):
web pages, and if it does this by creating what
we call browser window instances. So each browser window instance
is basically running a web page, like a simple web page,
in its renderer process, which I'm going to tell you
exactly what it is just now. But the key thing
is that there's two processes. One is main, the other

(21:34):
one is called renderer the render processes. The render process,
on the other hand, it manages all the corresponding web pages.
So for example, if let's say one so a crash
in one render process does not affect other processes because
they are you can think of them as their own
little islands. So yeah, and then there's the one other

(21:57):
key aspect to it, which is I guess you deal
with this with any other application, which is the communication, right,
the communication side of things. Electron does that using what
they call IPC stands for inter process communication. The two
main things in that space is well, the first one

(22:20):
is called IPC main for the main process of course,
and IPC render for the render process. But I guess
we have a lot to cover today, so I won't
go into yeah, Kales, but just know that there's a
mechanism that allows you to communicate between these processes that
we've talked.

Speaker 1 (22:36):
About, right, Yeah, Yeah, I think we've kind of gone
as deep as we want to just for this, because yeah,
ultimately this is about just getting your cross platform app
together in one repo, and we can probably just go
deep on another episode and talk about Electron.

Speaker 3 (22:51):
There.

Speaker 1 (22:52):
One other thing that I'm curious about then, is as
we get into this and we have let's say we
have Electron all set up and it's working as expected,
not a tremendous extra amount of code that we have
to maintain in order to make it work, how do
we start adding mobile into this?

Speaker 3 (23:07):
Yeah, so that's so, yeah, that's a very good question. Naturally,
as we've mentioned that this, we've got that desktop support,
we've got the we've got the web app, right whatever
the technology of used. So now we're thinking i IS
and Android for integrating mobile platform support into your your workspace.

(23:30):
There are a couple of options out there as mentioned earlier,
the React Native and many others, but for today, I'm
going to focus on one specific one which is called
Capacitor Ionic from the Ionic boys and girls. Yeah, which
is an interesting project out of the Ionic team. I

(23:52):
personally enjoyed it's it's still enjoyed its simplicity and definitely,
you know, I think it's got some of the best
documentation out there. So what is this? What is capacity?
First of all, it is open source. So what it
does is it provides a native run time and an
API layer for for web applications. Right, So that's that's

(24:16):
also a loaded statement, but essentially it exposes the native
layer through an API in order for you to write
code ones to interact with the native mobile native platform.
This helps you create this cross platform io is Android
as well as p w as or progressive web apps,

(24:38):
and you can use any modern framework, whether it be view, React,
Angular or just plain old JavaScript. So so that is
what Capacitor is a high level to get started with it.
There's two ways to start.

Speaker 2 (24:53):
I'm just going to chime in here for a second
jump in jump in. Yeah, well, I know.

Speaker 1 (24:57):
I just want to clarify a couple of things. Some
folks might be familiar with Ionic having a originally been
built on Cordova, which is a patchy project which came
out of I can't remember. I think Adobe had owned
it at one point and then they turned it over to
a patchy foundation. Yeah, it was originally phone Gap. But

(25:18):
what happened is is the folks at Ionic kept running
into just some.

Speaker 2 (25:23):
Funky things with Cordova, you know, just in the way
that it worked. It didn't seems as natural to them,
and so they created their answer to that, which is Capacitor,
which does more or less the same thing, except it
provides a cleaner API and doesn't have some of the
cruft of basically what amounts to a much older project

(25:44):
in Phone Gap. So anyway, so that's what you're dealing with.
So if you're thinking, oh, well, what about Cordova, what
about this? What about that? That's essentially how that came about.
And anyway, it's a really interesting story. We should get
somebody on the show to talk about it, and I
know we've covered it on job script Jabber, I think.
But anyway, yeah, so that's that's pretty much that.

Speaker 1 (26:03):
But yeah it yeah, and they write the bridge code
from the native stuff, the native libraries on iOS and
Android over the JavaScript.

Speaker 2 (26:11):
You don't have to go do it yourself.

Speaker 3 (26:14):
Absolutely exactly. So in spirit, capacitor and Coudova are very similar, right, Yes,
they both manage a WebView and provide some structured way
of exposing this native functionality to web code. Right. However,
capacitor has a few key differences in its app development workflow.

(26:36):
Where in Couldova you use that conflict dot XML file
or some similar configuration to manage all your plug ins,
Capacitor you actually check in your excode and Android Studio
projects into source control as well as you also use
those specific platforms IDs when necessary of course, to do

(26:59):
some platform specific configure, running testing and that sort of thing. Yeah,
So configuration basically changes as changes are made by editing
the appropriate platform specific configuration files directly. So for example,
in Android, you'll be working with that Android manifest XML

(27:20):
I think it's called where else in exquode it will
be the info dot p Liss. So, yeah, that's it's
a good point that you made that they are very similar,
but Capacitor basically just simplifies it the whole process.

Speaker 1 (27:33):
Yeah yeah, So what does it take to get Capacitor
in there?

Speaker 3 (27:38):
Yeah, so there's two ways. There's a recommended way and
then not so recommended way.

Speaker 1 (27:48):
So you know, that reminds me of how do I
put it? It was back to the future, right where
they're like, we can either take you in the hard
way or the easy way, and then they whack them
over the head the easy way.

Speaker 3 (28:00):
Yeah, exactly, So it's kind of it's a scenario, right.
But so I'll start with a recommended way, which is
you can either add Capacitor to an existing project or
they're not so recommended way, which is studying just you know,
with a clean, fresh project. But Capacitor was designed primarily

(28:21):
to be dropped into an existing front end project. But yeah,
it also comes with a simple studying project structure if
you'd like to start a fresh So my personal recommendation
is exactly is how they recommend it, just having an
existing app and just drop it in there. And I'm
going to just take like one or two minutes to
explain how how straight for what it is to edit

(28:45):
to an existing project. So essentially you drop in a
capacitor into an existing project by running an NPM install package.
Right it's called So there's two parts. There's capacitors Cli
so it does like Angular cel ideas you know that
sort of things, writing scripts and so forth. And then
there's a core module which is you know, aptly named

(29:10):
capacitor Core and just by just dropping in, so after
you've done the NPM install, you just simply run NPX
kept in it that will initialize in an initialized capacitor
and then you'll install the native platforms you want to target.
And so in this case we're talking about iOS, So
simple script like NPX cap ad iOS for iOS and

(29:33):
then replace iOS with Android for Android and that's pretty
much it. You will have projects as I mentioned for
for Android, it will be Android specific code and bio
is the same thing. But the power of it is
that it gives you access to core native APIs, so

(29:53):
you know, you can immediately start working with the camera,
file system, haptics, geolocation or vcation, whatever that you want
to that you want to focus on. And you can
also extend with your own APIs if you want, but
that's essentially the the first step that you need to
get this whole process started.

Speaker 1 (30:14):
Awesome. So one other question that I have because Ionic
has been around in the Angular community for a really
long time and Capacitor is the technology that they created
and then moved over to. Right, So what I'm wondering
is is why not go with Ionic? Like what's the difference?

Speaker 3 (30:32):
Well, so, the so the Ionic team or Ionic specifically
still uses the and from what I've read that they
will continue to use and support cutover. However, the I
think that the idea is now to to move more
towards capacitor for obvious reasons they are I mean the

(30:54):
Ionic team, they would by moving towards capacitor basically it
allows them to control and multiple stacks. So this Capacitor,
which is you know, part of their project. There is
Ionic which is basically the UI how do you call it?
UI library for building web apps, and then there's stencil jas.
So by moving towards capacitor, this allows them to have

(31:18):
control over this stack. So for example, if something were
to let's say I introduces or has a breaking change.
For example, the guy the Ionic team is able to
jump in and make quick changes into capacitors API to
quickly support whatever breaking change was, so and with kept

(31:40):
with Cudova. On the other hand, it's it's an old project.
I think it was early two thousands if I'm not mistaken.
Just yeah, run about two thousand and eight or something
like that. They I think there's been some slow sort
of process in adopt in adulting or keeping up with
the native mobile native specific platforms. So I think the

(32:02):
whole idea is basically just to get closer to the
stack so that they're able to control that entire stack.
But in terms of differences, Chuck, as you ask, is
that capacitor does actually support most of Cordova's plug in ecosystem,
so it's not like you're really moving out. And also,

(32:23):
as I've mentioned, you have the opportunity to extend by
adding your own plug in. Capacitor has a very good
API for allowing you to do exactly that.

Speaker 1 (32:32):
Cool I'm gonna go brush up on my swift now nice.
So you just follow the instructions for pulling Capacitor into
an existing web app and you're after the races. One
of the thing that I've been considering is a lot
of the apps that I have, they how do I
put it?

Speaker 3 (32:50):
So?

Speaker 1 (32:51):
They rely on a back end, right, And in fact,
in a lot of the cases that I'm working in right,
a lot of the static assets are served up right
by that back end.

Speaker 2 (33:00):
Right. You know, I've been.

Speaker 1 (33:02):
A Ruby on Rails developer for sixteen years now and
I like using that as my back end.

Speaker 2 (33:09):
Right.

Speaker 1 (33:09):
So if I have like a Rails back end Angular
front end app, how does that affect something like this
for both the desktop and the mobile. I mean, can
I could just lift the front end and just go
that way?

Speaker 3 (33:25):
So you moving towards the architecture. Is that something that
you you're thinking about, right?

Speaker 1 (33:33):
Right, Let's say that I just have an Angular I
have it's all angle on the front end. I don't
want to get into like server side rendered Ruby stuff.
I think that's well beyond the scope of this. But
let's say that I have single page app on the
front end that's all written in Angular, but I have
a Rails API back end. My Angular code probably just

(33:56):
calls into my back end and may just use like
unqualified you are our paths instead of like a fall
with the protocol in the domain and the path. So
if if I have something like that, am I going
to have to go clean that up and say, hey,
you're actually going to go talk to my app dot
com slash whatever instead of just slash whatever.

Speaker 3 (34:16):
Well not necessarily, I think Yeah. Without knowing exactly the
architecture and you know, the the interface, the API, it'll
be very hard to say concretely. But you touched on
the that you give an example that you have, and
your Angler is basically your your framework of choice in

(34:37):
this instance. So in terms of cross platform app Angular
is basically the glue that's what binds it okay together. Right.
So angler not only so Angular not only provide tooling
which allows you to quickly build features like what you've
mentioned just now, but it also provides, in my opinion,

(34:58):
some of the great, great best practices for organizing your code. Right.
So to give a concrete example, this could be perhaps
a I don't know a selfie app or TikTok or whatever.
Actually I've never used TikTok, but you know I've seen
videos created with it. So let's say it's a video
sharing app.

Speaker 1 (35:16):
Right, Let's pass ourselves as school off a schooler than
we are.

Speaker 2 (35:20):
We use tiktac all the time, bro, exactly.

Speaker 3 (35:26):
Yeah. So let's say you want this app to run
on the web mobile devices, well at least the most
prominent ones, which is and read and eyeways, right, and
you also want this app to be installable in a
desktop application. So in the context of Angular, you first
you create an Angular app the standard way with engine

(35:48):
you and your app name or if you plan to
have multiple applications Angular applications, so you're thinking, I'm taking
mono repo kind of style architecture. You can use ang
NW or the app name, but passing the flag create
application falls That allows you. That allows you a web

(36:09):
space name to be different from the initial app name, right,
and it ensures that that all applications, subsequent applications or
libraries that you would add to that web space and
they all reside in the project subfold. Then add your
Angular applic applications using the ANGI generated app or application,

(36:31):
and then you pass in the app name based on
your project requirements. Of course, you select whichever option works
for you, but by default this gives you out of
the box support for the browser, because Angular is primarily
a web framework with extra powers. Of course, then you
develop your app using web technologies that you know and love,

(36:52):
but in the end you have a web app as
an a site. The charcter got to mention this, I'm
not sure if you've heard of this website called what
web Can Do dot today.

Speaker 2 (37:03):
I haven't heard of that one. Can I use a
whole bunch.

Speaker 3 (37:06):
But okay, I'll include it in the show notes. But
basically it shows you what kind of features the web
currently supports. So, for example, there's an image capture API
which allows you to control or allows you web application
to control the advanced settings of your devices camera to
think of zoom, wide balance, ISO, focused points, whatever, to

(37:31):
take photos based on those settings. And there's also another
one that I like, which is called Media Recorder API.
This one allows you to record audio and video stream media.

Speaker 2 (37:42):
Played with that one, yeah really, yeah, I'm an audio nerd.
I was like, oh, I could do.

Speaker 3 (37:47):
This on the web page. Nice exactly. So, like, the
web continues to advance, but there's not yet quite match
up to the native devices, and so that's where you
would use electron capacitor to ad support for those native platforms.

Speaker 1 (38:06):
So I guess we're kind of getting toward the end
of our time here.

Speaker 2 (38:12):
And the thing.

Speaker 1 (38:13):
That I'm wondering now is and I'm going to kind
of harken this back to something else that I talk
about a lot is testing. So testing is much easier
to get into your app and be doing it right
if you start from the beginning, right, you start testing
when you start your app, right, And I'm wondering if
that's the same case with this right the same with

(38:34):
like internationalization, there are a bunch of things, you know, accessibility,
all those things are easier to get in initially and
then just keep up on as opposed to maintaining or
trying to go in after the fact and go, we've
got to make this all accessible or we got to
make this all responses? Is that the same here where
it's easier if you pull all the architectures in at once,

(38:56):
or you know, if you're a ways down the road,
is not? Is it not so painful just to kind
of go, Okay, now we're going to make this desktop
app and it's a day or two and then you're.

Speaker 2 (39:06):
Like, oh, I'm done.

Speaker 3 (39:10):
Yeah, that's a good question. But I think for me,
I think you know, with any tech approach, with caution, right, yeah,
so you know, take baby steps. So, for instance, suppose,
like in your example, you have this large, medium to
large application which is primarily web based, or maybe you

(39:30):
already have a desktop and you want to pull in
now using the same code base to support for mobile.
So for me, I mean the first approach would be
to first try and pull in maybe one platform, so
maybe for the next I don't know, a couple of sprints.
You know you would do Android and focus on that.

(39:51):
So get the guys up and running or ramp up
to prepare for getting the the Android support into your
existing platform. Testing. Yeah, Chuck Coman, it can be hard,
but I think, as you mentioned, if you start testing
early on. So I'm talking about these early baby steps.

(40:12):
So the first thing that you introduce to the code base,
make sure that that is covered in terms of testing.
And by testing, I mean you can use whatever is
applicable for that specific platform. Cypress obviously end to end
testing as well as unit tests of course, but definitely

(40:32):
jump in and get that testing early on, so that
you know, as the application grows bigger and bigger and
you add more features, camera support, aptics and all those
other funky features we love, then you know that at
least your base is well covered.

Speaker 1 (40:50):
Yeah, So any advice for people who were kind of
starting this out on their own and starting a new.

Speaker 3 (40:57):
App, Yeah, I would say, do your research, plan out
your project. Use. I like to say that, like, use
the right tool for the right job. Just because you've
got a hammer, this I mean that you must, you know,
nail every hit, every nail on the you know, on
the world. Right, Just do your research and find out
what is the best tool for your specific situation. Then

(41:20):
you you're free to develop the next shiny app for
all the platforms for Max Memories.

Speaker 1 (41:24):
Yeah, it's funny because people I've heard this advice from
people before on different things.

Speaker 2 (41:30):
It's like, hey, you know, go do your research and
then make a plan. And then what happens is somebody's
gonna go, well, that's not agile.

Speaker 1 (41:37):
And I'm just gonna tell you if that was your reaction,
don't be dumb.

Speaker 2 (41:42):
Okay, I should be nice on this show.

Speaker 1 (41:44):
But what agile is is we gather what information we
can without it taking forever. Obviously you know this isn't
a delaying tactic, but go do your homework, go figure
out what you think it's gonna take, and kind of
have a plan in mind, angele is is, Oh, we've
been doing this for two weeks. This part of the
plan is garbage. It doesn't we were misinformed. We we

(42:06):
know more now than we did then, so you adapt
the plan. Okay, So I think this is really actually
a wise move. If you're not familiar with this kind
of an approach, Yeah, go do a little homework, spend
a day or so, kind of get your head around
what it's going to take, figure out how you want
to start approaching it. And then yeah, when you get
in and you go, oh okay, I struggled with this.

(42:28):
I went and looked it up. It turns out that
there's a new approach that works better than that.

Speaker 3 (42:32):
Absolutely absolutely. I couldn't have said a bit of myself.

Speaker 1 (42:36):
Yeah, so what about the folks that have, like we said,
a well established app there, it's out there, it's making money,
and they realize, you know what, some of our folks
want a desktop app?

Speaker 2 (42:47):
Right, what do you do then?

Speaker 3 (42:49):
Yeah? So in that case I would like for me obviously,
I can only you know, give advice on based on
something that I've worked on personality.

Speaker 1 (42:58):
So right, there are a lot of people who don't
know about is that I get it.

Speaker 2 (43:01):
It's called legacy code, folks.

Speaker 3 (43:03):
Yeah, oh, legacy code. That that is real. That is
so real, real. Yeah, absolutely, it's you are going to
especially if you're working on a large code base, there
will definitely be challenges. But again I would say just
do it, spike it out right to just give it
a try and give it maybe two weeks and say

(43:25):
we're just going to go for it. Just drop in electron,
do simple basic functionality first. You don't have to support
all the features immediately all at once, right, start off
with a couple of features and see how that works out.
But also keep an eye on the architecture. So if
you're using if you're one of the lucky ones using

(43:47):
Angular framework, as I mentioned, it's got great documentation on
the best practices on how to structure your code in
a smart way to help you grow with the app,
to help you maintain app in the long run.

Speaker 2 (44:01):
Yep. Absolutely, What do Angular upgrades look like on this?

Speaker 1 (44:06):
I mean, of course, I'm thinking of like upgrades from
like three to four to five that were a little
scarier than say eight to nine to ten to eleven, right, right, yes,
but yeah, imagining that, Yeah, somebody's on like Angular eight
and they're looking at okay, we want to get up
to Angular twelve's coming out soon. What are we looking

(44:27):
at there? Like, what are there any gotchas or is
it just hey, you know, it generally just works.

Speaker 3 (44:33):
It's it generally just works. But that's the short answer.
The long answer is that, I mean, if you look
at the history of the Angular upgrades, it's I can't
think of one where there was like a serious or
maybe Angler six or whether there was serious like changes,
like breaking changes. So from that perspective, I would say

(44:55):
it's fairly safe. But then again it depends on the complexity.
It depends on that legacy code that you're talking about.
For example, where we're working on a hybrid application. So
not only are we worried about upgrading to the next
Angular version, but then we also need to make sure
that englier jes code is still functioning, still running efficiently.

(45:18):
We still need to take care of the Angular X
side of things, which what we call it. We have
to take care of old plugins from the Cordova world.
We have to take care of desktop and its integration
to the Microsoft Windows world. There's a lot, right, but
it's something that you it gets better with time. But

(45:41):
again my advice is just start small and then slowly
build up to it.

Speaker 2 (45:45):
Yeah, makes sense.

Speaker 1 (45:46):
So I guess the last question is is and we
should probably ask this first, but besides Tetris, what have
you built with this? Very very very and I said
Tetris because if you go read the article that's what
watch it theories like, hey, here's a Tetras app and
we're going to make it run everywhere because I don't
waste enough time playing games.

Speaker 3 (46:07):
Right, exactly, God chack, that's a very good question. So
as if you remember what I mentioned right at the
beginning is that this is technology that I work with
on a daily basis. It's not the entire stack. So
instead of capacity we use it, we're still using cutover.
But in terms of what you can do with exactly

(46:30):
what we've discussed today is anything and everything, right, because
the support is there, the technology is getting better and better.
So on a practical level, I mean, we've our application
that I've mentioned earlier on it's called Anio. You can
download it from the app stores. It's extremely rich, a

(46:52):
feature reach feature reach. It's been I think, I don't know,
it could be about four years almost five years in
development so far, and we'll have all this complexity as
well that we deal with on a data basis, so
you know, take it from me, child, it's a safe
bet if we can manage it, you know, with all

(47:13):
this complexity. I think if you are looking at a
medium or smaller, smaller app and use, it's fairly newish
in terms of you don't have to support like a
lot of legacy code. There's literally this guy is a limit.
I think the technology is ripe for you to do
in basically any any kind of app. I mean, look

(47:35):
at vs code. That is an extremely featured application and
it uses the very same technologies we've discussed.

Speaker 2 (47:43):
Awesome.

Speaker 1 (47:43):
All right, Well, before we get to picks, do you
want to remind people where they can get in touch
with you? I'm assuming yeah, Facebook or sorry not Facebook.
I don't even know why I said Facebook because I
don't like Facebook. But Twitter and GitHub and places like that.

Speaker 3 (47:56):
Yeah, absolutely, I think the easiest one is Twitter at
slick rick s l i q r c oh nice.

Speaker 2 (48:05):
I like that one.

Speaker 1 (48:07):
Sometimes it's like it's my name, I mean that's basically
what mine is.

Speaker 2 (48:11):
So yeah, all right, well let's go ahead and do
some picks. Let's shout out about some stuff. I'm going
to start us off here.

Speaker 1 (48:17):
So I think on the last episode that we did
unless it got canceled because we had a couple.

Speaker 2 (48:23):
That have done that.

Speaker 1 (48:24):
So I went to this retreat in oh No, last
week I was still coming back. So yeah, this is
my first week back. So now I can pick all
the good stuff. All right, here goes. So I went
to this retreat. It was it was kind of a
mix between like a conference and a retreat. But there's
a men's group that I'm a part of that's got
guys all over the world, most of them are in

(48:45):
the US and anyway, there's a there's a bunch of
guys that I talk to every week that are part
of this group. And so yeah, so we had a
big get together in Nashville, Tennessee. Nashville is a great town.

Speaker 2 (48:57):
I really like it.

Speaker 1 (48:58):
But yeah, we got there and we just kind of
went really really deep on stuff, right. So we had
conversations about what we thought everybody was good at. We
had conversations about stuff that we feel like each of
us need to improve on. We just dove in on
like family stuff and personal stuff and business stuff and

(49:19):
oh man was so so good.

Speaker 2 (49:22):
And there were a couple of things that really came
out of it. One of them is we did.

Speaker 1 (49:27):
There was a lot of conversation about relationships and how
relationships matter, and that was just one big takeaway and
so I'm going to kind of shout out about that,
just relationships.

Speaker 2 (49:38):
Right when I got back, I actually called up a few.

Speaker 1 (49:41):
People that I hadn't talked to in about a year,
and you know, just hey, how's it going, how's life?
How are things? What can I do to help you out? Hey,
give me a call. Well, Like, one of the people
I called was one of the guys that organizes NGI
coomf right, and I'm just like, I'm like, look, if
you get in a inch right making Energie cof go off,

(50:03):
call me up right because they're local guys, right, So
it's like, you need a cord, you need you know, anything,
you know, just call me and I'll just bring it over, right,
you know kind of thing, right, But it's just great
to connect and just be like, hey, how's you know,
how's your family, how's your you know, how's your business,
how's your life?

Speaker 2 (50:21):
How's And Yeah, I feel like I've been able to
offer some.

Speaker 1 (50:24):
Support for the folks that are out there and part
of the community, and so I really kind of took
away from that, and I'm actually setting up this is
the other big takeaway, So these are more actionable things.
But one of the one of the things I took
away is I've been moving all of my processes and
stuff for the podcasts and for other things into Monday

(50:45):
dot Com.

Speaker 2 (50:46):
So I'm gonna pick Monday dot Com.

Speaker 1 (50:48):
I think I picked click Up dot com a while back,
but Monday Monday dot com. It they're they're They're kind
of the same thing, actually, but I'm finding that Monday
dot has a few more.

Speaker 2 (51:01):
Automation features that I really want.

Speaker 1 (51:03):
The main clincher for me, though, was that I met
there was a seventeen year old young man there who
had done this for a friend of mine, but he
had gone in and so this other friend of mine
he runs like a copywriting business, and so they write
emails and blog posts and stuff for other companies, right,
they just ghostwrite them, so nobody knows it's them, right

(51:25):
except for the business owner and anyone the business owner tells,
but he set up the whole process for them, and
so you know, I'm paying him a few hundred dollars
and he's setting the same thing up for me for
the podcast processes, and so at the end of the day,
it's going to be hey, you know, do this, now,
do this, now, do this, and it's going to automatically

(51:46):
inform people that they need to get it done. So yeah,
and it integrates with Zappier as well, so if somebody
schedules a new episode, then it will put it into
Monday and set everything up so the process can get run.
And so I'm super super happy with that. And so
Monday dot Com is one. The other one and this

(52:09):
is more out of so I've been doing the dev
Influencers Accelerator and I've got a couple of people now
who are releasing podcasts on a regular basis. One of
them's on Flutter, the other one's on Quasar, which is
built on VIEWJS. But they're like, okay, now what I'm like, well,
now you got to grow your show, right, And so
one of the best ways to grow your show is
actually to get on other podcasts, right because you don't

(52:32):
have to explain to people on who listen to other podcasts.
Here's how you get a podcast, right, you just tell
them where to get yours, right, and so you know,
you just make sure that the content's good so that
they'll go check it out, and then you make sure
that the content on yours is good so they keep coming.
So the tools that I use for that, I'm just
going to put those out there. One of them is LinkedIn,

(52:54):
and I pay for the LinkedIn. I can't remember what
it is, but it's just the pro level stuff so
I get a certain number of emails, so I can
send email or messages to people that aren't in my
network or who aren't my first level connections. But LinkedIn
is terrific for finding people who work for particular companies.
It's also really good for finding people who like If

(53:18):
somebody has a podcast or something, it's usually pretty easy
to identify them if you know their name, and most
people use their name when they talk on their show,
so it's not terribly hard. But yeah, so then once
I have once I found them on there, the trick
is is that if they're your first level contact in LinkedIn,
you can pull their email off of there because it'll
expose up to you. Right, they have figure you know them,

(53:40):
so you probably have their phone number or their email
or whatever they've exposed. But if you're not, and most
of the people that I'm reaching out to are not,
then I use a tool called hunter dot io, and
if you know what company they work for, or you
say you have the domain for their podcast, you just
punch that in there and then you put in their name.

(54:01):
And what I find is like ninety nine percent of
the time, it gives me a good email address for
the person I'm looking for so that I can reach
out to them, right, and I'm not spamming them or anything.
And there's a whole process for this, right, because you
don't want to just say come on your show, right,
And I kind of lay that out in the Influencers

(54:22):
Accelerator because they're I'm kind of building a course at
the same time. So when they asked me for stuff,
I record a video that walks them through it. But
what's interesting is, and I know I've been going on
for a long time, but this all ties together because
essentially then the process for the podcast interviews to get
on the other shows is I have my virtual assistant

(54:43):
to go out and find the podcast that I need
to be on. Right, So I just said, look, anything
related to code, I want to be on it, right,
And so she went and looked up Alixer, and then
she went looked up Bruby, and then she went and
looked up JavaScript, and then she looked up Angular and
she went, you're right. And so she just went down
the list and she did out all the hosts for
all the shows.

Speaker 3 (55:01):
Right.

Speaker 1 (55:01):
So now I have names of people I can go
look up on LinkedIn, get their email addresses off of
Hunter dot io. But all that process is now also
and this is something I've been doing on my own,
but that whole process is now automated in Monday, and
so when we start putting the podcasts in there and
putting the host's names in there, right then it'll say, okay,

(55:24):
well you put these people in as podcast hosts. Now
you need to go find their email address, their LinkedIn,
their Twitter, their Facebook, et cetera, so that I can
go and reach out to them. And then I've been
doing the outreach myself. And the reason is is because again,
like I said, if you just send them kind of
the form letter, hey can I come on your show?
That might work for some of these shows for me

(55:48):
because I'm so well established in the podcast space, but
it won't work for most people. And to be perfectly honest,
I don't want to form letter people. So I'm actually
personalizing it. And so if I have all this content
information for them, that I can personalize it. Right, So
I spend an extra two or three minutes. I go
look at their social media feeds, I go check out
what happened on their podcast. I guess I'm giving away

(56:09):
the process for getting yourself invited on a podcast, but
I go through the work, right, and then at the
end of the day, I send them an email and
just let them know, Hey, I saw that you're doing this.

Speaker 2 (56:19):
I really like this. You talked about this on your show.

Speaker 1 (56:22):
I think I have a relevant follow up topic, right,
and then I you know, and then what the other
thing I do is I say, Hey, I really liked
how you talked about this thing on your show.

Speaker 2 (56:33):
Do you want to come on mine?

Speaker 1 (56:34):
And by by kind of offering the reciprocal.

Speaker 2 (56:38):
Right, Hey do you want going to come on my show?

Speaker 3 (56:40):
Hey?

Speaker 1 (56:41):
Can I come on yours? My success rate's been pretty good,
so but the whole process is on Monday, the whole thing,
and so I just stick them in there and then
it's Okay, fill in the host, find the host contact, right,
And so it prompts my VA to do all that work.
Go do kind of the pre sales because it is
a same it's just I'm not getting money for it.

(57:02):
But do all the pre sales work, and then I
line up the sales call and make it happen. And
the thing is is they benefit from coming on my
show too. So anyway, if you have a process for
something and you want to automate, because some of the
automation is, hey, editor the files, the files are uploaded, right,
and then you know, it doesn't automate any of the

(57:24):
editing or anything like that, right. But then when he
when he's done editing, then he'll put the the link
in for the finished episode, right. And when he does that,
that triggers the next layer, right. And so there's manual
steps in there all the way along. But it lets
it lets my other person know, my production and publishing

(57:46):
person know. Okay, the you know, the the audio file
is done, and hey, I've got a summary written for
the show notes, so you know, boom, My next step
is to get this sucker scheduled for the day it's
supposed to go out.

Speaker 2 (58:01):
Wow, and so.

Speaker 1 (58:02):
Anyway, that's that's the way that that works, and it's
really really powerful and I'm really digging this on Monday.

Speaker 2 (58:08):
The other thing, though, is that when I was talking
through this with this kid.

Speaker 1 (58:12):
He he asked me a whole bunch of questions about
the process and what I want the process to be,
and so we actually built in some of the stuff
that my previous virtual assistant was doing that my current
one isn't, and that is like getting things scheduled for
social media and getting the notifications to go out to
our guests. So right you'd get an email that said, hey, Richard,

(58:33):
your episode's up right here, here's how you share it,
here's an easy way to do this, that and the other,
and it's just right, and so it makes the whole
thing just really really simple. So anyway, that's that's what
I'm working on and I'm really really enjoying that. So
definitely go check out Monday dot com. I'll put a
link to it in the show notes, and then I'm

(58:53):
also going to just yeah mention that I did put
up some episodes on relationships as bonus episodes on pretty
much all of the podcast feeds on dev chat, dot tv,
and I had like three of them on the dev
Influencers podcast, so you can go find those at dev
influencers dot com slash podcast.

Speaker 2 (59:10):
That's cool, all right, Richard, what are your picks?

Speaker 3 (59:12):
All right? Yeah? The first one, I've got a couple.
The first one is en Video Shield. I'm not sure
if you've had a chance to play around. It's a
it's a streaming console device, but it also you can
also play games when it comes with their keypad and
whatnot runs on. I think it's Android TV. But what

(59:36):
I love about it is myself and my kids. These guys,
I don't know when do they practice, but like there's
this one specific game that my little one just kicks
my behind all the time. Right, Like I'm not very
big on gaming, but yeah, they pretty good at it.

(59:56):
So n Video Shields, but also for the streaming capabilities
of the device itself, I think it's you know, it's
it's what I don't know, six years old now, but
I think it's still one of the best streaming devices
out there. So that is my first peak. The second
one is an article written by I called Sashko Stubailo.

(01:00:18):
I'm not sure if I'm pronouncing it correctly. But I
spoke about it earlier on and it's titled how to
write a great technical blog post. You can find it
on free code camp dot org. Yeah it's it's I
think it's well written, it sucks, succinct, and it basically
hits the point home. So check that out. The second one,

(01:00:40):
the third one is free code camp dot org. We
spoke a little bit about this the last time, Chuck,
if you remember, so we shout out to Quincy and
his team and the community at free code Camp. And
also the last, last but not least, is in depth
dot dev as well as the community. Max I think
is doing a great job, you know, giving the platform

(01:01:03):
to a lot of aspiring writers, myself included, and so forth.
Very very good community they so shout out to them.
And last one is I mentioned it earlier on What
Web Can Do dot today. That's the url. Check it out. Awesome.

Speaker 2 (01:01:20):
All right, Well thanks for coming Richard. This was awesome,
and yeah there's a ton of good picks there that
you threw out.

Speaker 1 (01:01:27):
Yeah, but yeah, let's go ahead and wrap it up
here and until next time, folks, Max out Peace

All Episodes

Cross Platform Angular with Richard Sithole - AiA 425

Episode Transcript

Popular Podcasts

CrimeLess: Hillbilly Heist

Crime Junkie

Stuff You Should Know

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Cross Platform Angular with Richard Sithole - AiA 425