AFPEx and smartphones

[tmmorris]

I can't get 3G (or any) O2 reception at the strip* I fly from...

Tim

*AKA a major RAF rotary base...

[FlyUK73]

There is an update to the software on the 4th of march at 2200 UTC, so if you click login on the website after that a download will be forced.

if you visit:

https://ts1.flightplanningonline.co.uk/

https://ts2.flightplanningonline.co.uk/

https://ts3.flightplanningonline.co.uk/

and download the new version after the update (about 2300) from all three links you won't be asked to download again until the next update.

If you download from only one of the above links, the next time you try from a different link the terminal server (ts1, ts2 or ts3) will see your software as out of date and force a download.

Hope this helps.

[IO540]

FlyUK73

This is very helpful, but raises some points:

1) a lot of people download from http://www.flightplanningonline.co.uk/ which then changes the URL to one of the others - which one, seems to vary

2) why download from all three?

3) will you publish an update schedule?

4) if one is running the cached version, by executing ats.xjnlp.jnlp loader rather than going to the website, the ts1/ts2/ts3 server selection appears to be determined by the loader file; mine contains ts3 in one place and all three lower down

[ILOC]

IO540

AFPEx is not a website - it is a client-side Java application of about 3MB in size. AFAIK no current "phone" device runs it.

I don't have a Windows Mobile phone at the moment but apparently Java has been available for them for some time now.

The Ipad might perhaps???

Unfortunately not - Apple have made it very clear that they will never allow interpreted code such as Java (or Flash) to ever run on the iPhone or iPad. It's unfortunately rather typical Apple arrogance in assuming that everyone will come around to their world view and stop using them.

In general, www-capable phones can access most normal websites but there are occassional issues because these browsers are not quite Internet Explorer compatible.

This isn't really to do with Internet Explorer compatibility, more to do with a combination of the phones built in browser not doing a good job of resizing/shifting things around to fit on a small screen, and the website not being designed to be viewed that way. Firefox and Chrome have grown so massively in popularity that only the worst designed websites aim to just be IE compatible.

That said, pocket/pc is crap anyway and I am sure the more modern stuff like the Iphone are a lot more compatible.

Unfortunately not! The lack of Flash and Java on the iPhone and iPad means a large number of websites won't display properly. Having said that for the remaining websites Safari does do a very good job.

