Creating Apps for use on Android mobile phones

[jacque]

The button labels look fine to me. Do you mean the text in the field is too large? That would be the font the device is using. You can either make your fields wider, or assign a different font to the stack. Android's default font is Roboto. You can download and install it on your computer and develop your app with it. That way it will look the same on both the computer and the device. Roboto is here: https://fonts.google.com/specimen/Roboto

We can't really help you with the scripts unless you tell us what they are.

[Dragondos2020]

Thanks again for responding. I have downloaded the Roboto Fonts and installed. I have changed all the fonts within the application to Roboto. I have also changed the fullscreenmode from "letterbox" to "showAll". There has been an improvement in the look of the app on the different screens.

With regards to the script. I provide the following:

On the main screen of my app I have a datagrid which successfully loads the data and displays as expected within the datagrid. If I select a record the app works fine and moves the screen to the left and display the individual record selected. All good so far. I am able to enter the data into the required fields. All OK. On the card showing the individual record details, there are two buttons (plus the Navigation Bar displayed at the bottom of the screen). The two buttons are labeled 'Update Details' and 'Delete Member'. If I run this app from within the LiveCode Environment, then the 'Update Details' button' does update the database with the amended data. The'Delete Member' button also does what it is programmed to do, and that is it Deletes the Member Record from the Database. When I run the app on the emulator, I can use move from card to card using the 'Navigation Bar' with no problems. However, the 'Update Details' button does not update the database with the amended data, and the 'Delete Member' button does not delete the record from the database. This applies the same to any other button that I have placed on the different cards. It is only the 'Navigation Bar' that works.

Thanks to FourthWorld for putting the images onto this forum. If you look at the last image of the four. This is the screen that shows the individual record details. Plus the 'Navigation Bar', the 'Update Details' and 'Delete member' buttons which the script below refers to.


I have included below the scripts used for the 'Navigation Bar' and the scripts used for the 'Update Details' and 'Delete Member'

'Navigation Bar'
on hiliteChanged
local pName
get the hilitedItemName of widget "Navigation Bar"
go to card it
set the hilitedItemName of widget "Navigation Bar" to it
end hiliteChanged

'Update Details' Button
global gConnID

on mouseUp
local tUserID, tSQL, tColumnToUpdate, tNewValue, tTmp, tResult, tDatabaseID
local tFirst, tLast, membersName
put gConnID into tDatabaseID
put field "lblRecordID" into tUserID

put "Fname" into tColumnToUpdate
put field "txtFname" into it
put field "txtFname" into tFirst
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Lname" into tColumnToUpdate
put field "txtLname" into it
put field "txtLname" into tLast
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Addr1" into tColumnToUpdate
put field "txtAddr1" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Addr2" into tColumnToUpdate
put field "txtAddr2" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Addr3" into tColumnToUpdate
put field "txtAddr3" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Addr4" into tColumnToUpdate
put field "txtAddr4" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Postcode" into tColumnToUpdate
put field "txtPostcode" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Joindate" into tColumnToUpdate
put field "txtDate" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Fee" into tColumnToUpdate
put field "txtFee" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Paid" into tColumnToUpdate
put field "txtPaid" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Membership" into tColumnToUpdate
put the label of button "cboMembership" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Phone" into tColumnToUpdate
put field "txtTelephone" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Mobile" into tColumnToUpdate
put field "txtMobile" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put "Email" into tColumnToUpdate
put field "txtEmail" into it
put "'" & cleanSQL(it) & "'" into tNewValue
put "UPDATE members SET " & tColumnToUpdate & "=" & tNewValue & " WHERE member_id=" & tUserID into tSQL
put revdb_execute(tDatabaseID, tSQL) into tTmp

put tFirst && tLast into membersName
answer information "Member's Data Updated!" titled membersName
end mouseUp

function cleanSQL pSQL
replace "'" with "''" in pSQL
replace quote with quote & quote in pSQL
replace return with "*RETURN*" in pSQL
replace tab with "*TAB*" in pSQL
return pSQL
end cleanSQL

'Delete Member' Button
global gConnID

on mouseUp
answer warning "Are you SURE you want to DELETE this Member's Details?" with "Yes" or "No"
if it is "Yes" then
local tRowData, tSQL, tResult, tDatabaseID, tID, tCmd
put gConnID into tDatabaseID
put the text of field "lblRecordID" into tID
put "DELETE FROM members WHERE member_id = " & tID into tCmd
revExecuteSQL tDatabaseID, tCmd
put the result into tResult
if tResult is not a number then
answer error "There was a problem deleting this record:" & tResult as sheet
end if
end if
visual effect "push" left fast
go to card "members"
end mouseUp

