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

Transcript
Welcome to debugging. In this session
we'd like to discuss the approaches and the tools that we might use to debug our
mobile applications. Different parts of our mobile applications will actually
require different approaches to the debugging. For our server actions which
will be running on the server side will be doing traditional debugging will be
able to set breakpoints control execution flows on the server and
inspect the variables that are there, and we do that from the normal development
environment, so we have the typical tools we might expect there. We also need to be
able to debug some of the logic running on the client side so for that we can
use Chrome Dev Tools while we're working in the emulator we can go ahead and be
able to see more information things coming back both in the console look at
the source of the JavaScript that's available there and get more information
about the network and the application itself. To be able to debug some of these
actions and find where the OutSystems resources are we have a shortcut to be
able to do that and we can also control some of the network capabilities to see
how things will work like offline and then if we do have offline we may have
local storage so we may want to be able to see those resources as well so we're
going to talk about all those capabilities now we also may want to
physically debug the code running in the device and there's ways to do that as
well so instead of just using an emulator we can get to the device there
is documentation available and will point you to that
so let's start with the server-side debugging. On the server side we can
place break points on elements and from their mobile applications we will have
different types of server actions and we'll be able to place the breakpoints
on those server actions. Now to be able to actually do the debugging we need to
start the debugger and this will enable the debugger to register all of the
breakpoints and then
pause the execution of the code whenever we get to one of those breakpoints, and
if we wanted to be able to see we can go to the debugger tab to get more
information about the debugging including the list of break points that
are currently there and from there we could remove the breakpoints we could
disable the breakpoints a lot of nice things to be able to see where the
breakpoints are going to be. Once we stop at a breakpoint down in the debug tab
there are different types of commands that will allow us to control the
execution flow. We can either just stop debugging completely we could abort this
given request we could let this request continue and run on, or if we wanted to
take a more controlled approach we could step over this particular component or
we could step into this particular component so we can step over step into
or if we're in something step out of, and then we can also ask it to break on all
errors so any type of error that we get we'd like to stop because we might want
to go back and be able to inspect some of the variables and do that
so where would we see those well in the debugger tab at the bottom of the
breakpoints will be to our left but here underneath the main parts of the tabs
will be able to see all the variables that are currently in use all of the
local variables any variables tied to widgets any variables that are from the
session or from site and any variables that we put on watches. Now a number of
these are actually used for normal web applications and not all these will
apply to our mobile but we will be able to see the ones and use local and
use the tabs to get more information about the variables and you can see that
the controls that we mentioned are here as well so everything is in the debug tab
together at the bottom of the screen. Now you may have noticed in the previous
screen that when we said we were going to start the debugger it said start the
debugger in the public area and by default whenever we start the debugger
it will start debugging in the public area and that means that it will start
debugging the app
where it's located and that would be on our server and if the app is called MyApp
it will be at MyApp now what that means is that if I place breakpoints
there and there are two or three of us working together on that app if you
begin trying to test the app then those breakpoints are going to apply and it's
going to jump you into the debug mode and you may not want to do that so if I
know there are other people working and I only want to debug things I'm working
on myself and not slow any of those people down I can debug in a personal
area so what will happen there is that the code will be regenerated placed into
MyApp and then your developer login and that way you'll be able to
debug the development that you're working on and it won't
affect any of the other people. So that's pretty nice it not going to impact the
main version it's going to let you do your changes more quickly so that's
fairly nice. Now if you make changes to the actual data model you have to
republish all of the code for the public area and then go
back into the personal area but the only way you can get to the run and debug in
your personal area is from the Debug menu at the top of our development
environment, and one other thing to think about is when we talked earlier
about having applications that have multiple modules by default breakpoints
stop the execution of requests to the module so if we have MyApp breakpoints
and were inside of MyApp, and we're testing it while we're testing MyApp,
the MyApp, breakpoints will will pause the execution and allow us to do our
debugging. If we don't have this particular app, we're not working in this
module to start with we know that we're going to be in another module but we
want to be able to stop the execution for this module's code
then what we can do is set the entry module for that particular set of
code and what that tells the debugger to do is attach to the instance of the code
that is running within the context of the consumer module so here were inside
of OSMDb_Core but we're asking it to start OSMDb so now someone would be
able to navigate to OSMDb and as they're going through that anytime OSMDb uses
the Core we will activate those breakpoints and be able to break at that
place. So when we have multiple modules we may need to be careful as to which
one we're selecting for the entry module to be able to get to the breakpoints in
the way we want to get to them. So this is all on the server side we also need to
be able to go ahead and handle things on the client side, so in this particular
case what we really say when we're debugging is will be debugging inside of
the browser and the browser running an emulator so for our mobile devices we
can go ahead and select the mobile device and the emulator we'll go ahead
and place the circle and that will basically be our touch so we have
touch-enabled emulators that should be able to give us the same type of
information that we might get from the device and here you can see the touch is
enabled in a way where I'm actually sliding using a gesture sliding our
sidebar from the left-hand side over and then going ahead and and letting it go
to do some searches so we do have the capability of having the touch-enabled
stuff and when we come to do any of the different types of work we can always
take any of the resources that are there and inspect them so if we right-click on
the star and we want to see something more about the star we could go ahead
and inspect that and inspecting this will bring up Chrome's Developer Tools
so we say we're using the emulator in the browser we need to be using the
Chrome
browser to be able to do this type of client-side debugging because we're
going to be using Chrome Developer Tools so you can open the Developer Tools from
the menu at the top, saying that you would just like more tools and Developer
Tools or you can just go to any resource that's in the device in the emulator and
right click on it and say inspect. Now when we do that if we ask it to
inspect the gold star that is near the test device camera it will open the
Chrome developer tools and here you can see on the right-hand side it has opened
up the Chrome developer tools and it's actually tracking the fact that we're
working with the gold star so we can see that there's a link on the gold star
here is the icon that it's actually using and how it's displaying
it so up at the top we can see the actual elements we can see the styles
that are applied to it and down below in the console we can see information about
the requests and other things that are going on. So Chrome developer tools are
really nice because it can give us all this information about the JavaScript
that we're running inside the device now one of the things that can be a bit
problematic is that we're in a browser running an emulator and we want to see
all of this other information so you can leave it docked on the right-hand side
you could dock it at the bottom depending on the size of your screen you
may want to actually undock the window and keep the tools in a separate window.
They'll still react to whatever is happening inside of the device but we
would be able to have more real estate to see what's going on
so if we did that we'd still be able to see everything that's in the other
window and now we have a lot more space to be able to see the elements that are
there the styles that are available and things like that.
Now one thing you may have noticed down in the console is it says that if we
want to debug a client action then we should hold down the CTRL key while
using the app, and if we want to debug server actions we can just add break
points to any of the
server actions in Service Studio so we already talked about all the server
actions and server-side debugging, but here we can actually debug a client
action by holding down the CTRL key so what we might do there is we might
come over to our gold star place the touch there and use the CTRL key and
click it and if we click the CTRL key over the gold star what we'll see is
that the StarOnClickAction will be activated. The StarOnClickAction is
what goes ahead and changes the state of the star and stores that in the database
so we can go ahead and open that up and when we open it up it stops at the
debugger line, and at the debugger line it basically says at this point you're
near the StarOnClick capability and this below is all the things that it
needs to do, and at that point we can come up and we can step over each piece
of this JavaScript we can step into things that might be other functions in
other areas we can come back out of it or we can just continue letting the
script run as it started. So we can do all those things which are pretty cool
now some JavaScript can get fairly complicated and when it starts getting
complicated it's difficult to read
so what we may want to do is actually create or ask for the pretty version of
these files so you can either do that by clicking this little set of brackets at
the bottom or asking for the pretty minified file and it will open another tab
and it will shift everything and try to make the code look as easy as possible
to be able to read and follow so here it's a little bit quicker and easier to
see that this is the StarOnClickAction and here are all the things that
are related and contained inside of that action so lots of nice ways of being
able to see what's going on if we need to get down to the JavaScript level. Now
the JavaScript that we're looking at here is
the sources tab so the console is duplicated down here at the bottom
before we were inspecting the elements and now we're looking at the source and
in this particular case it tells you that we're looking at the ToDo main
source so the MainFlow has some source and we may want to be able to see where
that is so if we came over to the left hand side this is a list of all of the
sources. These sources that we're looking at right now are actually in the
contents of our ToDos, so the contents of the frame and what's happening are all
there inside of the ToDo if we wanted to go ahead and inspect those further we
could go to the server that we're on open the ToDos that we're looking for
and then go down to the script, and as we get down to the scripts there will be a
very large number of scripts because there are things here for buttons and
button groups because we're using those so each different widget and component
that we're using will have a JavaScript file here including things like the
plugins, so we have the capability of using the camera plugin and you can see
that here as well so there are a large list of these and if we wanted to see
where ToDo main is, we would just scroll down and be able to find ToDo main but
it's a little quicker and easier to go ahead and find the action just hit CTRL
click and jump into it. So here we can see the sources and be able to see all
the things that we need from a JavaScript perspective. If we also want
to be able to control the network maybe do some offline testing or be able to
see how this might work if we're going to bad network connection, Chrome
dev tools does a really nice job of either letting us know we're offline so
if we check offline and we make another request the phone will be notified that
it's offline and then it can change its behavior and attempt to react to that we
also can use this networking area to go ahead and see what different network
connections might look like so here there's no throttling if we go ahead and
make a request it shows us how long it takes
and it says that to load all the DOM it took a second and overall it took a
little more than two seconds.
Well what if we wanted to go ahead and say you know what instead of maybe
having a full-blown Wi-Fi connection or 4G connection with no throttling what
happens if i only have a 3G connection?
Well having a 3G connection connection takes a little bit longer and
takes almost three seconds to load so it begins
simulating and showing us each of the different resources that needs to be
loaded and how long it took, so here we needed 216 requests and they're only 76 KB
to go ahead and load over that time. Now that gives us a lot of information
about the JavaScript, we can sort of set breakpoints and move along the different
types of JavaScript we can look at the network connections, but we said we also
could test offline and for testing offline
could we see what's in local storage? The answer is yes. If we go to the
applications tab and look down inside of storage there is something called local
storage but that isn't where were storing our local storage entities so
this is a local storage that has different types of information inside of
similar more toward how its stores session information, so that's all
browser related and devtools related for us the the data that we actually want is
in the WebSQL that's where the local storage entities are so here you can see
our ToDo application and the ToDo has several different tables so if we go
down and look at the actual ToDo table we can see the five ToDos that were being
stored locally and being shown inside of our device, so this is one way where we
know what the different tables are and it will show us the list of tables and
we can just go look at one of those, but instead of having something simple like
five ToDos is we may have thousands of rows of data
well what could we do there if you go up to the top of the app and ask it you can
go ahead and give it a regular SQL query so here we know that the ToDos
are in this particular table so we could say select * from that table and we
all the data back we would have got that by just clicking on it but we can make a
much more involved SQL query to get a subset of the data to come back to us.
So we have access to local storage as well so dev tools is pretty cool
we have the capability of seeing a lot of the different parts of our mobile app
and getting more information about it, but this is still all in devtools and
it's still in the emulator what if we want to debug code actually running in
the device
well OutSystems 10 documentation has a section called debug code running in the
device and it goes into how we can look at the screens the different types of
actions and logic and look at local storage by actually connecting Chrome or
Safari and making sure that when it connects to the device we have the
capability of seeing more info, so again in this case we'd be using the Chrome
devtools just like we talked about with the emulator but the only difference is
now we use the Chrome devtools connected to the device to be able to see more, and
a lot of times we want to we may want to be able to do that to try to get a
better idea of what's going on with local storage because that's probably
the only easy way to be able to see what's going on. Now there's also other
types of problems that can come up that we may need to debug, if we're working
with mobile plugins and we might have one of the ones that supported by OutSystems
and its built-in we could go ahead and begin troubleshooting or
debugging that with OutSystems Now and if you've created your own plugins or
you want to be able to actually get down to the native code level because you're
having some sort of crash you need to go ahead and create a debug or dev build
of your mobile app and then use something like XCode or Android Studio
to go ahead and see that information. So in this section we gave sort of a
high-level overview of when we have mobile apps their server actions so we
have to use the server-side debugging that we would typically use, if we want
to be able to see more about the client-side Chrome devtools gives us
lots of great capabilities to
look at different things from the JavaScript itself and and step through
it to the network to the local storage so hopefully this gets you started and
you'll be able to learn more and debug more about your applications as you move