Mobile Development Basics
What's New in OutSystems 10
This lesson is part of the Developing OutSystems Mobile Apps course.
LEARN MORE

Transcript
Welcome to What's New in OutSystems 10. In this session we'd like to discuss all
the new capabilities that have been included in OutSystems 10. A lot of the
new capabilities revolve around mobile apps which include being able to create
new mobile user interfaces, also looking at the new mobile app architecture that
includes the capability of doing offline, as well as using extensible components
like plugins and other types of things. We also have the ability to generate a
native app for iOS or Android so a lot of really great things to talk about
from a mobile app perspective. But we didn't leave out the Web site as well.
There is an overall improvement in the developer experience and that includes a
number of new capabilities as well as several improved existing capabilities.
So let's go ahead and get started looking at all of the new capabilities.
So when we think about what's new for mobile apps we can begin comparing what
we can do with mobile apps to what we can do with Web apps in the past. So if
we do a side-by-side comparison, we can see that the Web apps were running
server-side logic they were storing things in the database making
synchronous requests from the browser to the server, and it was a request-response
pattern where the page had to be refreshed each time or at least a
component of the page if we were using AJAX. Now in our new mobile apps will
have server and client side logic so there will be logic that can run inside
the device as well as calling the server and having some of the logic run on the
server. Data can be stored in the server-side database or in local storage
on the device itself and when requests are made from the device they will be
made to the server and when they're made to the server they're made asynchronously
so that we can make several of these requests in parallel and then we can
react whenever the data comes back. And the overall user interface is reactive
itself, so if any of the data changes or we need
move to a different screen, the mobile app will attempt to handle all that on its
own and will only call the server when it needs data or other information. So in
general you can refer to this whole new architecture as a common pattern that
people refer to as a single page application. So our mobile apps will have
a different look and feel and a very different way of interacting, so let's
jump into the details of how all of that works. So there will be a number of
improvements to the mobile interfaces. Mobile interfaces will have new
templates and there'll be a phone template, a tablet template and a
universal template, and those templates do have a common set of resources and
patterns that are available to them and will help us get started making really
great-looking mobile apps. To be able to do that we start with the pattern which
is nice, with the template which is nice, but then we need to add patterns
as we go along.
So there have been dozens of mobile patterns that have been
identified that are easy to use and are things that we would often want to add
to a screen in a mobile device. So we may have things like different types of
icons and tags, we may have counters and different types of buttons or
floating actions that we want to make available on those screens. So these
patterns will be available they're easy to use, we'll be able to drag and drop
them, they'll adjust to the form factor, depending on whether it's the phone
template or the tablet template, and they end up looking really great. So both the
templates and the patterns are things that we've had in OutSystems 9
previously and you may have heard them referred to as Silk UI templates and
patterns and Silk UI has now been extended to go ahead and help us in our mobile
apps and all of these templates and patterns are specific to mobile.
We've also gone back inside of the Service Studio Toolbox and looked at the
baseline widgets that we have,
and the baseline widgets for mobile apps have been changed or upgraded, so that
when we create a mobile app the icons, the lists, the button groups and other
types of things will be a little bit different.
They've been optimized for touch so that if we need to do gestures or different
types of swiping we'll be able to use those, and it will be easy to do that.
Now some of the widgets are enabled for these types of swipes and gestures and
some of them aren't so there has been a capability, a set of patterns added, to be
able to do gestures, so that we can basically put in a gesture wherever we
need to be able to do that and we'll get slightly different behavior. Now some of
the widgets and the patterns
besides being able to handle gestures will also have animation inside of them
so if we want something to sort of look more natural, the animation properties
can be enabled or disabled depending on the type of look and feel that we want.
And for some of the widgets that don't have animations, there is an animation
pattern that we could apply to different types of widgets, and when these
animations occur we need them to look really smooth and great so they'll
render at 60 frames a second.
Now that's the animations for the widgets and the patterns which are sort
of on a smaller scale. When we decide to navigate between screens whenever we go
to a new destination, we have the capability of sliding or fading into a
destination and depending on the type of transition that we choose if we actually
navigate back to the previous screen it will reverse the transition and this
kind of makes it very natural for users to kind of begin understanding where the
screens live and whether they're on the left or the right and and be able to
swipe back and forth. So along with those user interface improvements, we have the
capability of opening any screen, so if we create a mobile screen and we want
to look at any one of them, we don't have to go to the default screen immediately,
we can open any one of the screens and jump to it
very quickly. We also have the ability now to have expressions in our styles,
and that gives us the capability of having dynamic styles that will react to
the values of the expressions that we put inside those styles, so we can now
have dynamic styles that will change as things inside of the application change.
We also, when we drag and drop some of our patterns to the screens, we now have
placeholders that can hold sample data, and that makes it easier to visualize
the pattern and overall it makes it very easy to work with
so it's a nice thing to have. So let's take a look at the new application
architecture. Our new runtime architecture for mobile apps includes a
Model-View controller pattern. So when we're going to run things on the client
device everything that's running on the client will be run inside of JavaScript
and it will have a Model-View controlling pattern that's inside of it,
based on React, and those React components will have the ability to run
their own logic and have their own behaviours on the client side. It will be
extensible, it will be able to put Cordova plugins to access all of the native sensors
and native capabilities, and when the device needs more information or data it
will be making REST calls back to the server. And as we begin developing these,
when we see these interactions occurring, our platform is going to go ahead and
generate the RESTful endpoints on the server side and then go ahead and
respond back to the device so we'll get all the information that it needs. So two
different sets of information: there can be logic on both sides, there can be
data on both sides because the device side can actually have local storage so
that it can work offline as well, so let's look at a few more details of the
run-time
architecture. One of the things that's been added is there are new app
events. When we create client actions
the app may need to know when the application has become ready so the user
has opened the app for the first time and sometimes they'll open the app and
then they'll close it. When the application resumes, we need to be able
to know when the applications resume so we can react to that as well.
Now once we know the app is open and we're able to work with it, we'll be on a
particular screen. The screen has different life cycle events that are now
available. We need to know when the screen is beginning to initialize, when
the screen is ready and the DOM is fully formed so that we're able to work
with it, when the screen is going to render, and once all that's done if we no
longer need the screen, when the screen will be destroyed. So these are events
that are basically hooks that allow us to go ahead and create actions to
respond to those steps inside of the life cycle, and that gives us more
control over how we can build our user interfaces. To continue to be able to do
even more,
we want to be able to use blocks and events. So the blocks are available as
reusable components, and the blocks may have some sort of event that will signal
changes to whoever the parent is and typically we will put blocks inside of
other blocks or inside of screens, and those events may tell them something
that has happened and share certain types of data, and then the screen would
have some sort of handler to go ahead and react to the event. So if we created
a datepicker block that allowed someone to pick a date,
it could throw a "date has changed" event, so when the DateChanged event occurs
if any other component begins using the datepicker, it would need to specify the
the following information about the date picker: it would need to specify what
handler is going to handle the date changed event
and then it would create a local variable to go ahead and hold the new
date that was going to be passed in to this particular method, because that's
part of the event that's being thrown. So a lot of nice flexibility there so that
we can create more modular components and smaller parts of screens
and then have them interact with each other and interact with the screen in
general.
Now once the screen is defined then we have this life cycle and we know the
different components that are in different areas of the screen, they're
going to need data and when they need data the aggregates now are attached
directly to the screen. And the aggregates can be opened and when we
open the aggregates we can actually see the entities attributes and how the
entity data structure exists there. There are also these data actions for advanced
cases and whenever we make calls to either server aggregates, to local
storage aggregates or to these data actions, they're performed asynchronously, so
all three of these calls can be made in parallel and then depending on the size
and the speed they may come back at different times because they've been
made asynchronously. So that means that the screen and the device will
be getting its data at different points and we want the screens to be as
responsive as possible so the UI elements are going to react to any local
data changes and those changes will occur immediately. There is this
virtualization mechanism that will only render items that can be seen on the
screen, so there's an optimization there so that we're not spending cycles doing
things that can't be seen by the user. And then the UI will respond while the
server is being called, so if we need some data we can make the call
asynchronously, but the UI isn't frozen waiting for that response to come back
we can continue to go on and do other things. So that makes the client side
user interface very reactive and that's great. We also have logic on the client
side and those are client actions. And the client actions will be modeled
visually they have a slightly different set of icons, but we're going to be using
the same knowledge that we had from OutSystems 9 to be able to go ahead and
model these, we'll be able to drag-and-drop different types of actions,
including server actions, and when we call the server those RESTful APIs will
be generated automatically for us so we don't have to worry about the
communication with the server directly, and then all those calls would be made
asynchronously as we mentioned. Now we also need the capability of handling
exceptions a little bit better so there are now OnException flows and they have
the same type of capabilities as action flows, and those will end up having
exception handlers so we can define the logic for any type of unhandled error
and then we can also send messages back to the user describing what type of
exception has occurred and giving them more information.
Another thing that's been added is that the module itself has a global
exception handler and that means that that will be the flow to handle any of
the errors that haven't been caught up until that point. And then finally we
want the capability inside of our mobile apps to get to the native capabilities
of the device, so we can add plugins to what we're doing at any given time and
that will give us access to what happens inside of the device. There are some network
capabilities as far as when we're going to be making these asynchronous requests
to the server,
how long should we wait before we timeout, so because they're asynchronous
they sort of need to know and handle some of that themselves and they need to
be able to react to the network status so because we're on a mobile device
sometimes we will be offline or we'll have a slower connection they need to be
able to know the type of connection and whether or not they're currently
on or offline, and all of that is built in. And as we're developing for all of
these things, we need to understand the types of calls we're making to the server
how often and what could be happening that would affect our overall
performance, so there are a new set of warnings that are available and they
basically try to detect all of the scalability and communication
anti-patterns, so that we know when we're doing something that that may affect the
performance of our mobile app. So anything that might delay the screen
rendering any time or making multiple server action calls together, we could
probably bundle those up, so a lot of really good scalability warnings to help
make sure our mobile apps will have great performance.
Another thing we could do to improve the performances is not make as many server
calls and store some of the data locally so a new set of capabilities called
local storage have been incorporated so now we not only have database entities,
but we can have local storage entities and the local storage entities will hold
all of their data locally the data will be available to the device at any given
time. So they are very similar to the database entities, the only difference is
that they're going to be stored locally on the device. We can still use
aggregates to query that data and we can actually take a database entity and say
we'd like to duplicate it as a local storage entity to make it easier to copy
the data back and forth from the device to the server. To be able to do all of that
we need some sort of synchronization approach or synchronization pattern, so
to be able to do synchronization a little easier between our local storage
entities and the server entities there are some new actions so the entity
actions have the normal entity actions that you'd expect, but there's also a DeleteAll
and a CreateOrUpdateAll and those two new actions are there so that
when we're taking all of
something like the tasks on our device and we're trying to push them to the
server we can go ahead and create them all at once. Now there's also been a
basic framework set up to help do synchronizations in general, so there are
a number of client actions and there is a server action that have been built to
kind of be the framework to be able to do that. So anytime we want to do a data
synchronization we can call OfflineDataSync and it will call ServerDataSync.
So we can learn more about that pattern later, but the synchronization framework
is there and it makes it a whole lot easier to do which is great because
offline can be a complicated thing to do. So that takes care of the new
application architecture.
What else do we have as far as extensibility? Well you can go ahead and
use native code inside of reusable plugins so you can use Java or
Objective C or Swift, create some plugins and then we can go ahead and incorporate
the plug-in into the mobile app. We also may want to take advantage of JavaScript
because now we do have logic running on the client device and it's running
inside of a React Framework then we could add extra javascript and be able
to work with that as well. So we can add JavaScript libraries for any types of
information that we need and then if we're working with those libraries and
we need to edit some things there's now a special JavaScript editor that has
things like autocomplete and other things inside of it that make it really
fun and easy to work with.
There are also a number of other extensions: we have a new HTML widget
that will let you create specific HTML components, we have CSS classes that will
detect whether or not you're on the phone or the tablet and whether is in
the portrait or the landscape orientation and that will allow our
devices and our apps to to react to how the device is being used a little bit
better. Because there's a lot of JavaScript going on back and forth we
have the capability of doing JSON serialization and deserialization so
there are specific
tools in the toolbox to be able to help us do that when we're inside of action
flows trying to to work with JSON. And then we have these things called UI
extensions. So on any given type of component we can add attributes or
events to the widgets that are there. So we can get down to the attribute area
and add things to them and then they also can have events, so if we have
something like an icon and we want to go ahead and add an OnClick event to that
icon, we can do that, and then define which handler will be doing the work.
So that gives us a lot of new capabilities to extend the base widgets and patterns
that are there. Once we've done all that we'd like to be able to generate an app
and be able to make it available on the app store or just at least take the
bundle and go ahead and install it on our phone. So to do that for iOS we need
to go out and get a developer certificate and have a developer profile
and for Android we basically just need to go out and register and get a
Keystore. And once we have that we'd be able to come in and click the Generate
button and it will generate the apps. So once we've done our development there is
a Generate tab that takes us into an area that allows us to generate the
native mobile apps, and when that occurs Service Center will actually keep track
of when the native apps have been generated, if there were any problems, and
it can help us sort of troubleshoot anything that might have been wrong with
what was happening during the generation process. We also want to be able to keep
track of the different versions. Now as we're creating the mobile app, we know
that OutSystems has its own versioning and it will keep track of the
application version for us and we can tag that, so we know when we're going to
move between different environments which version we're working with, but we
also need to know the mobile version itself and if the mobile version for
Apple has a particular version number
and the Android has a different version number, and it when we may need that to
occur because we've generated them at different times, we can go ahead and keep
track of all of that inside of Lifetime and here you can see at this
point the iOS, the app version, the Apple version, of our application is on both
and is available in production, where our Android is still in development and we
would want to be able to deploy it to production. So besides the versioning we
also want to know when the application has been updated, do we actually have to
create a new version of the app or not. So for a lot of UI logic and data
changes you won't need to go ahead and generate a new version and then put it
out on the store, have people download it. There will be automatic updates inside
the app because the shell will detect the changes, be able to download the
changes from the server, and be able to work with them. And then while we're
doing all of these updates and things in development we'd like to be able to
test them. So it'd be great if we could test inside of the development
environment itself ,test on the device if we need to,
and that means we would need to go through this generation process, or we
can use OutSystems Now and for those of you that might be familiar with OutSystems Now
that will allow us to get to the different apps that are on the
server and you won't actually have to do the generation process, but you'll still
be able to run the app in the device, which is kind of cool. So that takes care
of all of the new mobile stuff and there's an awful lot there, but that isn't all
that was done for OutSystems 10, there were a lot more improvements as well and
that includes when we get into the application area there are new icons so
we don't have to have all of the same looking icons if you don't create your
own custom icon, now you can go and at least specify a color and it will take
some of the letters out of your application's name to begin giving it a
custom icon.
If you want you can still upload your own icon, and it will select some of the
base colors from that.
There's also been an improvement to the toolbox. We used to have a very narrow
and thin toolbox,
now we have a wider toolbox with larger icons with easier labels to see and we
have the capability of searching for the different widgets or patterns that we're
looking for.
So because they are a little bit bigger there is more scrolling that may occur
to keep you from having to scroll too much the search is available.
Now there are some brand new capabilities have been added: now you can clone an
extension. So you could always clone a regular module, now you can clone an
extension module as well.
The exceptions have been upgraded so that when we go to the exceptions area
you can drag and drop an exception to a flow whenever you need to.
And there's a new set of system actions that focus on lists, because we now may be
sending information back and forth in large quantities, so there's a set of
list actions that are available as both client actions and server actions, and
this should make things a lot easier when we get stuck inside of loops
dealing with lists, these should all help us, these actions these operations, should
help us be able to do that much easier. Now there's also a number of TrueChange
warnings that have been added so that we don't have a cluttered development
environment. If there are a number of unused elements it will warn us that "hey
maybe you changed something and you no longer need this element" so we'll be
able to look at that and "yes i'm going to use it later" or "no it's
truly an unused element", and if it is an unused element why not just remove it,
and we can do that on a per reference or on a per module basis. Along those same
lines of removing things we don't need, it'd be great to be able to manage
dependencies, and many times when we're working with different modules and we
have dependencies we might have multiple dependencies,
and if some of them change at the same time, it would be great to refresh them
without having to come in and click on each one, so there's the new Refresh All
button which makes it a little bit easier to refresh all of our references
at once and the icons that are being used should make it a little bit easier
to see when we do have a dependency that needs to be refreshed. Also from a data
perspective, when we're in service studio working with data, if we're in an Aggregate
and we'd like to be able to see more information about the contact entity, we
can jump directly to the contact entity by hitting the new eyeball. We also want
to be able to see sort of the data in the Aggregate form from the entity so
now if you right-click on the entity and say View Data, it basically opens up the
base entity and pulls back all of the information as if we had just a simple
Aggregate, and then again the individual screens will now own the data and the
calls to fetch data. So here our home screen is getting the Contacts and we
can see that the Contacts are coming from the local store so it's a local
contact and that the type hierarchy is right here so that we don't have to jump to
the Data tab to see what are all of the attributes for a contact, so that makes
things a lot easier for us to drag-and-drop and build the screens
quicker. We also will have to do more assignments and the assignment mapping
capability now has the capability of doing conversions.
So if we have one element like a Contact and we know that we have a current list
of users and the users and the contacts are similar
how will we map back and forth? And it will attempt to find attributes that are
the same and map all those elements.
The other thing that we might have run into as a problem with the Assignments
is that a lot of times once you created one to delete it you had to delete both
sides of the Assignment.
Now you can just select any Assignment, right click and say Delete Assignment
or use Ctrl-D and it'll take that whole Assignment and remove it.
And then from a readability and documentation perspective we now have a
little bit nicer expression editing capabilities. We can add single and multi
line comments
any time we need and there is now parentheses matching, so once you put in
one parentheses it will highlight the other, one so that you can see which
sections of code you're working on. The switch has been improved so that you can
put labels on all of the different switch paths, and occasionally we might have
dragged-and-dropped new elements into a flow and it would somehow misalign the
overall flow making it kind of annoying and we would have to go back and do some work
to kind of do that. That's not going to happen anymore so your flows will all
stay nice and all of your icons if you keep them well aligned will will stay
well aligned. And last but certainly not least, there have been a lot of
security improvements. All of the security best practices about code injection and
redirects are inside the platform, the mobile authentication capabilities
have been added,
there have been new protections for brute force logins, there's advanced
capabilities to configure the network and HTTPS now, as well as being able to
specify that you want a Strict Transport Policy, and you can also go in and talk
about the Content Security Policy so there have been a lot of improvements in
security as well. So that's a huge amount of new stuff inside of OutSystems 10,
a lot of it is focused on all of our new capabilities to help us build mobile
apps but we also saw that there have been some improvements just in how the
developer is going to work inside of Service Studio so our experience as
developers should be a whole lot easier and a lot quicker. So hopefully this gave you a
great intro to what's new inside of OutSystems 10 and you'll spend some time
playing with all the new
features.