I really hope that the above information throws some light on the problem I am experiencing. Thank you all for your assistance and patience.

[FourthWorld]

Thanks again for providing the screen shots. They're especially useful for understanding the full scope of options for handling your app's layout.

We have two general approaches for adapting our layouts to work well on the wide range of today's mobile devices, FullScreenMode and Responsive Design.

At the moment our community is at a disadvantage, because we have a good tutorial on using FullScreenMode, but none of all for using common Responsive Design principles in LiveCode.

Here's the link to the Lesson on fullScreenMode:
http://lessons.livecode.com/m/15262/l/5 ... ll-devices

I've requested access to the proprietary tool used to produce the Lessons so I can add one about Responsive Design. In the meantime, here are some notes which can help you get started evaluating which is the best option for your app:

A Brief Introduction to Responsive Design in LiveCode

Understanding the Challenge and the Options

FullScreenMode is by far the easiest to implement, and the one that's been more practical to use for longer within LiveCode.

Responsive Design is by far the most commonly used by both native and web app designers, though like anything else in a scripting language it will require some scripting to use.

Let's first step back and consider the problem, and then we can evaluate how each option applies.

Modern screens come in a wide range of sizes and ratios, and support two orientations. And because mobile screens are much smaller than the ones we enjoy on the desktop, we want to think about things carefully to make the best use of every pixel.

If you make a fixed layout for a 4" phone in portrait orientation, running it on a full-size tablet will take those buttons you've lovingly arranged to be a comfortable fit for a finger and enlarge them to the size of a fist. And if you rotate the orientation of the device, there will be empty space on either size, and the top and bottom of your layout will be beyond the edges of the display. And even in other devices of similar size and also in portrait mode, a different ratio can still produce some padding and/or cropping.


FullScreenMode makes short work of allowing your app's layout to scale to fit the target device by automating one of several combinations of cropping, padding, shrinking, and/or stretching effects, or some combination of those depending on the mode chosen.

For some apps it's a truly optimal choice, esp. some types of games where only one orientation is allowed, there are no standard controls so scalling looks good, and meaningful content is limited to the center of the screen, so padding/cropping pose no impairment at all. The great game Monument Valley is a shining example of this, looking gorgeous on small phones and big tablets alike, at ratios from 3x4 to 9x16 and everything in between.


Responsive Design places screen elements in specific locations based on screen dimensions, usually relative to the edges of the screen or other objects so placement adjusts itself automatically to fit any dimensions, ratios, or orientations.

Responsive Design can even support different layouts at different sizes, such as exposing more controls on a tablet while having those tucked away in a flyout panel on a smaller device.

You'll find examples of Responsive Design in most web sites, and most of the apps on your phone, including gMail, Facebook, YouTube, Amazon, and most others.


Putting Reponsive Design to Work

Let's take a look at Responsive Design in action:

I've taken the liberty of reproducing a mock-up of your app based on the screen shots. I chose the most complex layout, the one with the most controls, as a test case for how we might approach this.

What we see in your layout is a common design pattern: header at the top, footer at the bottom, and a content region in between. The header and footer are of a fixed height, and run full-bleed to the edges of the screen, and the content region is the space available in between them.

What we need is a way for our app to be notified when the screen dimensions change, either when the app is launched or when orientation is changed. The resizeStack message provides this notification.

Putting this to work to handle your layout requres only one line for each major region of your layout, header, content, and footer nav:

Code: Select all

on resizeStack x,y
  put 60 into tRowSize
  -- Header - fixed height, full bleed:
  set the rect of btn "header" to 0,0,x, tRowSize
  -- Content Region
  set the rect of grp "ContentRegion" to 0, tRowSize, x, y-tRowSize
  -- Footer - fixed height, full bleed:
  set the rect of widget "NavBar" to 0,y-tRowSize,x,y
end resizeStack

The tricky part is usually the content region, and your layout is no exception. With more than a dozen controls, we don't want to hand-code the arithmetic for all those if we can avoid it.

Fortunately, LiveCode supports a resizeControl message for groups, which lets a group be self-contained in managing its contents. Using that message within a group simplifies the arithmetic tremendously, and also allows the group to be repurposed in other layouts while still preserving its clean interrior appearance.

