v1.0.5 Comments

[PilotFlying]

Hi Neal,

I thought I'd start a new thread on this to keep things in context.

I had my first day back on the line yesterday to put v1.0.5 through it's paces and, I gotta say, it's starting to resemble a well-oiled piece of machinery! The crashing is no more, the custom text recall is outstanding, the use of the term 'aircraft ident' is much appreciated by us north-of-the-49ers (and others), and all the other refinements just put icing on the cake.

I did, however, find one new problem that seems to have surfaced. Remember the timezone issue we were having with the out/in times? Well, it seems to have been contagious and has now spread to the flight date and out/in time date fields - or at least some variation of it. I haven't been able to pinpoint the specific behaviour of this problem, but I've noticed at least two related issues:

- selecting the blue 'current date/time' arrow doesn't always insert the current zulu date, but instead that of the local time zone
- the actual date selected with the wheel is not what is displayed in the field after being selected, although it is actually still correct when going back in to re-select (this is similar behaviour to what we had with the time issue before)

These two screenshots show the input made on the selector wheel for the in time, and the resulting display in the field, respectively. Notice that the wheel shows the 26th (today) while the field shows the 25th. Obviously it's not saved as 00:23 on the 25th, as the field would not accept an in time earlier than the out time. This specific case occured yesterday while transiting two time zones that were both still the 25th, while it was the 26th zulu.



These two show a similar case for the selection of the flight date. Again, notice the selection made was the 26th, while the resulting indication was the 25th.



It seems to be just an indication problem, as all dates are saved correctly and, when viewed in the lists of flights, appear as they should.

Let me know if there's any more testing I can do out here. I'm on the road for another 3 days, so should be able to play around a bit more. I'll be in and out of data coverage, so should be able to respond here and there.

Thanks again for a great product, and your attention to this latest issue.

Cheers,

Chris

 

[Neal Culiner]

Hello Chris,

Thanks for the feedback. Can you tell me what timezone your device is/was in when this occurred? Does this happen if you have Use GMT "OFF"? Does it matter if you're in airplane mode or not? Have you seen times where it does work then other times where it doesn't? I'm trying to pin down exactly when the problem occurs.

Thx

 

[PilotFlying]

Hi Neal,

Thanks for the reply.

Can you tell me what timezone your device is/was in when this occurred?

The first pair of screenshots above were in transition from UTC-4 to UTC-6, and the second from UTC-6 to UTC-7. Since airplane mode is turned on before departure, the 'current' timezone for the duration of the flight, until turning airplane mode off on the other side, would have been UTC-4 and UTC-6, respectively.

Does this happen if you have Use GMT "OFF"?

I haven't had a chance to play around with this yet, but the next time I see the issue occur I'll give it a try.

Does it matter if you're in airplane mode or not?

It doesn't seem to. In the screenshots I included in my last post, one occurrence was with airplane mode ON, and the other with it OFF.

Have you seen times where it does work then other times where it doesn't?

Yes. Unfortunately I can't pinpoint any unique circumstances associated with the issue, as it has both worked and not worked on flights that cross timezones. So far this pairing I haven't had any problems when remaining within one timezone, but I've also only operated one such leg thus far.

Today's flight legs were as follows: YEG (UTC-6) to YVR (UTC-7) to SFO (UTC-7). On both legs, everything worked as expected.

I hope this information helps. I'll report back again after tomorrow's flying with any findings, although all three legs tomorrow will remain within one timezone so not sure how helpful it will be.

Cheers,

Chris

 

[Neal Culiner]

Thanks Chris. I have not been able to duplicate this yet. I will continue to try.

 

[PilotFlying]

Hi Neal,

Sorry I didn't report back yesterday. It was a long day, and it wasn't too easy to find a computer at the end of it all. I encountered no problems whatsoever on all three legs, which took us from SFO-YVR-SFO-YVR, all in the UTC-7 time zone.

