This blog post is Part 1 in a series of three blog posts, explaining how to prepare the app for debugging (setup) and how to debug on iOS and Android.
- How to setup your apps to target locally on device (Part 1)
- How to debug your mobile app on iOS (Part 2)
- How to debug your mobile app on Android (Part 3)
How to debug your app locally on a device is going to be the first chapter and explained below.
HOW TO SETUP YOUR APPS TO TARGET LOCALLY ON DEVICE
As a developer, I test my code locally to observe its behavior and that helps me debug issues. This example uses the RHMAP WFM Demo Project template because it provides a Client App that uses authentication out of the box, providing an added complexity that would hinder local debugging. This blog post assumes the WFM project is configured as described in the documentation. While this post uses a WFM project as an example, you can use the techniques described in this post for any Client and Cloud Apps, not just WFM projects.
As a full-stack developer, you want to observe both the back-end and front-end app. However, the Client App is difficult to debug because, as soon as the app initializes, it makes several calls to the server. This post explains how to setup your apps to target locally.
The goal is to test the app in the browser using a grunt file Gruntfile.js
with several tasks:
- Run Client App on a browser with server cloud backend:
grunt
- Run Client App on a browser with local cloud backend:
grunt serve:local --url=http://localhost:8001
For the Cloud App we can use the same grunt file:
- Run cloud app locally:
grunt
Note on running your cloud app locally:
The in Gruntfile.js the Cloud App has environment variables that you set up for your project.
The most important one is FH_SERVICE_MAP where you need to list the MBaaS services where the cloud app connects. The services can be running locally or remotely:
options : {},
// environment variables - see https://github.com/jsoverson/grunt-env for more information
local: {
...
/*
* This is mapping to authentication service, when running raincatcher-demo-auth locally it will map to it
* allowing cenv : {
orrect authentication.
*/
FH_SERVICE_MAP: function() {
/*
* Define the mappings for your services here - for local development.
* You must provide a mapping for each service you wish to access
* This can be a mapping to a locally running instance of the service (for local development)
* or a remote instance.
*/
var serviceMap = {
'yxs2qd3aicaumfr3xyc3rgmb5': 'https://localhost:8012'
};
return JSON.stringify(serviceMap);
}
}
},
You must provide a mapping for each service you want to access using FH_SERVICE_MAP.
This is a mapping to a locally running instance of the service or a remote instance.
Now, you can set up your environment to debug our code to see what is happening in the app.
- Bypass box initialization
- Bypass auth service (if needed)
- Setup the mobile app
BYPASS BOX INIT
The Client App calls fh.init during initialization using the following path:
/box/srv/1.1/app/init
expecting a json as a response, for example:
{
hosts: {
url: ‘http://<cloud network IP>:8001’
},
init: {
trackId: ‘awbt345cas3v3ng5****sa1'’
}
}
The SDK expects the trackId attribute under the init key in the response from the cloud for a box-srv-app-init call, even if you are developing locally.
The original response returns more parameters but this is all you require to develop locally.
You need to bypass this call, modify the app.js file on cloud app and add the new route:
app.use('/box/srv/1.1/app/init', function(req, res) {
res.json({
hosts: {
url: 'http://<cloud network IP>:8001'.
},
init: {
trackId: ‘awbt345cas3v3ng5****sa1'
}
});
});
BYPASS AUTH
If your app calls to an Auth Service, you must bypass this call.
When you debug your local app, you will see that a call is being made to, modify the app.js file on cloud app and add the new route:
/box/srv/1.1/admin/authpolicy/auth
app.post('/box/srv/1.1/admin/authpolicy/auth', function(req, res) {
var user = req.body.params.userId;
var pass = req.body.params.password;
if (user === "test" && pass === "test") {
res.json({
authResponse : {
email : “redhat@redhat.com",
id: "b2a4c64e-c815-4cc1-b5bf-cb13****d",
name: "Redhat",
phone:"0123*****90",
status:"Active",
username:”redhat@redhat.com"
},
sessionToken:"kwgQl1Pu0k_4ACLUcghqULCUWPsTDB1M",
Status:"ok",
userId:”redhat@redhat.com"
});
} else {
res.status(401).json({'status': 'unauthorized','message':
'unauthorized'});
}
});
When you simulate the cloud POST call to /box/srv/1.1/admin/authpolicy/auth if the retrieved userId and password params are equal to test//test we return a json response for local development.
NOTE: If your app uses session token validation, make sure that the token session is valid. If not, you'll get an unauthorized response from DB calls, you can bypass the session token validation by commenting out the session validation checks.
SETUP THE MOBILE APP:
To run the app on a device we need to follow 3 simple steps:
1. Change fhconfig.json
Modify the host property of the fhconfig.json in the www directory of the Client App so it points to your locally hosted Cloud App:
{
"appid": "fqvk6******atqew72rsa",
"appkey": "95af9a42ee********3ba23a1bfe58c8",
"apptitle": "APP mobile",
"connectiontag": "1.0.1",
"host": "http://<cloud network IP>:8001",
"projectid": "fqvk6hompypukfkxaaaaatwu"
}
The host property has to be the machine’s public ip. ”Localhost” is not used in this property because localhost will be the client device.
2. Build Mobile App
Run grunt serve:local to generate the new www folder. Our mobile app has a Gruntfile.js to generate the vendor and bundle files.
3. Build Cordova App
If you want to build the app for iOS or Android and test on the device, run the following commands cordova platform add ios or cordova platform add android.
This will generate an Android or iOS project if the platform has been already added just run cordova build ios or cordova build android.
Click here to download the Red Hat Mobile Application Platform.
Last updated: February 26, 2024