Part 1/2

In this podcast episode, Krish introduces the audience to Snowpal's podcast and encourages exploration of their latest feature on snowpal.com before delving into the main discussion. He focuses on the concept of separation of concerns and design patterns within native mobile app development. Krish emphasizes the importance of developers focusing on their specific tasks without worrying about backend intricacies, such as data integration. He highlights the significance of recognizing and leveraging existing design patterns to streamline development processes. Using practical examples, Krish illustrates how implementing a structured approach to method invocation and data handling can facilitate adaptation to potential backend changes while minimizing impact on the overall application. Overall, Krish underscores the critical role of separation of concerns in building efficient and adaptable mobile applications.

Podcast

Check out on Spotify.

Summary

Explanation of Concerns in Mobile App Development:

• Introduction to implementing a new feature

• Discussion on concerns while implementing screens

• Focus on what developers should not have to be concerned about

Understanding Data Integration:

• Clarification on data integration concerns

• Emphasizing the importance of not worrying about backend details

Identifying Design Patterns:

• Discussion on identifying design patterns

• Importance of recognizing and leveraging existing design patterns

Implementation and Adaptation:

• Example scenario of method invocation and data handling

• Addressing potential backend changes and their impact

Conclusion

• Reflection on the importance of separation of concerns

Transcript

0:00

Hello. Hey everyone, this is Krish and hope you're doing well. Welcome to Snowpal's podcast. In this podcast, I want to talk about design patterns and separation of concerns in the context of native mobile app development.But before we go into the podcast, I want to ask you if you've checked out our latest and greatest feature called Project Key on snowpal.com.

0:25

They essentially point to the same SAS platform.If you've not, I strongly recommend that you do so because it's going to give you a ton of power over managing your projects more efficiently and successfully.OK, Now having said that, let's get into this podcast and I want to talk about separation of concerns and design patterns.

0:46

Like I said earlier, let's take a small example and try to drill deeper into that. Say you're implementing a new feature. It could be a new mobile app or an existing 1A native app. It doesn't really matter.But let's say you're implementing a new feature and you've been charted with implementing a few different screens.

1:05

Let's start small.One screen, right?One screen, a few attributes, and it's got some functionality. As to what that is really doesn't matter. So let's make a ton of assumptions as we go along.Someone said, OK, can you please implement this screen or one or two screens, And here's the data that you're gonna get, Here's what the user experience should look like, and here's the design for the user interface itself, right?

1:32

Something of that sort.Now when you start implementing, there are a few things you want to be concerned about.We may not talk about that in this podcast, but there are a few things that you should not have to be concerned about.And that's what I want to touch upon as somebody who's building AUI page, AUI screen on a mobile app.

1:53

I can worry about a bunch of things, but again, what I shouldn't have to worry about is where am I getting this data from?In the sense is it is, is this app integrating with third party service or with our own back end services, one or more micro services and what the exchange is built on and how that looks like right?

2:15

It could be a Restful exchange, it could be, it could be graph QL based exchange, it could be one of many things right?It doesn't matter as AUI developer and I'm pairing this UI hat building this screen on mobile, should I have to worry about those things?

2:34

Not at all, right?As far as I'm concerned, I'm going to get some data from somewhere and I need to make sure that the data gets placed on the screen in the right objects, using the right widgets and components correctly so the user can have the best experience and get whatever it is that they're trying to do in the quickest possible time, etcetera, etcetera.

2:57

Right now all that I need to know about the data and where it comes from is what method should I call, whether that method is an HTTP GET or a POST or a PATCH or a DELETE or what it integrates with.Again, it's not my concern.

3:13

I need to know which method to call, what arguments to pass that, what what it what the the spec looks like.The spec meaning between me, my layer, the screen and the method that I'm calling, not the spec between that layer and the third party and or your back end services.

3:30

So I need to know what that method is, what arguments I need to pass that method and what it will give me in return and what will give me what it will give me in return.What I mean by that is, even if that exchange in the real actual back end in the call happens to be Graph QL or REST or JSON or XML or whatever it is, I need a deserialized object, right?

3:52

And in memory deserialized object so I can consume that object and use it and use its methods and everything else that goes along with that object. To the extent that I need to to build these screens, how the the definition of the object and the interaction, my UI screens, interaction with that object or that model is all that should matter to me, at least from that aspect.