Today's flying took us from YVR (UTC-7)-YYC (UTC-6)-YYZ (UTC-4). I had no problems again on the first leg. Then, on the second leg, I decided to attempt to reproduce the issue at 2330Z, which is the exact same time as one of the other instances where I encountered the issue (second pair of screenshots on my first post in this thread); wouldn't you know it, the problem was back! Notice the out time date selected as the 28th (today) on the selector wheel, and the 29th appearing in the out time field. Again, the data was in fact saved correctly - it's just the indication that is wrong.



Upon arrival in Toronto (0040Z) everything worked as it should when recording our in time.

So, I have found some commonality between at least two of the instances: both occurred while approaching midnight zulu (2330), and both occurred with the phone locked to the UTC-6 time zone while in airplane mode.

I'm not sure if either or both of these commonalities have any significance, but I guess it's a start. Maybe you can attempt reproducing it with these conditions. I have another four days starting on Monday, and will let you know anything else I find.

Cheers,

Chris

 

[PilotFlying]

Also, out of curiosity, how is it that the indication in the flight date/out/in time fields can show anything other than what is directly selected on the wheel? Don't they just reproduce what is set? Or are they somehow calculated independently of the selection and saved data?

Cheers,

Chris

 

[PilotFlying]

Sorry, one more thing.

I just attempted to reproduce this issue at 23:58 local time with 'Use GMT' disabled (as per your question above), and everything worked as expected.

Cheers,

Chris

 

[Neal Culiner]

Hello Chris,

Thanks for the follow-up information, so it appears to only occur when within 30 minutes of midnight Zulu? I'll run tests against that scenario and see what I can come up with.

Again, the data was in fact saved correctly - it's just the indication that is wrong.

Can you clarify this please? Where exactly is it correct and where is it wrong?

Also, out of curiosity, how is it that the indication in the flight date/out/in time fields can show anything other than what is directly selected on the wheel? Don't they just reproduce what is set? Or are they somehow calculated independently of the selection and saved data?

I wish it were this easy and this actually what I'm trying to accomplish, but there is a conversion that has to take place due to how the phone handles timezones and suspend/resume scenarios, etc. I've already started enhancements for 1.0.6 so I hope to tackle this problem this week. Other than that not really any other issues, I fixed the tappability issues on the calc button for iPhone 4 users and will continue optimizations and preparation for schedule importing.

 

[PilotFlying]

Hi Neal,

Thanks for the follow-up information, so it appears to only occur when within 30 minutes of midnight Zulu?

So far, at least, that's the only pattern I can find. That, and the fact that the phone was in the UTC-6 time zone when the issue occurred.

Can you clarify this please? Where exactly is it correct and where is it wrong?

The only place the date appears wrong is in the date/out/in fields:



What I mean when I say it saves correctly is that (a) when selecting one of the fields to modify it, the correct date is shown on the selector wheel (even though the wrong date still shows in the field when pressing save),