If you are willing to jailbreak your iPhone (bypass Apple's draconian app installation protection/stranglehold) then you can install Java, and all sorts of other wonderful apps that don't conform with Apple's 'policies'. It's simple and by far the best thing I ever did on my iPhone.

Having said all of that I have an iPhone and love it. It's just unfortunate Apple insist on trying to control and restrict everything.

The iPad is basically going to be a giant iPod Touch - so same restrictions and apps. It will be marvellous for browsing the web, watching videos, reading email/e-books and hopeless for much else.

[englishal]

Another reason Android is superior to the Apple OS and perhaps one reason Apple will eventially sign their own death warrant?

[ILOC]

Not that I ever thought I'd hear myself saying it, but...

Just wait for Windows Mobile 7. Microsoft have made a completely unprecedented move (in the history of Microsoft) and completely scrapped their existing Windows Mobile code and started from scratch.

The prototype phones they are showing around look like they are going to be really very good. They are taking a sensible middle ground in specifying quite tightly what hardware must be used for the phones but still allowing other manufacturers to produce them.

The interface looks really good - clean, fast. Still quite a few bugs at the moment but it's a very early prototype.

Don't even get me started on Microsoft's prototype Courier tablet, now that looks amazing.

God, I'm beginning to sound pro-Microsoft. Coat, hat.

[IO540]

IMHO there is no handheld device, nor is there likely to be one, which does the whole job for GA preflight tasks.

I can get very basic weather data on my phone, but can't run any usable route planning app on anything that size.

One needs something bigger - a 7" screen or similar. Obviously not a phone, PDA or anything like that.

The Ipad is good for nothing other than a PDF browser - IF you can get a load of plates printed off to appropriately sorted PDFs. That's a possible EFB solution for IFR pilots, which are a small group.

I have played with loads of gadgets but no matter how I look at it, a small lightweight laptop is the way to go. With a GPRS/3G radio (which can be a bluetooth-connected mobile phone**) it actually does everything.

Funnily enough the Ipad's advert budget and fashionable following should result in a load of lookalikes from China but they will be normal 80x86 computers and thus far more useful.

The big issue with WM is that M$ do not offer any support or patches. They delegated this to the device manufacturers, who obviously washed their hands of customer support. Compaq, HP, Toshiba, Fujitsu, etc, never supported these products, giving rise to a raft of online forums where thousands of p*ssed off owners moaned about issues, and occassionally found fixes. This killed the PDA market well before "smartphones" came along.

We now have "convergence" of phones and PDAs (and low quality cameras) but I don't think this is relevant to GA preflight activities. In limited situations, a "phone" can be used to get taf/metars or even meteox.com radar data and such (my compact Nokia E51 can) and that is OK for a preplanned route, but flight plan filing is not usually a standalone task; one needs to plan the route somehow, with Eurocontrol validation if IFR, and all this extra stuff needs a laptop. So being able to run AFPEx on a phone is of use to some people some of the time, but usually only if they skip a lot of other important stuff.

** the advantage of using one's phone as the GPRS/3G radio is that you already have a SIM card in your phone, which you presumably "look after". Having another radio in the "portable device" is just a PITA because it's another SIM card to keep topped up, etc. Also many people have phones provided by their employer which is even better

[eharding]

Has anybody looked at the network traffic the AFPEx application generates in order to file a flight plan? - is it via HTTP, or some custom protocol? Does it work behind corporate firewalls?

The decision to deploy this thing as a Java download smacks of extreme high-order muppetry.

[kui2324]

eH - if your corporate IT police have dictated you can't download any applications/files (like ours have) then you may well not be able to run it.

Which is a complete pita when it comes to skiving off for a quick flight. When we are forced to use it for booking out courtesy of the upcoming NATS cost savings (and I do feel for the people who are losing their jobs over this) we will either have to hope the local handling agents computer is working or take a laptop to run it and use their wi-fi.

[IO540]

Has anybody looked at the network traffic the AFPEx application generates in order to file a flight plan?

I did comparisons for a 'typical' flight plan filing session

Homebriefing 1.4MB
AFPEx 0.4MB
EuroFPL 0.1MB

AFAIK, AFPEx is all over port 443 (HTTPS). Never had any trouble running it, over mobile internet or anything else.

You have an email.

[FlyUK73]

1) a lot of people download from http://www.flightplanningonline.co.uk/ which then changes the URL to one of the others - which one, seems to vary

It's the servers carrying out load sharing, if 2 and 3 have more users the call is directed to 1.

2) why download from all three?

On startup the cached version on your local computer is examined by the server to ensure it matches what is expected, if the server doesn't see a match it forces download of a new one. A download from ts1 has a different point of origin from one downloaded from ts2, therefore it is stored in cache differently.

3) will you publish an update schedule?

I just did.

4) if one is running the cached version, by executing ats.xjnlp.jnlp loader rather than going to the website, the ts1/ts2/ts3 server selection appears to be determined by the loader file; mine contains ts3 in one place and all three lower down

Then you will always download from ts3, the risk is that the ats.xjnlp.jnlp loader may change, which means you may have issues if try to use the stored version on your desktop. The index page including the webstart file is about 70kb, switch images off on your browser and you are down to about 5k. A better way of avoiding the index page download is to put a shortcut to https://ts1.flightplanningonline.co.uk/ATS/ats.xjnlp directly on your desktop ensuring a valid webstart file (about 1k) is downloaded every time. The problem with doing this is that if everyone saves ts1 on their PC as a shortcut, all that money spent by NATS on load sharing implementation goes straight out of the window.

Bear in mind also, that if the implementation was not Java your bandwidth would be much much more, as an active html page with server calls to validate data on the fly would require more interaction. Your local copy of AFPEx already contains all the data needed for validation of the various elements of the forms, standard routes for IFR flights, etc.

[IO540]

OK, good.