4:20

Now if we start, if I have to start worrying about everything behind that, then I'm not going to be spending my time wisely in building these UI pages.And the reason I say it more than once, and it might sound like I might sound like a broken record because I feel like I've said the same thing more than three times in like 3 minutes, it's because I was looking for to identifying these design patterns because you know when you're trying to solve a problem, The first one of the first questions I asked myself is, hey, is this problem unique enough that I have to solve it differently or is it possible that nobody else has solved anything like this before?

4:58

9 out of 10 times?That's not the case, right?Your app is different, your product is different, the problems it's solving is different, but the underlying design patterns are.There's only so many of those.And if you haven't checked out the Gang of Four or the Enterprise Design Patterns, Patterns, you know, I strongly recommend you do that.

5:15

But even if you didn't go through those books cover to cover, I mean if we all if we when you do the same thing for many years, you understand that there are going to be certain design patterns whether they are documented or otherwise. So you try to look out for those and in the 9 out of 10 times when you can think of those, even if you can't name those patterns, you know that you can take a certain approach and don't have to reinvent the wheel, right?

5:41

It's very extremely important for many reasons.One is the time to market you can get.You can solve your problems much quicker that way.You can also solve them better because somebody's already figured this out, so you don't have to reinvent the wheel.And thirdly, when someone else looks at your code, they don't have to understand the way you may have thought in solving that particular problem because this, the design pattern sort of speaks for itself and they understand what that is because they understand those patterns, right?

6:12

So there are many positives or prose.Essentially, I just called out for some of them. So I'm starting to build the screen and I'm calling a method.Imagine the case where there is a method and I pass some arguments, it gives me an object or a map or whatever the data structure is and then I go from there.

6:29

That way I don't need to know what else is going on behind the scenes to.I also am not worried about any updates that are happening or any changes that are happening between the server and the API integration on the native mobile app site.

6:46

So if an attributes name were to change for instance, or the worst case scenario, even if the entire structure of the response changed, the object is going to hide that from me, right?The models going to hide that from me, so the deserialized version is hopefully going to continue to be backwards compatible so I don't have to make any changes to my screens or pages.

7:07

So therein lies the separation of concerns.If something changed in the back end, maybe someone changed their Java or Ruby server to node entirely so or maybe they didn't change the stack dramatically, but they just changed the specs. So things change quite a bit between version one and version two, or version one and version 1.1.

7:27

And if that were to be the case, you want to make sure that there's one or two of your tiers get impacted on the native mobile app, but not the whole 9 yards.I also say this because when you mention full stack development more often, more often than not folks tend to think of that as okay UI middleware back in the whole 9 ads.

7:47

But one of those tiers is actually a client, which is a native app.But even within the scope of a native app, there is still full stack development right?Because you can slice and dice your native app N number of ways and you can create as many layers as you possibly can or should.

8:04

So they are all separate from each other and each one's change is does not when it lives in isolation and it doesn't impact the other tiers, right?So we have to think full stack even within each of the layers, whether it's full stack as an application overall or full stack within the native mobile app or even full stack within back end for instance, Right.

8:24

I'll take a different example another day in another podcast for that.But in this first podcast I want to talk about separation of concerns.Because you know, you know when you go look up a ton of examples or you read articles.

8:39

There's plenty of good examples, but I haven't found one that called out for the separation of concerns from an API standpoint, at least from building a mobile app, you know, in the context of building a native mobile app. So I just try to come up with a few different patterns that seem to make sense to me.

8:57

But there's one that we've actually gone, we're going with and we've actually made quite a bit of progress which you know is able to establish that separation.And you know even in the first few days or so we're seeing that we're able to make changes in different layers without it having having an impact on every aspect of the mobile app necessarily.

9:22

So hopefully that made some sense and it helps some of you.We'll pick this back up in the next podcast.

Thank you.

Part 2/2

