December 26, 2022 • 45 mins
Azam and I discus some architectural ideas Azam has developed over the course of over a hundred sample codebases.
- Azam's blog
- Azam's article mentioned in the episode: Practical Mv Pattern Crud
- Azam's Udemy course: MV Design Pattern in iOS - Build SwiftUI Apps Apple's Way
- Azam on Twitter
Stream makes it easy for you to seamlessly integrate real-time experiences into your application. Check out their Swift tutorial to learn how you can get started adding video or in-app messaging to your apps!
Lead Software Developer
Learn best practices for being a great lead software developer.
Rate me on Apple Podcasts.
Send feedback on SpeakPipe
Or contact me on Mastodon: https://hachyderm.io/@appforce1
Support my podcast with a monthly subscription, it really helps.
My book: Being a Lead Software Developer
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Jeroen Leenarts (00:03):
Hi, and welcome to another special edition of on
podcast. I'm sitting here withSam sharp. And he's been on the
podcast before, close to one anda half year ago. And recently I
increased online if there weresome people interested to be on
the podcast. And as I'm actuallyraised his hand and indicated a
very good reason why he wants todo that. And the reason he wants
(00:27):
to be on the podcast, again, isto discuss some of his learnings
about Swift and swift UIdevelopment, because he claims
that he has created over 100prototypes in the last three
years, I think he said, andthat's quite an interesting
journey. So first of all,welcome back, Sam, how you doing
(00:48):
today?
Mohammad Azam (00:49):
Yeah, I'm doing great. Thanks for having me.
Jeroen Leenarts (00:51):
So you specifically mentioned that you
wanted to talk about yourlearning path into Swift and
swift UI over the past threeyears? Because people who do not
know you, they should look youup online, because you have some
wonderful material available forpeople who are interested in
learning more about Swift iOSand Swift UI development. What
(01:13):
am I missing here? What elseshould I share? Before we dive
Mohammad Azam (01:17):
in? Yeah, sure.
So I have a popular YouTubechannel close to like maybe
18,000 subscribers. I also have72,000 students on Udemy. And I
think it's like around 1012courses just on Swift UI. But I
believe the total courses areover 30, I believe, which are
covering swift UI, Firebasevapor, you know, a lot of
(01:40):
different stuff. So definitelycheck out the courses on the on
Udemy. Part. And definitelycheck out the latest courses
publishing out. But yeah, mainlya publish on Udemy and YouTube.
Jeroen Leenarts (01:55):
Yeah. And as always, I will make sure to link
everything in the show notes. Soby the end of the show, we'll
probably mention few of theselinks again, and but look at my
show notes. And I will make sureto list them there. Just to dive
in. You mentioned three years tome and over 100 prototypes. So
what's the what's the ideathere? Because you must have had
(02:18):
a reason to like reallyexperiment this much with code,
right?
Mohammad Azam (02:23):
Yeah, so most of the prototypes were actually
small projects that I was doingfor my Udemy courses. And I
recorded, I think, like 10, or15, or 10, or 12, at least,
courses just on Swift UI andpresentations. So most of them
were related to that. But onething that I started learning
(02:43):
is, and this is where it becomesa little bit more controversial,
which is good for I think mypodcast is, for last three years
since 2019 2021, whatever I wasusing, which everyone was using
MVVM design pattern. And I wasone of the biggest proponent of
MVVM. I wrote books on it spokeat different conferences,
(03:06):
articles, even courses on MVVM.
But after I do these apps, whenI started doing these apps, and
more and more apps, and the waythe app complexity was going,
the pattern was kind of likecoming in the way. So once I was
I think doing the MacOSapplications, I was like, Okay,
this doesn't seem right, thereis something wrong with what I'm
(03:28):
doing, or there's somethingwrong with serve UI, or how I'm
applying these patterns. So forthree years, I start doing or
start creating apps using MVVM.
And then after three years, I'mlike, this is not working out,
there's something wrong, like Icannot access the environment
object, I cannot access thefocus state, I cannot access
(03:50):
the, you know, gesture stateinside the view model. And it's
just a pain to pass thosedependency all the way down to
the child elements to the childviews. It's just a very much a
pain. And even if you pass thedependencies down to the child,
or children, then you're lost,like okay with who's maintaining
the dependency, because now it'slike all over the place. So I
(04:12):
went back to the drawing board,I started reading a little bit
more on how react works. And Ifound it interesting post
online, actually couple ofinteresting posts, that were
talking about the same thingthat I was experiencing. And
they were talking about how youshould not be using MVVM to
create some view application,because it's not a wrong
(04:33):
pattern, per se. But so if UI isalready a pattern, you should
not wrap it around with anotherpattern. And that's I found it
very interesting. And instead oflike telling that person whoever
posted like you're wrong, andyou don't even know what you're
talking about, instead of that Itried to communicate with and I
tried to contact that person.
And we started talking onTwitter and he was sharing some
(04:53):
ideas. I shared my ideas and wecame to the conclusion along
with some other people is thatit's just not, at least for our
apps clients or web application,at least, it was not making
sense to use MVVM to wrap ourwhole, you know, Swift UI with
MVVM framework or MVVM designpattern. And we in the end, we
(05:16):
found out that serve UI isalready a pattern. Instead of
wrapping it with other stuff, weshould just use how Apple is
trying to tell us how to use it,which is in their code examples.
Now, this is not to say that,okay, you should go back and
take out all the MVVM stuff andreplace it with a different
(05:36):
pattern. Now, if your app isworking out, you should just
keep it because there is alwaysa learning curve on new patterns
or new techniques. So I wouldjust keep it that way. Just look
at different experiment thatother people are doing, maybe
you will like those things. Soat that point, yeah, they will
only like few peoples in thecommunity, maybe a handful of
(05:58):
half a dozen that were talkingthat were saying that there is
something that we are missing.
And I will also eventuallybecome part of that one, and
kind of admit that I was doingit wrong, for close to three
years, especially for clientserver based applications. And
(06:18):
what we learn from watching thevideos watching how React is
doing stuff, is what I learnedis the view itself has the
capability of binding. So itdoesn't really need any help
from a separate view model file.
So we went back, I mean, I wentback to WPF, Windows
(06:39):
Presentation Foundation, whichwas in Microsoft, and I looked
at how Microsoft was doingthings because this is where the
MVVM pattern, you know, evolved.
And in WPF application, we hadzamel file and the C sharp file
and they were like gonna likelink together, whatever you type
in the zamel file, it will bebinded to the C sharp file,
(07:01):
which contains the view model.
But in our Swift UI, the viewconsists of all those property
wrappers like state and all thatstuff. So it doesn't really need
any help from a separate viewmodel. So we start looking into
this pattern and more, Iexperimented with it and started
converting my apps, the more itbecome very clear that this is
(07:21):
the way that Apple wants you todo this stuff, you don't really
need a view model for everysingle screen that you're going
to be building. The view has thecapability of binding, so why
not just use the view itself. Soa very quick example can be if
you're building something like alogin view, which contains a
user name, textbox and apassword textbox. If I'm using
(07:44):
the MVVM pattern, I will startwith login view model. Well, I
don't really need a login viewmodel. I mean, the login view
can contain two state propertyrecords, one for the username,
one for the password. And that'sit done. And you can validate
inside the view, the validationis just checking that you put
the username, and you put somesort of a password. But that's
(08:07):
pretty much it. That's notbusiness logic. That's just
basic UI validation. And I wrotean article on it, it was a very
initial article where I guess Ididn't do a good job of
explaining this kind of not anew pattern, but what Apple is
recommending or what Apple isdoing. And people were like, Oh,
you mean, like put everythinginside the view? I'm like, no,
(08:30):
no, no, that doesn't make anysense. No, you should not put
everything inside of view, youjust don't create a view model,
what you do is you create what Ilike to call an aggregate model,
meaning just one model for theapp for a small app, you just
need one model. And your viewwill communicate to that model.
(08:50):
And that model will communicateto the web service, the web
service will communicate to theserver, get back the data, and
it will pass through thefailures backwards. So that is
the architecture that I'm using,at least for my applications.
And it's actually turning out tobe really good, I can take
advantages of the environmentobject, I don't have to pass any
dependencies. I can use focus,there's just a state environment
(09:14):
values, whatever I need, I canjust do it inside the view. So
that was definitely a turningpoint for me to to create myself
UI abs in a very different way.
Jeroen Leenarts (09:27):
But but it isn't in a way making sure that
the data that is being handledin your app, really at the
center of everything that you'redoing right because the view
hierarchy manipulates this thismodel of data that you have that
is at the core of yourapplication, but then at some
point this this data needs to betransacted upon. So either it
(09:49):
needs to be transformed intosomething else or it has to be
sent off to a network locationto be handled there. So is it
like a Also that not only fromthe few hierarchy side, but also
from the networking sites andother areas within the logic of
your app that you try to workwith this data in a more
(10:11):
reactive way, or how are youlooking at this.
Mohammad Azam (10:15):
So I'm just looking at it in in mostly in
your simple applications, yourdesign will be or your
architecture will be in basic,like simple applications, your
view, will communicate withsomething called an aggregate
model, you can call it facade ifyou want, if that helps. And
that aggregate model will beresponsible for providing the
(10:37):
viewer with all the data itneeds. So let's say that view
needs the list of products. Sothat particular aggregate model
is going to use a web servicelayer to get all the data and
then just hand it over to theview using published properties.
Now, if you have a muchcomplicated application, much
bigger application than onemodel, one aggregate model is
(10:59):
not going to do the trick.
Because you might be dealingwith a catalog for E commerce,
you might be dealing with, youknow, inventory fulfillment. So
you can create multiple of thesefacade or aggregate models. And
those will be responsible forwhatever they want to do in that
particular domain, in thatbounded context. So a catalog,
(11:19):
aggregate model can return you alist of product, product items,
categories, but the fulfillmentwill be related to dealing all
the operation related tofulfillment, whatever that
domain does. So in the end, it'ssimilar to the MVVM. But we
removed the requirement tocreate a view model per every
(11:40):
view, that makes it simpler.
Jeroen Leenarts (11:46):
Yeah, because you're basically relying on the
binding behavior fromstraightaway into your model to
make sure that all the data getswell taken out of the model and
pushed back into the model. Andyou and is there like, is it
more like a technical reasonthat you choose, at some point
(12:09):
to split the models intoseparate aggregate models? Or is
that something that is morerelated to how you, as a
software developer, then candeal with a lower cognitive load
when working with this data?
Mohammad Azam (12:26):
Yeah, I think my theory is that, for simple
applications, you will only needone aggregate model, you can
even call it model, that's finewith a capital M. Yeah. And that
will provide you all the datayou need with like different,
different structs. So there'llbe one struct for product and
category and category items, andsorting behaviors, and filtering
(12:49):
behavior, all of that stuff, allof that implementation can go
inside that particular model.
But as your business needsevolve, and now you need to keep
track of, well, I need to docatalog, I need to do inventory,
I need to do fulfillment, thenyou start adding different
aggregate model or facades,whichever one you want. And
those will be responsible forgiving you different kinds of
(13:10):
model data that will bedisplayed and manipulated on the
screen. Now, from the viewperspective, for simple screens,
which only have few text boxes,three, four, even five, the view
itself can populate those textboxes in just a state variable,
and then pass it down to themodel. That's perfectly fine.
(13:33):
Now, if you have 10, or 20different fields, maybe you're
creating a page or a view, whichis responsible for driver
license registration, which is along page or long view, with a
lot of fields, maybe at thatpoint, it's a good idea to
create a separate struct, whichis responsible for holding that
data. So you don't have like 30fields 30 state variables, in a
(13:55):
one view, you have thatseparated out into one or
multiple, different structs,which you can say it's a view
model, that's fine.
Jeroen Leenarts (14:09):
But in your way of working these aggregate
models, they're not just data,right? They they also do other
things with the day to daymassage the data in a way that
it's like sorted or the orworked upon, so are filtered for
example, yes. Would you then onthis aggregate model also have
(14:30):
logic that actually initiates athing like a network call to a
web service or an end to webservice handling and error
handling and all the details andminutiae of that is basically
handled in probably some serviceobject?
Mohammad Azam (14:44):
Yes, yeah. So the aggregate model is responsible
for providing you the data interms of those struck models
like product category, usercustomer, whatever accounts to
those small models, by anaggregate model is also
response. trouble for initiatingthe call to the web service or
call to the network by using thenetwork service layer. So it's
(15:07):
not going to do it on its own.
It's going to ask the networkservice layer or the HTTP client
layer, that hey, can you give meall the products and then the
service layer, the networkservice later is going to fetch
all the products and assign itto a, basically a products,
property or public property onthat particular aggregate model.
And then it will be obviouslyautomatically refreshed, the
(15:29):
view will display it.
Jeroen Leenarts (15:33):
Yeah. Yeah. And then I can imagine that if you,
for instance, try and get a listof orders from your back end,
that you then on your aggregatemodel, have a function called
fall, let's just call it getorders, right? Yes, you just
(15:54):
want to fetch those, or maybefetch orders, whatever works for
you. But it sounds to me likethen the the aggregate model is
a really nice place to branchoff work on a separate track,
right. So that you have I thinkyou can really use async await
(16:15):
at that level there to make surethat you do something in the
user interface, the userinterface does not get blocked.
But once the data callbacks,it's it's populated in your
model. And because you'rebinding to the list of orders,
in your model, the view updates.
Mohammad Azam (16:30):
Oh, absolutely, yeah, so most of the functions
in my aggregate model, likefetch products, get products, or
whatever, they are asyncfunctions. And obviously, the
function in the web serviceitself, they are also async,
because that's where I will usethe URL session, dot shared or
whatever, to make the call. Sothat kind of helps to put all
(16:54):
the data in one central placefor small apps, at least. So
that you know, exactly, youknow, where the data is, what is
the state of the data. And it'ssometimes that in most of the
time, at least, for me, it's Ican just inject the aggregate
model object in the environmentvariable environment object, so
(17:14):
that it is available in the viewthat I injected plus all the
children. So then I can simplyuse the environment object to
get the actual data out anddisplayed on the screen. So it's
much easier for me.
Jeroen Leenarts (17:28):
Yeah, but but you will have the situation that
the aggregate model is sort oflike a pass through thing for
operations that reach out intothe network, right. But what if
you have some form of cachinggoing on. And it's not a typical
low level URL caching, but it'sa higher level caching? Is that
(17:49):
something that you wouldimplement in the in the surface
layer or in the aggregate modellayer, then
Mohammad Azam (17:54):
you have a choice, I think, in those cases,
I would just create a differentlayer for caching, and then use
that layer inside the aggregatemodel. So that if it's available
in the cache is returned fromthe cache don't even bother the
web service layer. And if it'snot available in the cache, or
maybe the time has expired, thenyeah, go ahead and get this
latest stuff from the cache.
Jeroen Leenarts (18:14):
Yeah. And it sounds to me that this very
straightforward layering thatyou put in your application,
because basically, you have asurface layer that does like
networking, asynchronous file,io, whatever. Then there's like
a model layer. And then there'sa few layers. So it's basically
a three layer system. And what'sthe furthest in complexity and
(18:35):
size that you have taken thisidea?
Mohammad Azam (18:39):
I've created some apps that had multiple aggregate
models. One is like an Ecommerce application kind of
scenario. But one of the peoplethat I was talking to the while
they're using a very similarmodel is called Well, little bit
simpler than using like anactive record pattern for their
approach. And they're creating afull fledge application with
(19:02):
like six to eight people workingon it. But for my case I work
with are converted basically allthe application that I was doing
before, and it was much easierto use, because I was not
dealing with like 30 differentview models. I just have where,
like, one or two view models ifI need to. But for me, I think
(19:23):
it was like two or threeaggregate models. I think that
was where I was working with.
Jeroen Leenarts (19:27):
Yeah. And but how does this work? When you
want to do some testing on youron your code? Because it seems
to me that the three layers arewell, quite tightly bound
together? Well, not not from notbottom up, but from top down.
There's a large dependency, ofcourse, between the deeper
layers within your app, right?
Mohammad Azam (19:47):
Yep. Yeah. So I wouldn't say I mean, tightly
bound or anything, but I thinkmost of the people who did
testing or one of the questionthey always ask me that, well,
how do I test it? Yeah, causewait The MVVM approach, I can
just go ahead and test it usingmy view model, I can just create
a instead of a view model, I cansay on whatever, like, increment
(20:10):
or whatever function I fire, andthen I can see that the view
model is getting populated ornot. Yeah, I don't believe that
Dota those tests are any useful.
I think. I mean, I've seen thosehundreds and 1000s of these
kinds of tests for view modelsand view controllers. But I
don't think they're testinganything. They're just testing
the implementation detailswithout testing the behavior
(20:31):
itself.
Jeroen Leenarts (20:34):
Yeah, I've seen tests that pretty much like
okay, I populate property and Iread property, yes, the same
value comes out. Wow, amazing.
Mohammad Azam (20:42):
And what these tests can actually doing is if
you're using the MVVM approach,or any approach, I mean, I don't
want to say MVVM is bad oranything. But if you're using
MVVM, model, or even the viewcontroller in UI kit, usually,
for these tests testing, whatyou do is you mock out the web
service layer, you mock it out,you say okay, I'm going to mock
(21:05):
it out, I own the web servicelayer, but I'm just going to
mock it out, I'm going to passit as a dependency, when the,
when this is called, then makesure that my view model property
gets changed. Well, if you'rewriting a test that is checking
for an expectation, on your viewmodel that a property of a view
model will get changed. That'sthe wrong test. Because that is
(21:27):
testing the implementationdetail, and not the behavior, if
you refactor your code andsimply change the name of the
property, and but the behaviorremains the same, your tested
start going to fail, which isincorrect, which shouldn't
happen. And these that's whythese kinds of tests are very,
very brittle test. Even if yourefactor your code, and the
(21:47):
behavior remains the same, thetest will start failing, which
is not a good idea. So now we goback to the customer, how do we
test them? Well, we test writinga real integration of end to end
test, like end to end test meansyour simulator is going to
launch you, the simulator or thetest, if you want to write
something in a text box, pressthe button, and then you're
(22:10):
going to check for the behavioragainst the real test server,
but not something that is mockedout. That is not saying that
mocking is bad in all thescenarios, but you shouldn't be
mocking heavily for things thatyou have access to, yes, if
there is a payment gateway, andevery time you access the
payment gateway, they charge,you should probably mark that
(22:31):
out or at Twitter framework,whatever, you don't have access
to that, you should do that. Butheavy mocking, which is being
advocated when you're testingyour view controllers and view
models that those tests are nota good return on your
investment.
Jeroen Leenarts (22:49):
But it does require a lot of control on the
deeper layers of yourarchitecture, right. And then
I'm talking about architectureof the entire stack, not just
the app, but also stuff that isbehind that, right. So you have
to have like a test environmentthat is somewhat stable, so that
if you run if two people run thesame test suite, at the same
(23:10):
time that they don't interferewith each other is that
complicated to achieve or thatthat
Mohammad Azam (23:15):
yeah, that's definitely one of the bad sides,
I guess of end to end testingthat there is the initial setup
that is required. If your serverif you're doing end to end
testing, then you will have tomake sure that your server is
performing all the migrations tocreate the database to create
the table, maybe add some seeddata, insert the data into the
(23:36):
tables that you are inserting,maybe you're adding a new
customer, verify it, and thendelete the data, because you
can't really read a live data inthe database, because it will
fail the next or the futuretest. So that will require a
little bit of quite a bit of asetup one time hopefully one
time setup. And, and then again,they are slow also, so end to
(23:59):
end test is not answer toeverything, because they are
also slow. But they are slow,because they are end to end. You
know, I mean, they check all thelayers. So you may not run them
every single time you check inthe code. But then you will have
to decide when to run themfrequently, but not as
frequently. So to slow you down.
Jeroen Leenarts (24:18):
Yeah. Yeah. So So probably you need some sort
of smaller units testing stillto test certain aspects of your
tech stack. Because because youdon't want to run the
integration tests like everyminute. Because yeah, probably
the integration test takes alittle bit longer than a single
minute. But is this integrationtesting? Is this something that
(24:42):
is typically done on thedevelopers machine? Or is it
more done on CI? And that isautomatically done when you push
your code to a central gitrepository or what's the what's
your thought process there?
Because I can just imagine thatif you have like a good group
people developing your backends,there's a good chance that they
(25:02):
actually are doing that in somesort of containerized way, and
that you can most likely run theentire tech stack, or at least
the critical parts of the techstack that you need in in the
local Docker environment. Forexample,
Mohammad Azam (25:15):
yes, yes, for end to end testing, which covers
like the whole layer ofeverything that should be
learned run under very fast CIserver, continuous integration
server, because the it will takea lot of time, depending on how
many tests you have. Now, ifyou're building a client server
application, where Sophie Why isobviously the client, and server
can be in whatever doesn'tmatter node or Express js, then
(25:40):
100 to a 99.9% of the time, youractual logic of the application,
the domain will be living on theserver, meaning on the
JavaScript side on the nodeside, or SP dotnet, Ruby on
Rails, whatever. So that has tobe tested thoroughly like like
really, really well. Kind oflike if you're building a bank,
system finance system, you musttest out your server can deposit
(26:04):
the money into the bank,withdraw the money, transfer the
money, and if there is ainsufficient funds, then make
sure that you charge overdraftfee because that's like, that's
that's the money in the bank.
Basically, there's like a $2billion difference for these
banks sometime $5 billionbusiness. So those are the
moneymakers. So that core, orthe domain has to be tested
(26:25):
thoroughly with unit tests likeplain ol unit test on the
server. And then we willobviously if you're exposing
your API to someone else, thenthe public API needs to be
tested thoroughly usingintegration tests or unit tests,
whatever. And then the wholesystem, all the layers have to
be tested. And usually end toend test tests are usually run
(26:47):
on CI server because they areslow in the end.
Jeroen Leenarts (26:52):
Yeah. And but I can imagine that if you really
step back and accept thatcertain aspects of an app that
you're building is pretty much aJSON based rest surface browser,
because that's what many appsactually in fact are. You can
make a distinction in your codebase that if it's really like,
(27:15):
okay, calling web services anddealing with the results of
that, that you then accept thatthe testing that you do as an
app developer, it is more on theintegration level. And if
there's other logic within yourapp that is, well, less bounce
to the web serves as more logicand self standing on its own,
that you then in fact, do ourwork more on the end to end
(27:40):
testing of that logic. But ofcourse, if you look at an
integration test that you wouldneed to do on such a piece of
code, for instance, you need todo some processing on an image
or whatever. That is somethingthat you can test end to end as
well. But that's just because ofthe fact that the end results of
your test. They don't leave thesystem, or at least they you can
(28:01):
test in a state that you don'thave to have network interaction
at that point. But you stillhave a meaningful test going on?
Because yes, there's actuallogic, actual complexity being
processed on some inputs, thatshould present a certain output,
right?
Mohammad Azam (28:15):
Yeah, yeah, I think if, if our app is simply
which most of the soap UI appsare simply consuming the actual
data from JSON service, and thenobviously, the server people or
whatever, they're gonna test theserver side and the public
API's. But as a soap UIdeveloper, I will be definitely
be more focused on end to endtests writing and consuming or
(28:39):
integration tests. In this case,I guess, yeah, integration
tests, checking that my client,the behavior that I'm trying to
achieve is tested through myswift UI app launching,
simulating those events,filtering the options, and
although thing against the reallife test server, definitely
that will be much helpful.
Jeroen Leenarts (29:01):
And what kinds of techniques or frameworks or
things would you suggest? Or areyou actually using yourself in
these integration tests, I canimagine some UI automation. I
can imagine some scripting toinfluence the back end, or maybe
even have a dedicated commandline client for the back end
(29:21):
that you can call from yourtests, right?
Mohammad Azam (29:25):
Yeah, for my integration tests, and since
most of my end to end tests,they're most of them are related
to node and express because myserver on the safe side, I'm
using just a basic x unit, orXC, like a UI test framework
that they have the building. Andyou can change the
configuration. I mean, you canwrite some code to check if it's
(29:48):
running on UI tests and you thetest server routes or URL, but
you can also make those buildconfigurations and simply the
whole configuration will bedepending on whatever the build
target that you select, so youcan have like a lot of variables
in there in the built in thebuild file. From the server,
yes, server becomes a little bitmore complicated when you do end
(30:10):
to end because now you have tocreate the database, you have to
do the migrations you things, ifyou're using SQLite, or which
whichever database or techniquethat you're using, and that will
reside on kind of like on theserver side to do all of those
things. So that is where thecomplexity comes into play. And
that is where it takes a lot oftime to drop those database,
(30:33):
build it up, again, for everysingle test. And I think that's
where the slowness comes intoplay. Also, I think, in the end,
for me, it's most more aboutsince all the tests are not
equal, like one test, theydepending on what kind of apps
(30:54):
that we're building the test fordepositing money and withdrawing
money and charging the userwithdraw, I mean, the penalty or
whatever, for insufficientfunds, those kinds of things
will be more important to me, ormore must be because they
actually create revenue for thecompany. But we find creating a
find have created a loggingengine, which are logging
(31:17):
framework that will log when youlog in and log out, it will be
kind of like at the bottom of mylist because okay, it didn't log
whatever. I'll get to that whenI will get to it. Because, you
know, I mean, that can betested, but it's not as a high
priority.
Jeroen Leenarts (31:33):
Yeah. So yeah, because I'm thinking about if
people want to learn more aboutthis approach, I know you wrote
an article on this. And it's, Ithink you wrote that in October,
if I'm correct, a few monthsago. But have you already been
able to create some, some somemore information about that,
(31:57):
because the initial article thatyou wrote about it is, is really
like just dropping down theidea? And probably getting some
responses and communication andsome discussions going on that.
So but that's the initiation ofthe concept and the idea, but
where are you at now withexploring this idea in this
concept? And is it alreadysomething that you feel that has
(32:20):
enough proof in your mind thatit is it is usable? An actual
sound way to go about setting upan app?
Mohammad Azam (32:29):
For me, it works.
I mean, that's all I can say.
And I think initially when Iposted the idea, and I'm just
checking, it was a few thirdcouple of months ago. The latest
article on that is, I'm not surethe date I think it was in
October 6 2022 is the latestone, which was about which is
called swift UI architecture, acomplete guide to MVC pattern
(32:52):
approach. And then I did also alittle bit more article on core
data, how you can embrace coredata with Swift UI, and how you
can evolve with Swift UIarchitecture for client server
apps. So I have been evolving itin terms of core data and client
server apps. But I think ifsomebody has to read this
article, I would definitelycheck out the Swift UI
(33:14):
architecture, complete guide toMVC pattern that's most updated,
I think, our article.
Jeroen Leenarts (33:20):
Yeah. And, of course, view being you. There's
probably also a Udemy courseabout that, where you explore
this concepts a lot more, right?
Mohammad Azam (33:30):
Yes, there is a Udemy course that I published, I
think, this year, and it'scalled MVC design pattern. And
iOS builds a few apps applesway. So after talking to a lot
of people and getting intoissues with MVVM, I went back
and watch all the videos of surfUI, and try to bother like,
(33:53):
very, very slowly try to see allthe code that they're writing,
definitely check out their codefor the food truck application.
That is, I mean, that's a decentsize app. I mean, somebody can
say, well, it's gonna work on asmall app, but it's not going to
work on larger well definedlarge. So that argument, that
argument in itself is selfdefeating, because they cannot
(34:15):
define large what's the Lord'sapp 2 million? Well, how about
if I work with 10 million linesof code for me 2 million small,
there we go. With the largestrelative not absolute. So that's
another problem. So but yeah,
Jeroen Leenarts (34:28):
but you at the start of this conversation, you
we mentioned that? You did like100 prototypes. So these 100
prototypes. Can you again, tellme why. In your sound mind, did
you come up with the concept ofhey, let's create like a
gazillion prototypes and justsee where I end up? Because
(34:51):
there must have been someprocess to the madness, right?
Mohammad Azam (34:54):
Oh, yeah. So prototypes. I started creating
for my courses for sale. UI. Sowhen soap UI came out 2019, I
started working on my firstscores, which contains like, a
lot of different apps. Andsomewhat simple, somebody a bit
more complicated. So duringthose three years, I created
like hundreds and hundreds ofprototypes using Firebase using
(35:17):
core data using just a few I,using realm, I mean, so many
different frameworks I had touse. And initially, I was using
MVVM pattern. And it was workingout but it was like, I had to
always have to like, Okay, Ineed to pass a dependency into a
dependency into a dependency,that I don't want to do that
anymore. So that is where I waslike, Okay, maybe I'm doing
(35:38):
something wrong over here.
Because then I started lookingat React also, because react and
so few, I pretty much the samething. React people are a little
bit more crazy than so fewpeople because we in React, they
have components and right insidethe component, they will make
the network request, just fine.
I mean, yeah, sure, if you thinkyour component is only going to
(36:01):
be displaying and not being usedsomewhere else, you can perform
the fetch request, which willbasically a network request, get
the data and display it on thescreen. I mean, that's fine. And
since you I also, I don't haveproblem with that, it's a little
bit too liberal for my tastes,at least, I mean, I would like
to have a little bit moreseparation. So that's why I have
(36:22):
that responsibility to theaggregate model or facade, which
calls the web service layer. SoI'm a little bit more future
proof if the app goes into muchbigger. So that is my view of
that.
Jeroen Leenarts (36:35):
Okay. So just to recap, you did like a lot of
experimentation. And then youcame to the conclusion that you
think, on a general level, whendeveloping swift UI code, we're
doing it wrong. And the doing itwrong, is that we just add a lot
of architectural complexitylayering, because most likely,
(37:01):
that's what we are used tocoming in from UI kits. And
that's also what we need it whendealing with UI kit to keep the
complexity in check. How do youfeel about having these
aggregate models and just makingthem available in the in the
environment of Swift UI? Becausesome people will immediately
(37:24):
say, Yeah, but that's likeyou're creating a global and in
some languages, some frameworksthat's, that's a bit of a no,
no. But what's what's yourstance about that in Swift UI,
Mohammad Azam (37:37):
so not every time I put it in that environment,
but most of the app I'm makingis, they have the capability to
edit or update and delete indifferent views. And it's easier
for me to have that available inthe environment, instead of
passing down as a bindingproperty. So sometimes I can use
state objects, sometimes I canuse observer object, but it
(37:58):
sometimes I mean, most of thetime, it makes sense for my apps
to because I'm creating, create,read, update, delete all the
operation, to put it inenvironment. Now environment is
not technically a global object,because it depends on where
you're injecting it. So you caninject it on the root. And it
will be available to the rootand all the child of the root.
And I think there's one very bigmisconception, which I also had
(38:23):
was about when that sort of UIrecreates your view re renders
your view, because I was underthe impression for a long time
that, Oh, you just put a selfdot print changes inside the
body property. And whenever thatfires, okay, all the view is
gone and recreated from scratch.
But that is actually not true atall. The body property, if you
(38:45):
put a self dot print changes, orhello world, something inside
there, the body property, whenit fires is only telling you
that the body is being evaluatedright now. It's not being
recreated. So Sofia is quitesmart. Because if something
change in your view, if you'reincrementing a counter, and
(39:08):
you're displaying a counted in atext field, but you also have a
text, sorry, a text view, andyou have a list and you have a
button and you have a pickerview and a segmented control,
blah, blah, blah. So if you'renot going to recreate all of
that stuff, because all of noneof that stuff is using the
counter value that just gotincremented it's only going to
update the text view becausethat's the only one chord
(39:29):
change. So during the evaluationprocess is going to make a diff
meaning differentiation betweenthe new tree and the old tree.
And it's going to find out thatoh, well, there's only one
control the TextView thatactually use the counter. So all
of these other five controls, Idon't have to recreate them. So
I think that's the good thing.
(39:51):
And that is what also happenedwith the environment. Just
because you put something in theenvironment does not mean here
the whole app is going torefresh and rebrand. Under, it's
only going to read under if thatparticular view is using the
property of or from theenvironment.
Jeroen Leenarts (40:06):
Yeah, yeah. And that's, that's there's a lot of
smart diffing going on in thebackground, to actually see what
has changed between the viewhierarchy as it is encode and
what is actually on screen. Andyou can trip it up. Sometimes it
does more than you would like,but then there are ways to get
(40:29):
around that. So but just to, towell to to start closing things
off a little bit. We alreadymentioned some of the articles
and some of the coursework thatyou did on the MVC design
pattern. And but what I'm alsocurious about is last time we
(40:50):
spoke on the podcast wassometime in the summer of 2021.
What has happened since then,what have you been doing? And
what are some of the successesthat you do you have in the
well, I think close to one and ahalf year already?
Mohammad Azam (41:08):
Yeah, I've been busy obviously teaching, that's
my full time job. I think I wasteaching my 13 or 1414 cohort
for for the company that I workfor digital crafts. And then
very busy in I think I publishedI published two small books, one
of the navigation API, and oneon UI kit with a few recipes.
(41:30):
Both are available for free.
During the holidays, you can getit for free completely. And I
also published an actualhardcopy book, which is about
the boot camp, which issurviving the coding boot camp.
It's a small book hardcopy plusebook also. So that contains a
lot of advice related to whichboot camp to attempt to enter
(41:50):
and what goes into boot camp,how to be a successful student,
because I've been teaching forsix years now. And doing like
some independent work on theside sometimes. But and yeah, of
course, a lot of courses Ideveloped like MVC design
pattern. The new course I justpublished, like maybe couple of
weeks ago was about UI kit,because they were people were
(42:13):
like, Hey, you forgot about you.
And Katie, you haven't talkedabout it for a long time. Um,
okay, here's the code for you UIkit with completely programmatic
approach. No storyboards, no,nothing. So, so yeah, definitely
fun.
Jeroen Leenarts (42:27):
Suggest just dabbling server, some old school
iOS development, just for justfor the heck of it,
Mohammad Azam (42:33):
just for the heck of it.
Jeroen Leenarts (42:35):
And as the iOS related teaching that you do on
the side, because your main jobis, is doing coursework for a
company, but you do the iOSstuff on the site is still doing
for you what you intend it to bedoing for you just create a
little bit of extra income foryou and your family to, you
(42:56):
know, just do the occasional funtrip every now and then. And are
some other extra expenses thatthat just make living. That
little bit more enjoyable foryou and your family.
Mohammad Azam (43:08):
Yeah, definitely.
I think it's just extra incomethat, you know, I like to
travel. So I usually dosometimes those trips for hiking
to Colorado or wherever. Andsome time I we just came back
from beautiful Mexico City, thewhole family vacation, or nice
couple of weeks, I think threeweeks ago or something. Yeah,
that was fun. And yeah, I'm, Iconsider myself a little bit of
(43:30):
a finance guy. So I do invest alittle bit of money on from that
into mutual funds. Very simplestuff. But yeah, it's been it's
been fun. And I think what thesecourts have allowed me to do is
to kind of like, take a stepback and think about those
things. Because I know that whenwe are on the clock, we have to
type some time, we're not reallythinking that much. But now, it
(43:51):
has allowed me to kind of likeslow down, think about things
and then write about it muchmore better than just completing
these tasks and all that stuff.
Jeroen Leenarts (44:03):
Okay, cool.
Sounds good. Seems you're stillin a in a very good place with
your work and how are youenjoying it and how you spending
your time? Where should peoplego look to find everything that
you do online?
Mohammad Azam (44:17):
The best way would be Twitter. You can follow
me at awesome sharp AZ am shERP. And yeah, if you follow me
on Twitter, you'll get to knowabout everything that I'm doing
because I am quite active. Yeah,that's the best way.
Jeroen Leenarts (44:33):
Okay. I will make sure to link that in the
show notes. And yeah, I think Ithink we covered what we wants
to cover in this conversation, Ithink.
Mohammad Azam (44:43):
Sure. Yeah.
Absolutely.
Jeroen Leenarts (44:45):
Okay. Thanks for your time and talk to you
next time.
Mohammad Azam (44:49):
Sounds good.
Thank you for having me.
Hi, and welcome to another special edition of on
podcast. I'm sitting here withSam sharp. And he's been on the
podcast before, close to one anda half year ago. And recently I
increased online if there weresome people interested to be on
the podcast. And as I'm actuallyraised his hand and indicated a
very good reason why he wants todo that. And the reason he wants
(00:27):
to be on the podcast, again, isto discuss some of his learnings
about Swift and swift UIdevelopment, because he claims
that he has created over 100prototypes in the last three
years, I think he said, andthat's quite an interesting
journey. So first of all,welcome back, Sam, how you doing
(00:48):
today?
Mohammad Azam (00:49):
Yeah, I'm doing great. Thanks for having me.
Jeroen Leenarts (00:51):
So you specifically mentioned that you
wanted to talk about yourlearning path into Swift and
swift UI over the past threeyears? Because people who do not
know you, they should look youup online, because you have some
wonderful material available forpeople who are interested in
learning more about Swift iOSand Swift UI development. What
(01:13):
am I missing here? What elseshould I share? Before we dive
Mohammad Azam (01:17):
in? Yeah, sure.
So I have a popular YouTubechannel close to like maybe
18,000 subscribers. I also have72,000 students on Udemy. And I
think it's like around 1012courses just on Swift UI. But I
believe the total courses areover 30, I believe, which are
covering swift UI, Firebasevapor, you know, a lot of
(01:40):
different stuff. So definitelycheck out the courses on the on
Udemy. Part. And definitelycheck out the latest courses
publishing out. But yeah, mainlya publish on Udemy and YouTube.
Jeroen Leenarts (01:55):
Yeah. And as always, I will make sure to link
everything in the show notes. Soby the end of the show, we'll
probably mention few of theselinks again, and but look at my
show notes. And I will make sureto list them there. Just to dive
in. You mentioned three years tome and over 100 prototypes. So
what's the what's the ideathere? Because you must have had
(02:18):
a reason to like reallyexperiment this much with code,
right?
Mohammad Azam (02:23):
Yeah, so most of the prototypes were actually
small projects that I was doingfor my Udemy courses. And I
recorded, I think, like 10, or15, or 10, or 12, at least,
courses just on Swift UI andpresentations. So most of them
were related to that. But onething that I started learning
(02:43):
is, and this is where it becomesa little bit more controversial,
which is good for I think mypodcast is, for last three years
since 2019 2021, whatever I wasusing, which everyone was using
MVVM design pattern. And I wasone of the biggest proponent of
MVVM. I wrote books on it spokeat different conferences,
(03:06):
articles, even courses on MVVM.
But after I do these apps, whenI started doing these apps, and
more and more apps, and the waythe app complexity was going,
the pattern was kind of likecoming in the way. So once I was
I think doing the MacOSapplications, I was like, Okay,
this doesn't seem right, thereis something wrong with what I'm
(03:28):
doing, or there's somethingwrong with serve UI, or how I'm
applying these patterns. So forthree years, I start doing or
start creating apps using MVVM.
And then after three years, I'mlike, this is not working out,
there's something wrong, like Icannot access the environment
object, I cannot access thefocus state, I cannot access
(03:50):
the, you know, gesture stateinside the view model. And it's
just a pain to pass thosedependency all the way down to
the child elements to the childviews. It's just a very much a
pain. And even if you pass thedependencies down to the child,
or children, then you're lost,like okay with who's maintaining
the dependency, because now it'slike all over the place. So I
(04:12):
went back to the drawing board,I started reading a little bit
more on how react works. And Ifound it interesting post
online, actually couple ofinteresting posts, that were
talking about the same thingthat I was experiencing. And
they were talking about how youshould not be using MVVM to
create some view application,because it's not a wrong
(04:33):
pattern, per se. But so if UI isalready a pattern, you should
not wrap it around with anotherpattern. And that's I found it
very interesting. And instead oflike telling that person whoever
posted like you're wrong, andyou don't even know what you're
talking about, instead of that Itried to communicate with and I
tried to contact that person.
And we started talking onTwitter and he was sharing some
(04:53):
ideas. I shared my ideas and wecame to the conclusion along
with some other people is thatit's just not, at least for our
apps clients or web application,at least, it was not making
sense to use MVVM to wrap ourwhole, you know, Swift UI with
MVVM framework or MVVM designpattern. And we in the end, we
(05:16):
found out that serve UI isalready a pattern. Instead of
wrapping it with other stuff, weshould just use how Apple is
trying to tell us how to use it,which is in their code examples.
Now, this is not to say that,okay, you should go back and
take out all the MVVM stuff andreplace it with a different
(05:36):
pattern. Now, if your app isworking out, you should just
keep it because there is alwaysa learning curve on new patterns
or new techniques. So I wouldjust keep it that way. Just look
at different experiment thatother people are doing, maybe
you will like those things. Soat that point, yeah, they will
only like few peoples in thecommunity, maybe a handful of
(05:58):
half a dozen that were talkingthat were saying that there is
something that we are missing.
And I will also eventuallybecome part of that one, and
kind of admit that I was doingit wrong, for close to three
years, especially for clientserver based applications. And
(06:18):
what we learn from watching thevideos watching how React is
doing stuff, is what I learnedis the view itself has the
capability of binding. So itdoesn't really need any help
from a separate view model file.
So we went back, I mean, I wentback to WPF, Windows
(06:39):
Presentation Foundation, whichwas in Microsoft, and I looked
at how Microsoft was doingthings because this is where the
MVVM pattern, you know, evolved.
And in WPF application, we hadzamel file and the C sharp file
and they were like gonna likelink together, whatever you type
in the zamel file, it will bebinded to the C sharp file,
(07:01):
which contains the view model.
But in our Swift UI, the viewconsists of all those property
wrappers like state and all thatstuff. So it doesn't really need
any help from a separate viewmodel. So we start looking into
this pattern and more, Iexperimented with it and started
converting my apps, the more itbecome very clear that this is
(07:21):
the way that Apple wants you todo this stuff, you don't really
need a view model for everysingle screen that you're going
to be building. The view has thecapability of binding, so why
not just use the view itself. Soa very quick example can be if
you're building something like alogin view, which contains a
user name, textbox and apassword textbox. If I'm using
(07:44):
the MVVM pattern, I will startwith login view model. Well, I
don't really need a login viewmodel. I mean, the login view
can contain two state propertyrecords, one for the username,
one for the password. And that'sit done. And you can validate
inside the view, the validationis just checking that you put
the username, and you put somesort of a password. But that's
(08:07):
pretty much it. That's notbusiness logic. That's just
basic UI validation. And I wrotean article on it, it was a very
initial article where I guess Ididn't do a good job of
explaining this kind of not anew pattern, but what Apple is
recommending or what Apple isdoing. And people were like, Oh,
you mean, like put everythinginside the view? I'm like, no,
(08:30):
no, no, that doesn't make anysense. No, you should not put
everything inside of view, youjust don't create a view model,
what you do is you create what Ilike to call an aggregate model,
meaning just one model for theapp for a small app, you just
need one model. And your viewwill communicate to that model.
(08:50):
And that model will communicateto the web service, the web
service will communicate to theserver, get back the data, and
it will pass through thefailures backwards. So that is
the architecture that I'm using,at least for my applications.
And it's actually turning out tobe really good, I can take
advantages of the environmentobject, I don't have to pass any
dependencies. I can use focus,there's just a state environment
(09:14):
values, whatever I need, I canjust do it inside the view. So
that was definitely a turningpoint for me to to create myself
UI abs in a very different way.
Jeroen Leenarts (09:27):
But but it isn't in a way making sure that
the data that is being handledin your app, really at the
center of everything that you'redoing right because the view
hierarchy manipulates this thismodel of data that you have that
is at the core of yourapplication, but then at some
point this this data needs to betransacted upon. So either it
(09:49):
needs to be transformed intosomething else or it has to be
sent off to a network locationto be handled there. So is it
like a Also that not only fromthe few hierarchy side, but also
from the networking sites andother areas within the logic of
your app that you try to workwith this data in a more
(10:11):
reactive way, or how are youlooking at this.
Mohammad Azam (10:15):
So I'm just looking at it in in mostly in
your simple applications, yourdesign will be or your
architecture will be in basic,like simple applications, your
view, will communicate withsomething called an aggregate
model, you can call it facade ifyou want, if that helps. And
that aggregate model will beresponsible for providing the
(10:37):
viewer with all the data itneeds. So let's say that view
needs the list of products. Sothat particular aggregate model
is going to use a web servicelayer to get all the data and
then just hand it over to theview using published properties.
Now, if you have a muchcomplicated application, much
bigger application than onemodel, one aggregate model is
(10:59):
not going to do the trick.
Because you might be dealingwith a catalog for E commerce,
you might be dealing with, youknow, inventory fulfillment. So
you can create multiple of thesefacade or aggregate models. And
those will be responsible forwhatever they want to do in that
particular domain, in thatbounded context. So a catalog,
(11:19):
aggregate model can return you alist of product, product items,
categories, but the fulfillmentwill be related to dealing all
the operation related tofulfillment, whatever that
domain does. So in the end, it'ssimilar to the MVVM. But we
removed the requirement tocreate a view model per every
(11:40):
view, that makes it simpler.
Jeroen Leenarts (11:46):
Yeah, because you're basically relying on the
binding behavior fromstraightaway into your model to
make sure that all the data getswell taken out of the model and
pushed back into the model. Andyou and is there like, is it
more like a technical reasonthat you choose, at some point
(12:09):
to split the models intoseparate aggregate models? Or is
that something that is morerelated to how you, as a
software developer, then candeal with a lower cognitive load
when working with this data?
Mohammad Azam (12:26):
Yeah, I think my theory is that, for simple
applications, you will only needone aggregate model, you can
even call it model, that's finewith a capital M. Yeah. And that
will provide you all the datayou need with like different,
different structs. So there'llbe one struct for product and
category and category items, andsorting behaviors, and filtering
(12:49):
behavior, all of that stuff, allof that implementation can go
inside that particular model.
But as your business needsevolve, and now you need to keep
track of, well, I need to docatalog, I need to do inventory,
I need to do fulfillment, thenyou start adding different
aggregate model or facades,whichever one you want. And
those will be responsible forgiving you different kinds of
(13:10):
model data that will bedisplayed and manipulated on the
screen. Now, from the viewperspective, for simple screens,
which only have few text boxes,three, four, even five, the view
itself can populate those textboxes in just a state variable,
and then pass it down to themodel. That's perfectly fine.
(13:33):
Now, if you have 10, or 20different fields, maybe you're
creating a page or a view, whichis responsible for driver
license registration, which is along page or long view, with a
lot of fields, maybe at thatpoint, it's a good idea to
create a separate struct, whichis responsible for holding that
data. So you don't have like 30fields 30 state variables, in a
(13:55):
one view, you have thatseparated out into one or
multiple, different structs,which you can say it's a view
model, that's fine.
Jeroen Leenarts (14:09):
But in your way of working these aggregate
models, they're not just data,right? They they also do other
things with the day to daymassage the data in a way that
it's like sorted or the orworked upon, so are filtered for
example, yes. Would you then onthis aggregate model also have
(14:30):
logic that actually initiates athing like a network call to a
web service or an end to webservice handling and error
handling and all the details andminutiae of that is basically
handled in probably some serviceobject?
Mohammad Azam (14:44):
Yes, yeah. So the aggregate model is responsible
for providing you the data interms of those struck models
like product category, usercustomer, whatever accounts to
those small models, by anaggregate model is also
response. trouble for initiatingthe call to the web service or
call to the network by using thenetwork service layer. So it's
(15:07):
not going to do it on its own.
It's going to ask the networkservice layer or the HTTP client
layer, that hey, can you give meall the products and then the
service layer, the networkservice later is going to fetch
all the products and assign itto a, basically a products,
property or public property onthat particular aggregate model.
And then it will be obviouslyautomatically refreshed, the
(15:29):
view will display it.
Jeroen Leenarts (15:33):
Yeah. Yeah. And then I can imagine that if you,
for instance, try and get a listof orders from your back end,
that you then on your aggregatemodel, have a function called
fall, let's just call it getorders, right? Yes, you just
(15:54):
want to fetch those, or maybefetch orders, whatever works for
you. But it sounds to me likethen the the aggregate model is
a really nice place to branchoff work on a separate track,
right. So that you have I thinkyou can really use async await
(16:15):
at that level there to make surethat you do something in the
user interface, the userinterface does not get blocked.
But once the data callbacks,it's it's populated in your
model. And because you'rebinding to the list of orders,
in your model, the view updates.
Mohammad Azam (16:30):
Oh, absolutely, yeah, so most of the functions
in my aggregate model, likefetch products, get products, or
whatever, they are asyncfunctions. And obviously, the
function in the web serviceitself, they are also async,
because that's where I will usethe URL session, dot shared or
whatever, to make the call. Sothat kind of helps to put all
(16:54):
the data in one central placefor small apps, at least. So
that you know, exactly, youknow, where the data is, what is
the state of the data. And it'ssometimes that in most of the
time, at least, for me, it's Ican just inject the aggregate
model object in the environmentvariable environment object, so
(17:14):
that it is available in the viewthat I injected plus all the
children. So then I can simplyuse the environment object to
get the actual data out anddisplayed on the screen. So it's
much easier for me.
Jeroen Leenarts (17:28):
Yeah, but but you will have the situation that
the aggregate model is sort oflike a pass through thing for
operations that reach out intothe network, right. But what if
you have some form of cachinggoing on. And it's not a typical
low level URL caching, but it'sa higher level caching? Is that
(17:49):
something that you wouldimplement in the in the surface
layer or in the aggregate modellayer, then
Mohammad Azam (17:54):
you have a choice, I think, in those cases,
I would just create a differentlayer for caching, and then use
that layer inside the aggregatemodel. So that if it's available
in the cache is returned fromthe cache don't even bother the
web service layer. And if it'snot available in the cache, or
maybe the time has expired, thenyeah, go ahead and get this
latest stuff from the cache.
Jeroen Leenarts (18:14):
Yeah. And it sounds to me that this very
straightforward layering thatyou put in your application,
because basically, you have asurface layer that does like
networking, asynchronous file,io, whatever. Then there's like
a model layer. And then there'sa few layers. So it's basically
a three layer system. And what'sthe furthest in complexity and
(18:35):
size that you have taken thisidea?
Mohammad Azam (18:39):
I've created some apps that had multiple aggregate
models. One is like an Ecommerce application kind of
scenario. But one of the peoplethat I was talking to the while
they're using a very similarmodel is called Well, little bit
simpler than using like anactive record pattern for their
approach. And they're creating afull fledge application with
(19:02):
like six to eight people workingon it. But for my case I work
with are converted basically allthe application that I was doing
before, and it was much easierto use, because I was not
dealing with like 30 differentview models. I just have where,
like, one or two view models ifI need to. But for me, I think
(19:23):
it was like two or threeaggregate models. I think that
was where I was working with.
Jeroen Leenarts (19:27):
Yeah. And but how does this work? When you
want to do some testing on youron your code? Because it seems
to me that the three layers arewell, quite tightly bound
together? Well, not not from notbottom up, but from top down.
There's a large dependency, ofcourse, between the deeper
layers within your app, right?
Mohammad Azam (19:47):
Yep. Yeah. So I wouldn't say I mean, tightly
bound or anything, but I thinkmost of the people who did
testing or one of the questionthey always ask me that, well,
how do I test it? Yeah, causewait The MVVM approach, I can
just go ahead and test it usingmy view model, I can just create
a instead of a view model, I cansay on whatever, like, increment
(20:10):
or whatever function I fire, andthen I can see that the view
model is getting populated ornot. Yeah, I don't believe that
Dota those tests are any useful.
I think. I mean, I've seen thosehundreds and 1000s of these
kinds of tests for view modelsand view controllers. But I
don't think they're testinganything. They're just testing
the implementation detailswithout testing the behavior
(20:31):
itself.
Jeroen Leenarts (20:34):
Yeah, I've seen tests that pretty much like
okay, I populate property and Iread property, yes, the same
value comes out. Wow, amazing.
Mohammad Azam (20:42):
And what these tests can actually doing is if
you're using the MVVM approach,or any approach, I mean, I don't
want to say MVVM is bad oranything. But if you're using
MVVM, model, or even the viewcontroller in UI kit, usually,
for these tests testing, whatyou do is you mock out the web
service layer, you mock it out,you say okay, I'm going to mock
(21:05):
it out, I own the web servicelayer, but I'm just going to
mock it out, I'm going to passit as a dependency, when the,
when this is called, then makesure that my view model property
gets changed. Well, if you'rewriting a test that is checking
for an expectation, on your viewmodel that a property of a view
model will get changed. That'sthe wrong test. Because that is
(21:27):
testing the implementationdetail, and not the behavior, if
you refactor your code andsimply change the name of the
property, and but the behaviorremains the same, your tested
start going to fail, which isincorrect, which shouldn't
happen. And these that's whythese kinds of tests are very,
very brittle test. Even if yourefactor your code, and the
(21:47):
behavior remains the same, thetest will start failing, which
is not a good idea. So now we goback to the customer, how do we
test them? Well, we test writinga real integration of end to end
test, like end to end test meansyour simulator is going to
launch you, the simulator or thetest, if you want to write
something in a text box, pressthe button, and then you're
(22:10):
going to check for the behavioragainst the real test server,
but not something that is mockedout. That is not saying that
mocking is bad in all thescenarios, but you shouldn't be
mocking heavily for things thatyou have access to, yes, if
there is a payment gateway, andevery time you access the
payment gateway, they charge,you should probably mark that
(22:31):
out or at Twitter framework,whatever, you don't have access
to that, you should do that. Butheavy mocking, which is being
advocated when you're testingyour view controllers and view
models that those tests are nota good return on your
investment.
Jeroen Leenarts (22:49):
But it does require a lot of control on the
deeper layers of yourarchitecture, right. And then
I'm talking about architectureof the entire stack, not just
the app, but also stuff that isbehind that, right. So you have
to have like a test environmentthat is somewhat stable, so that
if you run if two people run thesame test suite, at the same
(23:10):
time that they don't interferewith each other is that
complicated to achieve or thatthat
Mohammad Azam (23:15):
yeah, that's definitely one of the bad sides,
I guess of end to end testingthat there is the initial setup
that is required. If your serverif you're doing end to end
testing, then you will have tomake sure that your server is
performing all the migrations tocreate the database to create
the table, maybe add some seeddata, insert the data into the
(23:36):
tables that you are inserting,maybe you're adding a new
customer, verify it, and thendelete the data, because you
can't really read a live data inthe database, because it will
fail the next or the futuretest. So that will require a
little bit of quite a bit of asetup one time hopefully one
time setup. And, and then again,they are slow also, so end to
(23:59):
end test is not answer toeverything, because they are
also slow. But they are slow,because they are end to end. You
know, I mean, they check all thelayers. So you may not run them
every single time you check inthe code. But then you will have
to decide when to run themfrequently, but not as
frequently. So to slow you down.
Jeroen Leenarts (24:18):
Yeah. Yeah. So So probably you need some sort
of smaller units testing stillto test certain aspects of your
tech stack. Because because youdon't want to run the
integration tests like everyminute. Because yeah, probably
the integration test takes alittle bit longer than a single
minute. But is this integrationtesting? Is this something that
(24:42):
is typically done on thedevelopers machine? Or is it
more done on CI? And that isautomatically done when you push
your code to a central gitrepository or what's the what's
your thought process there?
Because I can just imagine thatif you have like a good group
people developing your backends,there's a good chance that they
(25:02):
actually are doing that in somesort of containerized way, and
that you can most likely run theentire tech stack, or at least
the critical parts of the techstack that you need in in the
local Docker environment. Forexample,
Mohammad Azam (25:15):
yes, yes, for end to end testing, which covers
like the whole layer ofeverything that should be
learned run under very fast CIserver, continuous integration
server, because the it will takea lot of time, depending on how
many tests you have. Now, ifyou're building a client server
application, where Sophie Why isobviously the client, and server
can be in whatever doesn'tmatter node or Express js, then
(25:40):
100 to a 99.9% of the time, youractual logic of the application,
the domain will be living on theserver, meaning on the
JavaScript side on the nodeside, or SP dotnet, Ruby on
Rails, whatever. So that has tobe tested thoroughly like like
really, really well. Kind oflike if you're building a bank,
system finance system, you musttest out your server can deposit
(26:04):
the money into the bank,withdraw the money, transfer the
money, and if there is ainsufficient funds, then make
sure that you charge overdraftfee because that's like, that's
that's the money in the bank.
Basically, there's like a $2billion difference for these
banks sometime $5 billionbusiness. So those are the
moneymakers. So that core, orthe domain has to be tested
(26:25):
thoroughly with unit tests likeplain ol unit test on the
server. And then we willobviously if you're exposing
your API to someone else, thenthe public API needs to be
tested thoroughly usingintegration tests or unit tests,
whatever. And then the wholesystem, all the layers have to
be tested. And usually end toend test tests are usually run
(26:47):
on CI server because they areslow in the end.
Jeroen Leenarts (26:52):
Yeah. And but I can imagine that if you really
step back and accept thatcertain aspects of an app that
you're building is pretty much aJSON based rest surface browser,
because that's what many appsactually in fact are. You can
make a distinction in your codebase that if it's really like,
(27:15):
okay, calling web services anddealing with the results of
that, that you then accept thatthe testing that you do as an
app developer, it is more on theintegration level. And if
there's other logic within yourapp that is, well, less bounce
to the web serves as more logicand self standing on its own,
that you then in fact, do ourwork more on the end to end
(27:40):
testing of that logic. But ofcourse, if you look at an
integration test that you wouldneed to do on such a piece of
code, for instance, you need todo some processing on an image
or whatever. That is somethingthat you can test end to end as
well. But that's just because ofthe fact that the end results of
your test. They don't leave thesystem, or at least they you can
(28:01):
test in a state that you don'thave to have network interaction
at that point. But you stillhave a meaningful test going on?
Because yes, there's actuallogic, actual complexity being
processed on some inputs, thatshould present a certain output,
right?
Mohammad Azam (28:15):
Yeah, yeah, I think if, if our app is simply
which most of the soap UI appsare simply consuming the actual
data from JSON service, and thenobviously, the server people or
whatever, they're gonna test theserver side and the public
API's. But as a soap UIdeveloper, I will be definitely
be more focused on end to endtests writing and consuming or
(28:39):
integration tests. In this case,I guess, yeah, integration
tests, checking that my client,the behavior that I'm trying to
achieve is tested through myswift UI app launching,
simulating those events,filtering the options, and
although thing against the reallife test server, definitely
that will be much helpful.
Jeroen Leenarts (29:01):
And what kinds of techniques or frameworks or
things would you suggest? Or areyou actually using yourself in
these integration tests, I canimagine some UI automation. I
can imagine some scripting toinfluence the back end, or maybe
even have a dedicated commandline client for the back end
(29:21):
that you can call from yourtests, right?
Mohammad Azam (29:25):
Yeah, for my integration tests, and since
most of my end to end tests,they're most of them are related
to node and express because myserver on the safe side, I'm
using just a basic x unit, orXC, like a UI test framework
that they have the building. Andyou can change the
configuration. I mean, you canwrite some code to check if it's
(29:48):
running on UI tests and you thetest server routes or URL, but
you can also make those buildconfigurations and simply the
whole configuration will bedepending on whatever the build
target that you select, so youcan have like a lot of variables
in there in the built in thebuild file. From the server,
yes, server becomes a little bitmore complicated when you do end
(30:10):
to end because now you have tocreate the database, you have to
do the migrations you things, ifyou're using SQLite, or which
whichever database or techniquethat you're using, and that will
reside on kind of like on theserver side to do all of those
things. So that is where thecomplexity comes into play. And
that is where it takes a lot oftime to drop those database,
(30:33):
build it up, again, for everysingle test. And I think that's
where the slowness comes intoplay. Also, I think, in the end,
for me, it's most more aboutsince all the tests are not
equal, like one test, theydepending on what kind of apps
(30:54):
that we're building the test fordepositing money and withdrawing
money and charging the userwithdraw, I mean, the penalty or
whatever, for insufficientfunds, those kinds of things
will be more important to me, ormore must be because they
actually create revenue for thecompany. But we find creating a
find have created a loggingengine, which are logging
(31:17):
framework that will log when youlog in and log out, it will be
kind of like at the bottom of mylist because okay, it didn't log
whatever. I'll get to that whenI will get to it. Because, you
know, I mean, that can betested, but it's not as a high
priority.
Jeroen Leenarts (31:33):
Yeah. So yeah, because I'm thinking about if
people want to learn more aboutthis approach, I know you wrote
an article on this. And it's, Ithink you wrote that in October,
if I'm correct, a few monthsago. But have you already been
able to create some, some somemore information about that,
(31:57):
because the initial article thatyou wrote about it is, is really
like just dropping down theidea? And probably getting some
responses and communication andsome discussions going on that.
So but that's the initiation ofthe concept and the idea, but
where are you at now withexploring this idea in this
concept? And is it alreadysomething that you feel that has
(32:20):
enough proof in your mind thatit is it is usable? An actual
sound way to go about setting upan app?
Mohammad Azam (32:29):
For me, it works.
I mean, that's all I can say.
And I think initially when Iposted the idea, and I'm just
checking, it was a few thirdcouple of months ago. The latest
article on that is, I'm not surethe date I think it was in
October 6 2022 is the latestone, which was about which is
called swift UI architecture, acomplete guide to MVC pattern
(32:52):
approach. And then I did also alittle bit more article on core
data, how you can embrace coredata with Swift UI, and how you
can evolve with Swift UIarchitecture for client server
apps. So I have been evolving itin terms of core data and client
server apps. But I think ifsomebody has to read this
article, I would definitelycheck out the Swift UI
(33:14):
architecture, complete guide toMVC pattern that's most updated,
I think, our article.
Jeroen Leenarts (33:20):
Yeah. And, of course, view being you. There's
probably also a Udemy courseabout that, where you explore
this concepts a lot more, right?
Mohammad Azam (33:30):
Yes, there is a Udemy course that I published, I
think, this year, and it'scalled MVC design pattern. And
iOS builds a few apps applesway. So after talking to a lot
of people and getting intoissues with MVVM, I went back
and watch all the videos of surfUI, and try to bother like,
(33:53):
very, very slowly try to see allthe code that they're writing,
definitely check out their codefor the food truck application.
That is, I mean, that's a decentsize app. I mean, somebody can
say, well, it's gonna work on asmall app, but it's not going to
work on larger well definedlarge. So that argument, that
argument in itself is selfdefeating, because they cannot
(34:15):
define large what's the Lord'sapp 2 million? Well, how about
if I work with 10 million linesof code for me 2 million small,
there we go. With the largestrelative not absolute. So that's
another problem. So but yeah,
Jeroen Leenarts (34:28):
but you at the start of this conversation, you
we mentioned that? You did like100 prototypes. So these 100
prototypes. Can you again, tellme why. In your sound mind, did
you come up with the concept ofhey, let's create like a
gazillion prototypes and justsee where I end up? Because
(34:51):
there must have been someprocess to the madness, right?
Mohammad Azam (34:54):
Oh, yeah. So prototypes. I started creating
for my courses for sale. UI. Sowhen soap UI came out 2019, I
started working on my firstscores, which contains like, a
lot of different apps. Andsomewhat simple, somebody a bit
more complicated. So duringthose three years, I created
like hundreds and hundreds ofprototypes using Firebase using
(35:17):
core data using just a few I,using realm, I mean, so many
different frameworks I had touse. And initially, I was using
MVVM pattern. And it was workingout but it was like, I had to
always have to like, Okay, Ineed to pass a dependency into a
dependency into a dependency,that I don't want to do that
anymore. So that is where I waslike, Okay, maybe I'm doing
(35:38):
something wrong over here.
Because then I started lookingat React also, because react and
so few, I pretty much the samething. React people are a little
bit more crazy than so fewpeople because we in React, they
have components and right insidethe component, they will make
the network request, just fine.
I mean, yeah, sure, if you thinkyour component is only going to
(36:01):
be displaying and not being usedsomewhere else, you can perform
the fetch request, which willbasically a network request, get
the data and display it on thescreen. I mean, that's fine. And
since you I also, I don't haveproblem with that, it's a little
bit too liberal for my tastes,at least, I mean, I would like
to have a little bit moreseparation. So that's why I have
(36:22):
that responsibility to theaggregate model or facade, which
calls the web service layer. SoI'm a little bit more future
proof if the app goes into muchbigger. So that is my view of
that.
Jeroen Leenarts (36:35):
Okay. So just to recap, you did like a lot of
experimentation. And then youcame to the conclusion that you
think, on a general level, whendeveloping swift UI code, we're
doing it wrong. And the doing itwrong, is that we just add a lot
of architectural complexitylayering, because most likely,
(37:01):
that's what we are used tocoming in from UI kits. And
that's also what we need it whendealing with UI kit to keep the
complexity in check. How do youfeel about having these
aggregate models and just makingthem available in the in the
environment of Swift UI? Becausesome people will immediately
(37:24):
say, Yeah, but that's likeyou're creating a global and in
some languages, some frameworksthat's, that's a bit of a no,
no. But what's what's yourstance about that in Swift UI,
Mohammad Azam (37:37):
so not every time I put it in that environment,
but most of the app I'm makingis, they have the capability to
edit or update and delete indifferent views. And it's easier
for me to have that available inthe environment, instead of
passing down as a bindingproperty. So sometimes I can use
state objects, sometimes I canuse observer object, but it
(37:58):
sometimes I mean, most of thetime, it makes sense for my apps
to because I'm creating, create,read, update, delete all the
operation, to put it inenvironment. Now environment is
not technically a global object,because it depends on where
you're injecting it. So you caninject it on the root. And it
will be available to the rootand all the child of the root.
And I think there's one very bigmisconception, which I also had
(38:23):
was about when that sort of UIrecreates your view re renders
your view, because I was underthe impression for a long time
that, Oh, you just put a selfdot print changes inside the
body property. And whenever thatfires, okay, all the view is
gone and recreated from scratch.
But that is actually not true atall. The body property, if you
(38:45):
put a self dot print changes, orhello world, something inside
there, the body property, whenit fires is only telling you
that the body is being evaluatedright now. It's not being
recreated. So Sofia is quitesmart. Because if something
change in your view, if you'reincrementing a counter, and
(39:08):
you're displaying a counted in atext field, but you also have a
text, sorry, a text view, andyou have a list and you have a
button and you have a pickerview and a segmented control,
blah, blah, blah. So if you'renot going to recreate all of
that stuff, because all of noneof that stuff is using the
counter value that just gotincremented it's only going to
update the text view becausethat's the only one chord
(39:29):
change. So during the evaluationprocess is going to make a diff
meaning differentiation betweenthe new tree and the old tree.
And it's going to find out thatoh, well, there's only one
control the TextView thatactually use the counter. So all
of these other five controls, Idon't have to recreate them. So
I think that's the good thing.
(39:51):
And that is what also happenedwith the environment. Just
because you put something in theenvironment does not mean here
the whole app is going torefresh and rebrand. Under, it's
only going to read under if thatparticular view is using the
property of or from theenvironment.
Jeroen Leenarts (40:06):
Yeah, yeah. And that's, that's there's a lot of
smart diffing going on in thebackground, to actually see what
has changed between the viewhierarchy as it is encode and
what is actually on screen. Andyou can trip it up. Sometimes it
does more than you would like,but then there are ways to get
(40:29):
around that. So but just to, towell to to start closing things
off a little bit. We alreadymentioned some of the articles
and some of the coursework thatyou did on the MVC design
pattern. And but what I'm alsocurious about is last time we
(40:50):
spoke on the podcast wassometime in the summer of 2021.
What has happened since then,what have you been doing? And
what are some of the successesthat you do you have in the
well, I think close to one and ahalf year already?
Mohammad Azam (41:08):
Yeah, I've been busy obviously teaching, that's
my full time job. I think I wasteaching my 13 or 1414 cohort
for for the company that I workfor digital crafts. And then
very busy in I think I publishedI published two small books, one
of the navigation API, and oneon UI kit with a few recipes.
(41:30):
Both are available for free.
During the holidays, you can getit for free completely. And I
also published an actualhardcopy book, which is about
the boot camp, which issurviving the coding boot camp.
It's a small book hardcopy plusebook also. So that contains a
lot of advice related to whichboot camp to attempt to enter
(41:50):
and what goes into boot camp,how to be a successful student,
because I've been teaching forsix years now. And doing like
some independent work on theside sometimes. But and yeah, of
course, a lot of courses Ideveloped like MVC design
pattern. The new course I justpublished, like maybe couple of
weeks ago was about UI kit,because they were people were
(42:13):
like, Hey, you forgot about you.
And Katie, you haven't talkedabout it for a long time. Um,
okay, here's the code for you UIkit with completely programmatic
approach. No storyboards, no,nothing. So, so yeah, definitely
fun.
Jeroen Leenarts (42:27):
Suggest just dabbling server, some old school
iOS development, just for justfor the heck of it,
Mohammad Azam (42:33):
just for the heck of it.
Jeroen Leenarts (42:35):
And as the iOS related teaching that you do on
the side, because your main jobis, is doing coursework for a
company, but you do the iOSstuff on the site is still doing
for you what you intend it to bedoing for you just create a
little bit of extra income foryou and your family to, you
(42:56):
know, just do the occasional funtrip every now and then. And are
some other extra expenses thatthat just make living. That
little bit more enjoyable foryou and your family.
Mohammad Azam (43:08):
Yeah, definitely.
I think it's just extra incomethat, you know, I like to
travel. So I usually dosometimes those trips for hiking
to Colorado or wherever. Andsome time I we just came back
from beautiful Mexico City, thewhole family vacation, or nice
couple of weeks, I think threeweeks ago or something. Yeah,
that was fun. And yeah, I'm, Iconsider myself a little bit of
(43:30):
a finance guy. So I do invest alittle bit of money on from that
into mutual funds. Very simplestuff. But yeah, it's been it's
been fun. And I think what thesecourts have allowed me to do is
to kind of like, take a stepback and think about those
things. Because I know that whenwe are on the clock, we have to
type some time, we're not reallythinking that much. But now, it
(43:51):
has allowed me to kind of likeslow down, think about things
and then write about it muchmore better than just completing
these tasks and all that stuff.
Jeroen Leenarts (44:03):
Okay, cool.
Sounds good. Seems you're stillin a in a very good place with
your work and how are youenjoying it and how you spending
your time? Where should peoplego look to find everything that
you do online?
Mohammad Azam (44:17):
The best way would be Twitter. You can follow
me at awesome sharp AZ am shERP. And yeah, if you follow me
on Twitter, you'll get to knowabout everything that I'm doing
because I am quite active. Yeah,that's the best way.
Jeroen Leenarts (44:33):
Okay. I will make sure to link that in the
show notes. And yeah, I think Ithink we covered what we wants
to cover in this conversation, Ithink.
Mohammad Azam (44:43):
Sure. Yeah.
Absolutely.
Jeroen Leenarts (44:45):
Okay. Thanks for your time and talk to you
next time.
Mohammad Azam (44:49):
Sounds good.
Thank you for having me.
Popular Podcasts
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Intentionally Disturbing
Join me on this podcast as I navigate the murky waters of human behavior, current events, and personal anecdotes through in-depth interviews with incredible people—all served with a generous helping of sarcasm and satire. After years as a forensic and clinical psychologist, I offer a unique interview style and a low tolerance for bullshit, quickly steering conversations toward depth and darkness. I honor the seriousness while also appreciating wit. I’m your guide through the twisted labyrinth of the human psyche, armed with dark humor and biting wit.