Some random observations:

From talking to many, I suspect most people are unable to execute a file called ats.xjnlp - presumably due to a missing association. That's why, when I downloaded mine (from the Login prompt on your website) I called it ats.xjnlp.jnlp.

Server load sharing: would you not find that if you drastically reduced the full application download incidence, your server bandwidth would go way down? In the bad old days your servers must have been running flat out serving all those 3.5MB chunks. There aren't that many pilots with UK addresses

Standard routes: how are these used? IFR routes will always be pre-validated via IFPS, otherwise the FP gets a REJ. The majority of IFR routes flown "for real" are not out of the SRD; SRD routes just take you for a scenic flight around Paris with a 200nm radius

[eharding]

Originally Posted by FlyUK73

Bear in mind also, that if the implementation was not Java your bandwidth would be much much more, as an active html page with server calls to validate data on the fly would require more interaction

Sorry, that just doesn't sound true - what sort of validation is going on that would require AJAX interactions that would compare to a 3.8 Java Mbyte download every month or so?

A more likely explanation is 'we had this Java application developed for inhouse use, and decided that rather than build a scalable web application for external use, given the likely number of users, we'd foist the Java application on them instead'...and that would be a reasonable explanation - but don't try and bulls**t anyone into thinking this is a better solution than a pure browser-based implementation.

Even if we accept that it is more efficient to have the validation done locally, why does the *whole* thing have to be downloaded to reflect changes in the data? - unless you're constantly adding functionality with every release, then the changes to the validation data should be an incremental download - at least, it should be in anything with a remotely decent architecture.

[jonkil]

Sorry Fellas, wrong Forum I'm in, thought I was in the forum about flying, sorry again for logging into a GSM forum ! Anyone fly in here ?

[eharding]

Originally Posted by jonkil

Sorry Fellas, wrong Forum I'm in, thought I was in the forum about flying, sorry again for logging into a GSM forum ! Anyone fly in here ?

Apologies - and now back to our normal Pprune fare:

....anyway, that plastic C42 toy you fly - how long does it take to wind up the rubber band, and what happens if you wind it the wrong way? - also, in the event of a prop-strike, does the prop stop dead and the rest of the airframe spin wildly around it?

You see, you feel at home already.

[flybymike]

Thank God.
Someone who speaks English....

[bookworm]

FlyUK73, thank you, your information on the architecture is very helpful.

Bear in mind also, that if the implementation was not Java your bandwidth would be much much more, as an active html page with server calls to validate data on the fly would require more interaction. Your local copy of AFPEx already contains all the data needed for validation of the various elements of the forms, standard routes for IFR flights, etc.

Validation could be done in Javascript in the browser though, couldn't it? The issue is about where the code resides, not what language it's written in. And storing the standard route catalogue at the client is hardly efficient.

Surely the reason for using Java is that this was the way the COTS product worked. NATS wasn't going to develop bespoke software for this purpose, was it?

[IO540]

What does the SRD data do in the client application (or anywhere at all)?

There is no IFR route planning facility I know of, anywhere in all of this.

[FlyUK73]

From talking to many, I suspect most people are unable to execute a file called ats.xjnlp - presumably due to a missing association. That's why, when I downloaded mine (from the Login prompt on your website) I called it ats.xjnlp.jnlp.

That is correct, the helpdesk gets lots of calls about this.

Server load sharing: would you not find that if you drastically reduced the full application download incidence, your server bandwidth would go way down? In the bad old days your servers must have been running flat out serving all those 3.5MB chunks. There aren't that many pilots with UK addresses

AFPEx doesn't only have load sharing for bandwidth sharing, it's also for contingency. The 3 server layout allows for a "majority decision" environment where if one server shows an error the other two can be used to restore it.

Standard routes: how are these used? IFR routes will always be pre-validated via IFPS, otherwise the FP gets a REJ. The majority of IFR routes flown "for real" are not out of the SRD; SRD routes just take you for a scenic flight around Paris with a 200nm radius

These are the routes contained with the the UK SRD, which are NATS' preferred IFR routes updated monthly and uploaded to the server.