If I were to limit the apps to work in portrait orientation only, I could just set the loc of the content region group to the loc of the card and be done with it.

But this exercise was too simple, so to make it more challenging I decided landscape mode should be an option.

I noticed the fields tend to fall into two conceptually-related categories, contact info and membership info. This lend itself nicely to putting each into its own group, so they could be placed side-by-side in landscape while stacked in portrait.

Here's the code for the "ContentRegion" group that handles that:

Code: Select all

on resizeControl
  -- Allow the user to enjoy whichever orientation
  -- they prefer with responsive design:
  --
  put item 1 of the loc of me into tMidX
  put item 2 of the loc of me into tMidY
  --
  if the width of this cd < the height of this cd then
    -- Portrait:
    set the loc of grp "UserInfo" to \
          tMidX, tMidY - (the formattedHeight of grp "UserInfo" div 2)
    set the loc of grp "MembershipInfo" to \
          tMidX, tMidY + (the formattedHeight of grp "MembershipInfo" div 2)
  else
    -- Landscape:
    set the loc of grp "UserInfo" to \
           tMidX - (the formattedWidth of grp "UserInfo" div 2), tMidY
    set the loc of grp "MembershipInfo" to \
          tMidX + (the formattedWidth of grp "MembershipInfo" div 2), tMidY
  end if
  --
end resizeControl

There we have it.

All in all, I spent just a few minutes dragging out the controls, and about half as much time writing the code to maintain their tidiness on every possible device type LiveCode supports.

Comments aside, in just 9 lines we can handle attractive placement on any device in any orientation.

Coupled with the three lines in the card script, we now have full bleed for the header and footer, attractive placement of the form fields and buttons, and this layout will adjust itself to fit every screen size, ratio, and orientation.

And that is indeed "every": one more advantage to Responsive Design is that you can see the results right in the IDE as you're working, reducing the number of build-load-test cycles needed just to see how things look. Just resize the window in the IDE and the layout updates itself as you go.

Here's the sample mock-up stack:

ResizeExample.zip

(2.8 KiB) Downloaded 250 times

I hope this helps.

As with anything else in app design, we rarely need to reinvent wheels. Examine your app's layout, examine the apps like it made by others, and in most cases you can get something quite similar at least as easily in LiveCode.

Additional Notes and Historical Information
For some background on LiveCode's layout options, this post to the use-livecode mailing list earlier this month in a related discusion may be of interest:

http://lists.runrev.com/pipermail/use-l ... 59594.html

Graham Samuel wrote:
> Thanks Richard, for that typically useful reply! I have indeed written
> many a resize handler, but getting back into this stuff I was struck
> by how messy it can get. Right now I don’t even know if say a field
> with 12 point type in it has to be changed to a smaller or larger
> rectangle with smaller or larger type in it, but obviously as soon as
> I can start doing simulations (I have a totally different problem
> there!) I can experiment.

If it seems messy you may just be thinking about it too hard.

Geometry no longer differs as much between the IDE and the device as it used to.

In the first versions of LC's mobile offering, we didn't have resolution independence. Heck, in the fist versions we didn't even have a pixelDensity function. Back then, fullScreenMode was offered as a
quicky workaround because while it rarely produces apps that look exactly like the ones we most commonly use, it was easy to implement and easy to use. The alternative involved a lot of guesswork and tedious
arithmetic to try to figure out the difference between logical and physical pixels. Ugh.

Today, LC only uses logical pixels, and it automatically translates those to whatever physical pixels a given phone may be using.

Want to place a button 20 pixels from the bottom-right of the screen?
Just use the syntax you've been using for years:

on resizeStack x,y
set the bottomRight of btn 1 to x-20, y-20
end resizeStack

One nice thing about this approach is that you spend a LOT less time needing to move the stack to the device just to see what it'll look like. Just resize the stack in the IDE and look at it.


> I do like the idea of sending resizeControl to groups - I have used
> similar techniques for other purposes in the past. Powerful and
> encapsulated.

It's one of the most useful enhancements added to LiveCode, making so much about delivering pixel-perfect UIs on every platform so much easier.


> As to graphics, I can presumably start with the highest possible
> resolution and resize at startup according to the actual screen size,
> or do what I said before, have a little library of different versions
> tweaked for different screen sizes. Or possibly use SVG...

No matter which method you use for your layout, LC includes options for including referenced images of different resolutions. IIRC the manual covers that pretty well.

But if you can use SVG for the images you want you'll never need to think about multiple copies at all, and will always have a rendering optimized for the device you're running on.