The podcast, led by Krish, delves into the critical concept of separation of concerns in native mobile app development. Krish emphasizes the need to separate UI development from API integration, highlighting the complexity and variability of backend APIs. He proposes an implementation strategy involving YAML files to dynamically construct API requests, thereby minimizing code changes and ensuring loose coupling. The importance of maintaining separation of concerns throughout the codebase is underscored to prevent spaghetti code and facilitate easier maintenance. The episode concludes with a summary of key points and a hint towards further exploration in the next installment.

Podcast

Check out on Spotify.

Summary

Advertisement for Scheduler Feature

• Promotion of a new feature called Scheduler on snowpal.com.

• Description of Scheduler’s features and benefits.

Discussion on Separation of Concerns in Mobile App Development

• Explanation of the concept introduced in the previous podcast.

• Emphasis on the importance of separating UI development from API integration.

Considerations in API Integration

• Explanation of the complexity and variability in backend APIs.

• Discussion on different types of APIs and their characteristics.

• Emphasis on the need for loosely coupled integration to minimize developer concerns.

Implementation Strategies for API Integration

• Proposal of a specific implementation strategy using YAML files.

• Description of how YAML files can define API paths, methods, parameters, and responses.

• Explanation of how this approach facilitates dynamic API request construction and minimizes code changes.

Importance of Separation of Concerns in Codebase Maintenance

• Emphasis on the importance of separation of concerns in software development.

• Discussion on how tightly coupled code can lead to spaghetti code and maintenance challenges.

• Advocacy for starting projects with proper separation of concerns to avoid future issues.

Transcript

0:01

Hello.Hey everyone, this is Krish and hope you're doing well.Welcome to Snap Pal's podcast. In this podcast I want to talk continue to talk about separation of concerns in the context of native mobile app development.This is podcast #2 in this series, so if you haven't seen heard the previous one, please check that out.

0:20

But before I go into the podcast, I wanna ask you if you've taken a look at one of our new features on snowpal.com. It's called Scheduler.If you've not, definitely check it out. It's a beautiful scheduler, A fancy one I should say.

0:37

It gives you complete control over managing your events, stand alone events and system events as well. So you can define your due dates and see all of your activities and what's spending and what's due in one place after you sign in. So I think you would enjoy that immensely and benefit from that as well.

0:56

Now having said that, let me get into the podcast, the last one I talked about separation of concerns and how you could not have your mobile UI developer just the UI.Let's say you're wearing a UI hat and you're building pages in a mobile app.

1:14

At that point how can you not be worried about the API integration?That's what we talked about in the previous podcast. In this one I want to drill deeper and talk about few one option, one way of going about doing that.Let's say I'm building this new page, new screen and you need to call a method and what that method does or sorry which API it integrates with in the back end is not my concern as we discussed as in the previous podcast.

1:39

But I call the method, I call it with some params and then it gives me a response, which is essentially A deserialized object.And I'm able to go about merely building my screens.Now to create that separation, what had to happen?

1:54

What is one way you could do it?Let's talk about that.Now each of these in that layer that integrates with your back end, we're going to talk about that specific implementation right now, right?So I'm just going to not be the UI screen developer at this point and talk about how I can do something correctly or well enough so my UI developer within the mobile app can be focused on what they are actually doing and not about the rest of the integration.

2:24

Now let's say in our case we have hundreds of APIs that serve multiple clients.One is our web client, one is the mobile web client, and there is a native client as native app client as well.Now there could be changes that happen in the back end.Maybe the structure of the response changes, maybe the stack changes and some other things change.

2:43

Or maybe none of those change, but the attribute names change.Or there are other semantic changes to the responses. It could be one of many things.And then in term, in when it comes to these hundreds of APIs, they are They are GET APIs, HTTP Gets, HTTP Puts, Patches, Deletes, Posts, and and whatnot, right?

3:05

So there is a variety of APIs.The path is different.Say you have Restful APIs and you could have Graph APIs.You could have a combination of them as well. So each of them is different in all possible ways, right?The spec is the different, meaning the URL, the the API path is different, the query string params are different, whether it what it accepts, the headers, the security headers, authorization.

3:30

There could be a lot of variations.Now when you're implementing these, when you're, sorry, not implementing the APIs, but you're implementing the aspect of the mobile app that integrates with these layers, you want to keep that as loosely coupled as possible.And what I mean by that is my method that serves as a facade to the mobile screen developer should not.

3:54