Sorry, that just doesn't sound true - what sort of validation is going on that would require AJAX interactions that would compare to a 3.8 Java Mbyte download every month or so?

Nearly every item in every form is validated; there are many forms on AFPEx not just the flight plan form. I'm not going to extrapolate the values for you, but in terms of reliability on low bandwidth lines, a single prevalidated message is far more efficient/quick than a huge number of Ajax calls. Also, if the server is unavailable for short periods, local validation can continue.

A more likely explanation is 'we had this Java application developed for inhouse use, and decided that rather than build a scalable web application for external use, given the likely number of users, we'd foist the Java application on them instead'...and that would be a reasonable explanation - but don't try and bulls**t anyone into thinking this is a better solution than a pure browser-based implementation.

So many assumptions; no facts. I won't rise to your hostility, it's not worth the wear on the keys of my keyboard.

Even if we accept that it is more efficient to have the validation done locally, why does the *whole* thing have to be downloaded to reflect changes in the data? - unless you're constantly adding functionality with every release, then the changes to the validation data should be an incremental download - at least, it should be in anything with a remotely decent architecture.

Again, assumptions. When the version of software changes it is good (and common in the industry) practice to install the whole application again. 3.8mb is smaller than most OS security patches so hardly a major download. AFPEx has made many changes to the software recently, mainly because of feedback from users, which is a good thing I'm told.

Validation could be done in Javascript in the browser though, couldn't it? The issue is about where the code resides, not what language it's written in. And storing the standard route catalogue at the client is hardly efficient.

It could, but there are many fields that need to be checked semantically and syntactically and the Javascript validation would fail on the first hurdle if it is switched off at the browser. The SRD is currently is downloaded on the fly, so if you don't use it you don't download it.

Surely the reason for using Java is that this was the way the COTS product worked. NATS wasn't going to develop bespoke software for this purpose, was it?

Yes, the COTS product was Java and for many reasons it was chosen as a suitable interface. Bespoke software is a thing of the past for most smaller projects, especially with so many good applications already out there.

What does the SRD data do in the client application (or anywhere at all)?

If you look under View, Preferential Routes on the APFEx terminal you will find them. Bear in mind that this is set to be downloaded as required so when you view that menu there will be a large download.

I'm happy to reply to most questions, but this is not in an official NATS capacity and I most certainly will not reply to hostility either toward me or NATS as I do this in my own time to try to help as best I can.

[IO540]

Your replies here are much valued, FlyUK73

These are the routes contained with the the UK SRD, which are NATS' preferred IFR routes updated monthly and uploaded to the server.

I am only a mere private IFR pilot but IMHO almost nobody flies SRD routes. Many of them are unworkable due to poor efficiency, and anyway most IFR enroute controllers don't operate them. Them seem to be mostly the end product of jostling for airspace by the diverse groups that own airspace (the military being a principal player, and much of the routing nonsense is to avoid huge chunks of empty military airspace).

It would thus seem to me to be a less than optimal allocation of resources to not have AFPEx as a simple website, for the sake of this kind of facility.

AIUI, most commercial IFR users get dedicated departments (or flight support services such as Jepp) to work out airway routes for them, and private IFR pilots use recently developed routing tools. So I don't see much actual real usage for standard route data in a tool whose user profile is that of AFPEx. Especially as the routes are UK only.

3.8mb is smaller than most OS security patches so hardly a major download.

True; however this remains a major issue for mobile internet users. The only ones who won't care will be ones who never fly abroad (and don't pay roaming charges) or ones on £40+/month contracts (which comes with enough "free" roaming data included).

Anybody with a laptop with mobile internet will very thoroughly turn off all windoze and other updates otherwise.... bang there goes your whole SIM card account; on a fast 3G connection you blow money away at anything up to about £40/minute

AFPEx is now a very good tool but the incidence of the whole application download needs to be somehow controlled, for "us" travelling pilots.

Also, could you please lengthen the login session timeout? It is only so many minutes. I don't think the short timeout aids security because if the machine is not physically secure, there is no security anyway because it takes only seconds to install a keylogger... (the banks know this too but cannot admit it ).