> Well, I am trying to learn, and I am grateful for all that you’ve
> said.

They key to that long post is this line:

As with desktop software, I find it instructive to observe how the
best apps on mobile behave, and then - because those establish user
expectations - do what they do.

I haven't seen your app so I can't say with complete confidence whether explicit placement via resizeStack or automated approximation with fullScreenMode is the best fit for your particular needs.

Consider what your app needs to do, and study the apps on your phone that best reflect your design goals. Rotate the device, run the apps on your phone and your tablet, observe how the apps adapt their layouts to
make the best use of each screen size.

As we've been doing on the desktop all these years, we can often get results every bit as good as apps made with anything else, and usually more easily.

--
Richard Gaskin
Fourth World Systems

[Dragondos2020]

Wow! You have provided a lot more information (and so useful) than I expected.

I will spend time following your comments, digesting the information and then incorporating into my app.

I can't thank you enough for taking time out and providing such detailed instructions. Plenty for me to get my head around.

Again Thank you for your help.

[AxWald]

Hi,

if you call one of the rev_db commands or functions, you will always, each & every time, with no exceptions, test the returned data. Only this way you'll find the errors in your code.

Have fun!

[AxWald]

Hi,

some more about your db stuff.

At first, keeping a databaseID for a longer time (= relying that the connection stays intact) has shown error prone - for me, at least. Even with SQLite a db connection can break easily as soon as it's not kept alive. With remote databases it's far worse.
So I recommend to accept the tiny overhead & open/ close the database connection for each call. Only if you send a lot of calls close together - but that's something that we want to avoid anyways, because it slows down our app, right?

For instance your update code - you're throwing 14 queries in quick succession. The DB will often (SQLite at least) encapsulate each one in a transaction, and this costs a lot of time. Unnecessarily! Check my alternative:

Code: Select all

on mouseUp
   local tUserID, tSQL, tColumnToUpdate, tNewValue, tTmp, tResult, tDatabaseID
   local tFirst, tLast, membersName, tVar
   put gConnID into tDatabaseID
   put field "lblRecordID" into tUserID
   
   put field "txtFname" into tFirst
   put field "txtLname" into tLast
   
   put "Fname,Lname,Addr1,Addr2,Addr3,Addr4,Postcode,Joindate,Fee,Paid,Membership,Phone,Mobile,EMail" into tNameList
   put empty into tVar
   repeat for each item L in tNameList
      put L && "=" && cleanSQL(fld ("txt" & L)) & comma & space & CR after tVar           --  compose the update lines
   end repeat
   delete char -3 of tVar               --  don't need last comma
   
   put "UPDATE members SET " & CR & tVar & "WHERE member_id = " & tUserID into tSQL         --  concatenate tSQL
   get revdb_execute(tDatabaseID, tSQL)              --  check result, ALWAYS!!!
   if it begins with "revdberr" then 
      answer error "OMG! This query failed! DB returned this:" & CR & it titled "A horrible error has occurred!"
   else
      put tFirst && tLast into membersName
      answer information "Member's Data Updated!" titled membersName
   end if
end mouseUp

function cleanSQL pSQL, noQuote
   if not noQuote then put false into noQuote                         --  default: with quotes
   replace "'" with "''" in pSQL
   replace quote with quote & quote in pSQL
   replace return with "*RETURN*" in pSQL
   replace tab with "*TAB*" in pSQL
   if noQuote then
      return pSQL
   else
      return "'" & pSQL & "'"
   end if
end cleanSQL

This is 1 query, and as such much, much faster. And we check the result, so we get a notification if something goes wrong. For debugging purposes this notification even contains your SQL string.

You may notice I modified your cleanSQL function, too. This way you save the typing of "'" 28 times in this handler alone, and rescues you of the probability to type "" instead ;-)

Have fun!

[Dragondos2020]

Again, thank you all for your help. I will put all your comments into action.

[sphere]

So I recommend to accept the tiny overhead & open/ close the database connection for each call. Only if you send a lot of calls close together - but that's something that we want to avoid anyways, because it slows down our app, right?

You could also check if there is still a connectionID and if not then reopen the DB, this way you would not have to open/close it repeatedly, but only reopen when needed.

For example with an sqlite db, when one might have the DB id stored in a global variable

Code: Select all