This is what I see when selecting one of the incorrect fields above, in this case the out time (notice how it show's the 28th (correct), while on the other screenshot the fields show the 29th (wrong)):


and (b) the correct date is synced to Logbook Pro PC, even though the wrong date is still shown in the field. This leads me to believe that behind the scenes everything is OK - it's just the indication on the interface that is in error.

I wish it were this easy and this actually what I'm trying to accomplish, but there is a conversion that has to take place due to how the phone handles timezones and suspend/resume scenarios, etc.

That's interesting. I just assumed that calculation happened when pressing 'now' on the selector wheel, etc., and then whatever is displayed on the wheel would be directly inserted into the field when pressing save.

I hope you can reproduce this and get to the bottom of it. In the meantime, it in no way renders the app unusable; however, it can get a bit confusing at the end of a long day.

Let me know if there's anything else you need.

Cheers,

Chris

 

[Neal Culiner]

Thanks Chris. So far I cannot reproduce this issue but I will keep trying.

 

[Neal Culiner]

Hello Chris,

Issue duplicated, found, and fixed! I expect to push 1.0.6 to Apple approximately Tuesday. It was a simple issue in the formatter that takes the date value and presents it on screen. You were right, the data is saved properly, it's just a presentation issue of the value.

Thank you for finding this issue and reporting it in such great detail. Your effort is greatly appreciated.

 

[PilotFlying]

Issue duplicated, found, and fixed!

Outstanding, Neal! I'm glad you were able to reproduce the issue, and thrilled that you were able to find a quick, easy fix. I'm always amazed at how quickly you get these things taken care of!

Thanks once again for the great support and for directing so much of your attention to this issue and, as always, I'm looking forward to the update!

Cheers,

Chris

 

[Neal Culiner]

Hello Chris,

I'm happy to report 1.0.6 is finished and testing is complete, the updates for iPhone and iPad have been submitted to Apple. Here is the narrative of the changes in 1.0.6 for those interested:

- Significant performance and stability enhancements
- Added feature where new flight route starts with last fix of prior route (Settings/Flight Log Settings to option ON/OFF)
- Flight Cost/Hour now calculated on device if Cost/Hr set in Options/Aircraft on PC edition
- History Date Due now calculated immediately when Accomplished date is selected
- Added Calculator button on History Date Due field to recalculate date due on demand
- Landings are now displayed in Flights view such as 1D/2N to indicate one day landing and two night landings logged
- Auto-Purge will now only purge Synced data to prevent inadvertent removal of Pending Flights
- Improved tapability of Duration Calculator button and other buttons for iPhone 4 users
- Fixed a rare display issue related to date/time selection within 30 minutes of midnight
- REMOVED Startup screen option in Settings as iOS 4 will resume the app on the last screen, this feature is obsolete
- Fixed an issue where a potential crash could occur on application startup which required a delete/reinstall to resolve the issue

Thanks again for your outstanding contributions. I am glad I was able to knock out quite a few items on the task tracker as well. If no bugs are reported, the next version will be 1.1 with the schedule importer integration which I'm looking forward to completing. This product has been a great pleasure to produce and it's come a long way. 1.0.6 really enhanced a lot of things after a complete code review and performance analysis. It even runs great on my iPod touch 2G now!

Now for the wait for Apple to review the updates!

 

[Neal Culiner]

Holy moly! They went into "in review" status within 10 minutes of uploading! This is a first! Normally takes 7-9 days!

 

[PilotFlying]

Hi Neal,

Once again, a very impressive list of new features and fixes! The option to recall the last point on a route as the first of the next is genious. I'm curious - what does it recognize as a break fetween two points? Space? Dash? I've been using a dash, i.e. YYZ-LAX; will that be recognized?

Holy moly! They went into "in review" status within 10 minutes of uploading! This is a first! Normally takes 7-9 days!

WOW! Maybe this will be a fast one. Fingers crossed...

Thanks again for the update, and for the care and attention you put into making a quality product.

Cheers,

Chris

 

[Neal Culiner]

Hello Chris,

Hopefully we'll come out of "in review" tonight and get a release within 24 hours of submission! That would be great because I truly believe this is the best release yet!

I'm curious - what does it recognize as a break fetween two points? Space? Dash? I've been using a dash, i.e. YYZ-LAX; will that be recognized?

What I do is walk backwards right to left one character at a time and find the first non-letter/number. So if it's a space, dash, comma, hyphen, i.e. anything other than A-Z or 0-9 it will trigger a break and use that as the last fix.

 

[PilotFlying]

What I do is walk backwards right to left one character at a time and find the first non-letter/number. So if it's a space, dash, comma, hyphen, i.e. anything other than A-Z or 0-9 it will trigger a break and use that as the last fix.

Once again - GENIOUS! I'm really looking forward to this feature.

That would be great because I truly believe this is the best release yet!

It sure sounds like it!

Cheers,

Chris

 

[PilotFlying]

Guess a 24 hour turnaround was in fact too good to be true! ;-)

 

[Neal Culiner]

No kidding! The closed doors of Apple, no one knows what really goes on, how the process works, etc. Such a secretive organization, very strange! So it's a hurry up and wait. I wonder if someone "touched" the files by accident and put them into "in review" status by accident, but then again, I've seen this before. I wonder if the process is such that it passes through so many channels and if there are no objections during the process it releases. So I'm glad at least there hasn't been any news contrary, and thankfully I've never had a rejection. Hopefully soon but I always put in my mind the 7 days as that's the average to date.

 

[Neal Culiner]

1.0.6 just got the green light, should be available within the next few hours!