One common productivity tip suggests that we complete the most difficult tasks first thing in the morning, when our focus and energy levels are supposedly at their peak.
My approach is a little different.
I tend to want to get most of the menial tasks out of the way first — as quickly as I can. That way they don’t stay in the back of my mind for the rest of the day, and potentially drain my mental focus.
Then I’m ready to start the more challenging work with a clean slate — be that problem-solving, composing, or something else.
On that note, there is one thing on my plate that does require a little exploration, and perhaps a tiny bit of a learning curve. But if I were to rate it, it would probably lean more toward the mundane side of the scale.
It’s the first thing on today’s development checklist.
Testing on Devices
Before continuing with feature implementation, I would like to circle back to device testing for a moment.
Currently, I am only in possession of one Android device that is suitable for testing the app. My other ones are all too old to be compatible.
That is not exactly ideal for someone who is launching a new app on Google Play.
After some research on remote mobile testing solutions, I decided to give AWS Device Farm a try.
Let’s jump right on it.
Setting Up
You can get an AWS account on its Free Tier plan for the first 12 months.
Then you will need an Identity and Access Management (IAM) user with permission to access Device Farm.
On the Free Tier, you will be given 1,000 minutes of free testing.
(I remember reading somewhere on the site that this is a limited-time offer. Normally they only give 250 or so free minutes.)
The setup guide can be found here:
(Not an affiliated link.)
Fast forward to the last step of getting started. The above screenshot shows me granting myself access to Device Farm.
Next, I will quickly walk through the steps of virtual testing.
Step 1. Go to the Device Farm Console
https://console.aws.amazon.com/devicefarm
Step 2. Create a new project
Step 3. Create a new run
I dragged the slider all the way to the minimum, so that I wouldn’t be using up too many minutes. Adjust your preference accordingly.
Everything looks fine for the most part.
You will see that I had selected the “Top Devices” pool only, for the same minute-saving reason. Theoretically speak though, in mobile testing, we are supposed to take care of the lowest common denominator of devices as well.
Remote Device Testing
What I was really interested in, however, is the Device Farm’s remote access.
It’s a web-based tool that allows me to manually test the app on a wide range of devices.
This can be very helpful because automated tests often don’t represent the whole picture.
I was hoping they would have either the Samsung Galaxy S8 or S9. But upon searching, it would appear that the highest model available was S5.
That would work.
In fact, I should definitely test on even older models before launch.
Right now, it’s just a quick UI eyeballing run, especially since the intended functionality wasn’t in place yet.
There’s an automatically recorded video of the test session. Sweet!
Nothing looked out of whack so far. I was ready to move on.
Timing Functionalities
Yesterday I added some <ionic-datetime> components, which are helpful for displaying pickers where users can select the current local date and time.
Design Choice #1
At first glance, it might seem weird that users are required to manually enter the date and time themselves.
The reason behind this design is simple:
It’s so that the app will still work properly in airplane mode.
But how?
Without network access in airplane mode, most phones will not be able to automatically sync up to the local time zone. In which case, the time travel tracker will return inaccurate results.
Manually inputting the current local date and time solves the potential issue.
Design Choice #2
Because of the same reason as above, I have decided to remove the “flight duration” display feature in the first release.
Most “time elapsed” implementation methods rely heavily on the device’s current timestamp. So not being able to get correct time zone offsets automatically (like when in airplane mode) isn’t ideal for making a timer.
Now, for Jet Tag to work as designed (on its latest specifications anyway), I would need to manipulate the data somehow.
I came across Moment.js on Ionic’s official documentations, which was supposed to make our lives easier for said work.
I decided to check it out.
First, I installed it via Terminal:
npm install moment --save There were some warnings:
+ moment@2.22.2added 1 package from 6 contributors and audited 6217 packages in 13.559sfound 6 vulnerabilities (1 low, 5 moderate)run `npm audit fix` to fix them, or `npm audit` for details
So I tried the suggested fix:
npm audit fixIt didn’t help.
up to date in 8.731sfixed 0 of 6 vulnerabilities in 6217 scanned packages5 vulnerabilities required manual review and could not be updated1 package update for 1 vuln involved breaking changes(use `npm audit fix --force` to install breaking changes; or refer to `npm audit` for steps to fix these manually)
Moving on for now, as I didn’t want to dwell on it for too long.
Passing Date and Time Data Between Pages
The flow would be straightforward:
- Home page records timestamp at the start of the flight, aka “time travel.”
- The start timestamp gets passed to the Arrival page.
- Arrival page records timestamp at the end of the “time travel.”
- The end timestamp gets passed to the Summary page.
- Summary component manipulates input data, calculates the result, and displays it on the page.
Here’s what I did today to get it all in place:
home.ts
date;
time;constructor(public navCtrl: NavController)
{
}goToArrivalPage()
{
this.navCtrl.setRoot(ArrivalPage, { start_date: this.date, start_time: this.time });
}
home.html
<p>
<ion-item>
<ion-label>Today's Local Date</ion-label>
<ion-datetime displayFormat="MMM/DD/YYYY" [(ngModel)]="date"></ion-datetime>
</ion-item><ion-item>
<ion-label>Local Time Now</ion-label>
<ion-datetime displayFormat="HH:mm" pickerFormat="HH mm" [(ngModel)]="time"></ion-datetime>
</ion-item>
</p>
arrival.ts
start_date;
start_time;
curr_date;
curr_time;constructor(public navCtrl: NavController, public navParams: NavParams)
{
this.start_date = navParams.get('start_date');
this.start_time = navParams.get('start_time');
}goToSummaryPage()
{
this.navCtrl.setRoot(SummaryPage, { start_date: this.start_date,
start_time: this.start_time,
end_date: this.curr_date,
end_time: this.curr_time });
}
summary.ts
import moment from 'moment';Didn’t forget to import the newly installed Moment.js tool.
start_date;
start_time;
end_date;
end_time;
start_timestamp;
end_timestamp;
time_difference;constructor(public navCtrl: NavController, public navParams: NavParams)
{
this.start_date = navParams.get('start_date');
this.start_time = navParams.get('start_time');
this.end_date = navParams.get('end_date');
this.end_time = navParams.get('end_time');this.start_timestamp = moment(this.start_date + " " + this.start_time);
this.end_timestamp = moment(this.end_date + " " + this.end_time);this.time_difference = this.end_timestamp.diff(this.start_timestamp);console.log("start time: " + this.start_timestamp);
summary.html
Here I was displaying the time difference in milliseconds for now, since that’s what would be returned by the moment.diff function.
Will convert it into a more human readable format later.
<p>
Time Traveler Status:
</p>
<p>
<em>{{ time_difference }} milliseconds</em>
</p>
Seeing the New Flow in Action!
Let me break it down. So I was simulating a flight that started on 10/22/2018 at 14:45.
And by the time I arrived at my mysterious destination, it’s already a whole day later. Not realistic, I know. This is just for demonstration purpose.
As a result, I would have time traveled into the future by:
24 hours x 60 minutes x 60 seconds x 1000 milliseconds
= 86400000 milliseconds
It worked!
Would now be a good time for me to say “SHIP IT?”
Not quite yet. I am going to reformat the millisecond string so that it reads more naturally. Then I’m calling it a night.
Tomorrow
Time flies, and it’s hard to believe I’m already over the 50% mark of this challenge.
With Jet Tag now functioning more or less as intended, I’m ready to quickly re-skin it into the second app, Cat Pat.
If all goes well, there will be some more app testing, and perhaps a little bit of copywriting for the launch.
Then hopefully both apps can be published on Google Play by the end of the challenge on Day 7!
