Mobile Programming
Programming model
This lesson is part of the Mobile for OutSystems Developers course.
LEARN MORE

Transcript
Selcome to the programming model. In this session
we'd like to talk about some of the basic programming elements that are
available inside of OutSystems and they've been separated into layers.
So we'll look at some of the basic elements very quickly and then take a deeper look
at how they fit into the overall lifecycle of the screens that we try to
create so there are web screens that have a particular type of cycle
and it revolves around synchronous requests and responses we also want to
look at the mobile screen lifecycle and how different it is and the fact that
it's asynchronous and then it has many more events and event handlers to
dictate how the screens will be rendered and how they will be interacting so if
we think about the OutSystems environment, we know that OutSystems
had the capability of doing web apps in previous versions and that's because it
had the server-side logic and the synchronous request response that we
were just talking about from a web app perspective. Now we have the new mobile
applications, and the new mobile applications have client-side logic as
well as available client-side local storage and they make all their requests
in an asynchronous fashion because the device once it gets its data can change
the way it looks and what it does as it needs to
so two very different programming models or at least two different life cycles
for those types of programming models so when we think of the basic elements that
OutSystems creates we know that we've talked about the four layers and when we
think about the four layers we can kind of leave business processes and
processes alone because they're on a higher level but if we think about the
interfaces we will have different types of screen flows or groups of screens and
individual screens inside of those flows
and those screens and those flows can have some sort of themes to go ahead and
dictate the overall look and feel the screens will eventually need to do
something and that requires some sort of logic there will be client actions that
run on the device for the mobile side of things and then there are the server
actions that are running on the server side sometimes when we're doing extra
work on the server side we will be using services or other types of integrations
and making sure that those are secured so a lot of different individual logic
components that are available and we're going to need some data. The logic and
the screens will be attempting to display some sort of information and
that maybe information that's been persisted inside of a database, it maybe
just information that we've built inside of the application and is in memory, but
there are plenty of types of data that we wish to be able to expose inside of
the apps that were building. So if we think about the web apps that we may
want to build or that we have traditionally built in the past, a web
app is a page so we may have some sort of HTML page and it makes a request so
maybe we're trying to book a hotel and we ask for more details about a
particular booking when the request comes to the server OutSystems has
these UI flows that we mentioned and the UI flows have individual screens so if
we're looking for the BookingDetail screen it can navigate to the
BookingDetail screen and basically say this is what the BookingDetail screen is made
up of and here are some of the things that we can do inside the screen. If
we're just trying to get the screen we would get the data that is required to
prepare the overall HTML page retrieving the things from the database that we
need and then looking at the screen itself and saying what are the widgets
and individual UI components that need to be rendered, and we would go ahead and
render those as HTML send the data back and any other
cascading style sheets, JavaScript, any types of images that would go back as
individual page resources and that would allow us to return the page. So that's
sort of one simple life cycle through the page now if we wanted to go ahead
and then cancel the Booking we would again ask for Cancel Booking when we
cancel the booking to the detail page instead of just running the normal page
it would go ahead and do the ChangeBookingStatus, and in
ChangeBookingStatus it would update the Booking inside of the database and then
it could return more information to this page or somewhere else, but this is the
type of life cycle where we go over the different resources like the UI flows
the screens here we have the actions that are available and then going into
working with the entities in the database so all the different layers are
involved all of them are related to each other and they're all part of the
overall life cycle mostly because we generally look at things from a
presentation layer and view versus the data being the model and the logic
sort of being the thing that sort of combines them together in the middle.
Now when we begin to think about the new mobile apps that we wish to build we
want to see how that can potentially be different. From the highest level it's
important to understand that mobile apps aren't going to do that normal
request-response thing because mobile apps are going to be single page
applications the OutSystems 10 compiler is going to generate JavaScript to take
care of the screen logic on the client side and that JavaScript will generate
HTML and the ability to display the screens the way we want them to be
displayed. Whenever those screens need data they will request the data
asynchronously, and OutSystems handles all of that by allowing the data to be
exposed from the backend
as a restful endpoint and those asynchronous actions are not going to
keep the screen from rendering so if something needs to change on the screen
or someone wants to navigate somewhere else
it is not blocked by the fact that we've made a request for data and multiple
requests for data can be inflated at the same time and that can be helpful as well. So
the logic inside of the screens is now specified as client actions instead of
before, anything we wanted
as far as behavior and screens we have to ask the server for help, and it would
always be a server action so there is a interesting difference there.
So when we begin thinking about the new runtime architecture we have this
JavaScript set of code that's running and it's running on the device in a
Model View Controller type of way where some of our data could be local the
overall view is being handled by the react JavaScript components and there is
a controller making sure that all these things work together, and we can still
have plugins and other types of things but whatever we need data we make very
efficient REST calls back to the server to get the logical or data that we need
so if we think about our mobile app and we were going to load it from the very
start we would get a Splash screen to start and the Splash screen would say
that it's loading all the resources in loading all the resources what it's
really doing is talking to the server and getting all of the bits of
JavaScript that it would need and when it we say it's getting all of the
JavaScript if we went into Chrome and Dev Tools and looked at the list of all
the JavaScript that's being downloaded it would be all of the different little
components that are needed as well as the definitions of our app and all of
the pages that might be available in the app so if we thought about going to the
ToDoDetail page we can see that in the ToDo app the main flow has a ToDoDetail
page and that page has a Model View and
a Controller so this screen has capabilities to go ahead and run on the
device because those three parts of the JavaScript are all there to manage things
while it's on the device without having to interact with the server at all.
So once we now are in this new world where basically the Splash screen can
load in the whole app is on the device
other than the dynamic data that we need, we need a new set of events and life
cycles to go ahead and help us manage all of this, and that includes an
application event life cycle so we need to know when the application is ready
and is loaded, and anytime it's ready
that means that the user could eventually basically turn off the app
could basically put it away and then we might at some point when they open it
again need to resume it so once they closed it resumed will occur when they
open it
we need to be able to react that. Once the app opens back up its going to open
to some particular screen and those screens have life cycles now. They know
when they are initialized when they have some of their information ready when
they've been rendered and if and when we need to destroy them and when we say
that there are these lifecycle events the events can occur and when we have
these on OnInitialize is the event that we can get and then we could go ahead
and create some sort of action to say when we know we're at the initialization
stage is there something we'd like to do. So these are basically callback
actions for us to be able to do something when these events in the life
cycle occur. Now that can be fairly important because we're also going to
have screens that may have multiple components so we've mentioned that
blocks are available, we can either pick blocks that have been pre-built, or we
can go ahead and build our own block. If we built our own date picker block and
inside that block the date changes
maybe that date from the block needs to go ahead and affect something else in
the rest of the screen so we need to be able to send that event back and when a
screen is using this date picker it will have to specify a handler so it knows
how to handle that event that can be thrown. So things are a little different
in the fact that the screens will be potentially built up of all of these
blocks. These blocks may need to communicate and the blocks will probably
need data and the data is fetched on the screen level, so the screen will dictate
what type of data it needs blocks could also have data inside of them but all of
that data is fetched asynchronously, and multiple sets of those requests could
occur at the same time. So there's a lot going on inside of a particular screen.
What would be the order or why are these events important or necessary? So if we
think about opening up an app and it begins loading the resources will be a
first screen the default screen that we might need to go to that screen will
begin getting initialized and in the initialization event we could go
ahead and decide to set up some default variables some initial parameters that
are important and then as the screen is initialized after that, it would make any
of the calls for data that it might need so this is the contacts screen it would
say go get all the contacts and for all the people that are in our contacts get
their images. So after initialization requests for data occur, and then it
begins loading up the page and once the DOM has finished loading and the page is
ready we know that the DOM is ready and we would be able to begin seeing
something about the screen because now that the DOM is ready we can begin
rendering the screen.
Well if we're ready to render the screen but we don't have any of our data back
yet and our widgets and components
need data to go ahead and be able to render themselves we would probably want
some sort of spinning wheel saying we're still loading the data. Once the contacts
are back if we need to do anything to the contacts after we have fetched them
there's an OnAfterFetch event and if we then have fetched the data and we have
done any kind of adjustments to the day that we need it would then automatically
cause a render event because inside of the page itself it knows that the
contacts are one of the pieces of data that needs and when the data changes and
is ready then it will re-render the screen to go ahead and display that data
so at this point that renders the screen it doesn't have the images so it shows
placeholders and then it goes ahead and shows the contact. Once the profile
images come in if we need to do anything OnAfterFetch we can do that and then
it renders and it adds the pictures. So you can see here that at different
stages as the screen is progressing in being able to have all the resources it
needs and being able to display the pictures these events and parts of the
life cycle are much more important with the way things will progress and
continue forward. So these life cycle event handlers are fairly specific on
initialize allows us to go ahead and basically occur, do work once we know
that yes a person who's navigating to the screen has permission to get to the
screen, and if we need to do any initialization like settings or default
information we can go ahead and set that OnReady as i mentioned will occur once
the screens and the blocks and DOM is ready and that way you can manipulate
the DOM if you need to. OnRender occurs right after OnReady or OnRender can
occur when anytime the data inside the screen changes so and in this particular
case the OnRender is available to kind of always keep the screen reactive
so that as data updates the screen updates as well. OnAfterFetche is
available for any of our fetching of data and we can then go ahead and use it
to act upon the data that's been retrieved and potentially change
a little bit before we need to display it there's another event that we haven't
introduced yet but we'll talk about in the second, which is OnParametersChanged
and this means that if a parent passed in information to a child block and that
block input needs to change because it changed in the parent screen it would go
ahead and submit that change to the block itself and that way the block can
react to the input that may have changed and at the end there's the OnDestroy and
that just says that whenever the screen and block is done we may want to be able
to do some work to clean things up before it is actually destroyed so that
can be important. Now we looked at loading a screen kind of from scratch
from the very beginning but what happens if we're on a screen and then we go
ahead and ask to go to a new screen, so if we click on one of our contacts we'd
like to go to the contact detail screen. Contact detail screen begins becoming
initialized and the event for destroying our current contacts page is thrown as
well so we understand that this is going to be destroyed we started initializing
the next page and in initializing it, it will go out and say okay
given that you've selected one of these contacts let's get that contact
information by Id so we'll make the data requests and then we'll actually get
back the ability to have the screen be ready so it's been initialized the
data has been kicked off. Once the DOM is ready the screen is ready to be rendered
and at this point if we have said that between this particular screen and the
new destination there's a screen transition that screen transition will
occur so that can be a slide left, slide right, fade in, lots of different screen
transitions, and once it transitions to the new screen then the new screen is
available and can be seen.
So even while the destroy, the initialize, the OnReady and, the beginning of the
render occurs
none of this is actually seeing the user is still seeing the old screen and then
once the OnRender has occurred the screen transition will occur so that
they'll be able to see the data and once the request for the fetch data has
returned it will go ahead and update and show all of that data as well so again
slightly different order and way in which the events occur but it's helpful
to understand how some of this can affect what you're seeing
because it's not the normal life cycle that we might be used to, and then the
last one here is what happens when we change the parameters of a block and
when we change the parameters of a block by saying maybe there's a date and we're
reviewing some data for a particular date if we go in and change the date
then the date has changed in the screen we need to change the block's data and
tell it that it should render itself given the new date that was the input
that allowed it to draw the first graph so once the date has changed parameter
change event occurs and the block is basically told you now need to react
to the parameter that has changed. It begins doing that and it may need to
refresh its expense data so as it begins refreshing its expense data and that
takes a little time it will go ahead and render but it will still have the same
information that it had
before so it's rendering the same look of the graph and nothing changes. Once
the new data comes back then it will render and change both of
the block for the data that's there and the overall screen renders now that the
block has changed as well so we'll be able to see the new page and what
has changed. So these three different types of asynchronous life cycles and
events and handlers can really change the way we're going to be thinking about
things and using the fundamental programming blocks and the fundamental
programming elements that we need, so hopefully this has given you a quick
introduction you can check the documentation for more details on this
and we'll be using these a number of times inside of our exercises.