Of course, you know the if I'm building the screen, I shouldn't.I don't even know that that integrates with the back end API.But even the person who's implementing that piece of the puzzle in the mobile app shouldn't have to worry about whether it's a GET or a PUT or a POST or a PATCH.

4:10

Because if they did that, their code is going to start looking ugly and it's going to be pretty redundant.Now how can you do this?One way you can do it, and that's, you know, I tried out a few different patterns.Again, every time your stack changes, you want to rethink the approach.

4:26

Because even though even though this computer science fundamentals don't necessarily dramatically change, you don't want to write note code with a Ruby flavor, or Java code with a note flavor or React Native with a dot flavor, right?

4:42

I mean what I mean by that is it should smell and feel with that stack, so it's easy for the next person to understand what you wrote. So it's not just good enough.If your code is clean and pretty nice, it should also be In Sync with that stack and that stacks recommendations and design patterns.

4:59

And that can sometimes get challenging, especially when you're a polyglot, polyglot developer and you're working on different things at at about the same time.OK, that was a digression.Apologies.Now back to what I was trying to say.Now you're building this layer that sits in between your back, your actual back end or third party services and your mobile UI screens, and you don't want to.

5:24

I always have to worry about whether it's a GET or a PUT or what arguments does it take, what I can expect in the in the response and things of that nature. So you can create a few levels of layers of separation there.One of them is like, for instance, the way we've implemented some of our API integration work in that.

5:43

In that context is we have we have a YAML file where we push all of the API path and it's definition too, right?So it specifies the method, whether it's a GET or a PUT or a PATCH or a DELETE. It has the path, it has a query string, params and everything else.

6:00

That essentially makes up that API call, the request and the response to some extent as well, right?But definitely the request.That way when we are implementing the APIs, we can just consume the YAML, right?

6:15

Not worrying about what that is, and dynamically construct those API requests. So the YAML is going to tell us whether it's a GET or a PUT, and it's going to tell us what the path is going to look like and what the query sync params are.And it it also contains the actual mapping between the string, the attribute names used in the actual back end.

6:36

So when you're writing your actual code, right outside of the YAML, actual executable code in that sense, you're looking up these YAML files.And we have like a number of YAML files essentially that for each of the different layers and pages and we call, we look up that YAML and we just have that snippet in the YAML, we give it a name so we can construct this API request sort of dynamically, right?

7:03

And if the PUT changes to a patch or if the path API path changes, all that we have to do is update the YAML and then we are generally good to go, right?I mean, sure there are some cases where you have to make changes in other places that is always bound ought to happen, right?

7:21

It's going to happen most of the time, but you want to minimize the number of times it happens. If it has to happen 100 times, you want to try and make it at 50 times, and if it has to happen 50 times, you make it 25 times, right? You get the picture. So you want to create these layers of separation, so each layer within your app actually is independent from the other.

7:44

Because when we talk separation of concerns, when we talk different tiers and distributive architecture, I feel like we we think slightly bigger in terms of the bigger picture where hey, I have a number of apps that make up my platform or my suite and then how do each of those apps talk to each other and whether I have a bus or what integration layer I have in between And all of those those things, right.

8:05

Which is completely unrelated to what I'm trying to say here.Even given a smaller problem, a much scoped down problem, there are still separation of concerns, right?You need to make sure those separations are there.If not, you're going, your code is going to become tightly net and it's going to start looking more like spaghetti code.

8:24

So if you want to take extra precaution and as quickly as possible because you know obviously we're going to have to continue to refactor and improve our code base.But at least we don't want to introduce a mistake sort of quote UN quote knowingly in the sense that we've have had that experience in the past and we're like maybe I can ignore it, but probably you shouldn't, right.

8:44

You want to make sure you start out correctly, whether it's a brand new product, brand new application, brand new app branding API, or just enhancements and changes and tweaks to existing APIs and screens.You still want to give it the same amount of respect in terms of how can I do this better, how can I keep the separation, Separation of concerns?

9:06

Just one aspect of software development, obviously, but I'm just trying to focus all of this podcast in that particular item.There's more for me to continue with this design pattern.When I'm close to the 10 minutes, I'll pick this back up in Podcast #3 in this series.

9:22

Thank you.