if gLocalDbID is not a number then
      --OpenDb ifclosed
      put specialFolderPath("documents") & "/localDB.fil" into gDBPath
      put revOpenDatabase("sqlite", gDBPath, , , , ) into gLocalDbID
      --answer gLocalDbID titled "DB id on settingscard"  --just to temporary check when testing, you could also use non-blocking mobileToast
   end if

[AxWald]

Hi,

You could also check if there is still a connectionID [...]

Unfortunately, the existence of a numeric ConnectionID (or an existing entry in the revdb_Connections/ revOpenDatabases) doesn't mean the connection actually still exists!

Code: Select all

revdberr,MySQL server has gone away

is what you can expect to get once in a while when you rely on a "still good ConnectionID".

You can try to check if your machine goes to sleep, if your app gets massacred in the background, if your router reboots, and you can fiddle with the settings of your db server - but you'll never be able to trust an aged ConnectionID.
So, you need to wrap each database call in a try construct, or test your connection each time you desire to use it.

Or you waste a few precious nanoseconds and wrap your whole database calls in something like this:

Code: Select all

function DoSQL theDB,StrSQL
   put getSQLCreds(theDB) into myDBArr                              --  get credential array
   put revdb_connect(myDBArr["type"],myDBArr["host"],myDBArr["db"],\
   myDBArr["usr"],myDBArr["pwd"]) into MyDBID                       --  connect
   
   if StrSQL begins with "SELECT" then                               --  fetch query data
      put revdb_querylist(tab,return,MyDBID,StrSQL) into myData
   else                                                              --  do an action query
      put revdb_execute(MyDBID,StrSQL) into MyData
   end if
   get revdb_disconnect(MyDBID)                                      --  disconnect always
   return Mydata                                                     --  return the result
end function

(getSQLCreds() is a function that accepts a "DB shortcut" ("AWX") and returns an array with the credentials for this db. Comes handy if you work with more than 1 db ;-) )

Then you call it this way:

Code: Select all

   put "SELECT `Name` FROM `t_test` WHERE `ID` = 1;" into StrSQL
   put DoSQL("AWX", StrSQL) into myRes

or

Code: Select all

   put "UPDATE `t_test` SET `Name` = 'axwald' WHERE `ID` = 1;" into StrSQL
   put DoSQL("AWX", StrSQL) into myRes

You see, no more trouble with expired ConnectionIDs. And no more mixing up revdb_queryList/ revDataFromQuery and revdb_execute/ revExecuteSQL - just write your StrSQL & throw it at the desired db.

But for sure, not before you have added the error checking for DoSQL() - I just omitted it for easier reading, and as an exercise for the esteemed reader ,-)

Have fun!

[Dragondos2020]

A lot to take in. But I will take on board. Many thanks for your valued comments. Regards

[sphere]

thank you AxWald that's a great way to tackle it.

[Dragondos2020]

Thank you all for your contributions. It has been quite overwhelming, but very welcome. My screen shots and presentation is beginning to take shape.

However, I still do not understand why the buttons that I have added to the project (excluding the Navigation Bar) works just fine within the LiveCode Environment. With each script of the different buttons, working as instructed to do. But when I use the project either on the Emulator or by installing the .apk file onto my Android Phone. Nothing happens when I select any of the buttons (excluding the Navigation Bar). It is the same code being used in both environments. What am I missing or not including?

Thanks

[AxWald]

Hi,

"Update details" and "Delete member" work in the IDE, but not on mobile?
Smells like you don't include the necessary database libraries. Check in the "Inclusions" pane of the "StandAlone Application Settings" - you need both "Database" and the db-specific one ("SQLite", "mySQL" ...).

Btw., dunno if it's mentioned somewhere:
A relatively easy way to test frequent changes is this:

• Connect your mobile to the computer via USB, and enable "USB debugging" on the fone/ tab.
• Select it in LC's "Development/ Test Target".
• Use "Development/ Test" to launch your stack on the mobile ;-)

(You may need to uninstall previous versions first)

Have fun!

[Dragondos2020]

I have now selected / included the following:

Navigation Bar : DataGrid : Sqlite : Database : Answer Dialog : Ask Dialog

Unfortunately, the result is still the same. Buttons work fine in LiveCode Environment, but not in emulator or on my Android Phone.

Frustrating or what! Any advise or comments would be gratefully received.

[sphere]

Did you include the correct inclusions in the standalone setting and on the Android tab?
Like sqlite, Internet permissions etcetera

Selecting the correct inclusions and permissions is vital for correct working of your app.
Trust us it works. Check the user guide for more info about it.