AFPEx and smartphones
Join Date: Sep 2003
Location: UK,Twighlight Zone
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
AFPEx really needs to be a straight HTML tool with no downloads and be truly platform agnostic to be of proper value.
As IO points out the cost of operating it on roaming GPRS/3G is expensive and it ties the app to laptop devices rather than mobile devices.
As IO points out the cost of operating it on roaming GPRS/3G is expensive and it ties the app to laptop devices rather than mobile devices.
Join Date: May 2005
Location: Abroad
Posts: 1,172
Likes: 0
Received 0 Likes
on
0 Posts
AFPEx really needs to be a straight HTML tool with no downloads and be truly platform agnostic to be of proper value.
(when eventually agreed upon that is
)(and btw, Java is so 1990's
Decent if not quite novel idea, but horrible kludge of an implementation IMO)(and for a last set of parentheses, may I suggest using deltas [binary diffs] for updates? I don't think nowadays "updating the whole application" is taken literally, even if conceptually true... certainly not in my domain)
Join Date: Jan 2008
Location: Heathrow
Posts: 19
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
AFPEx really needs to be a straight HTML tool with no downloads and be truly platform agnostic to be of proper value.
As IO points out the cost of operating it on roaming GPRS/3G is expensive and it ties the app to laptop devices rather than mobile devices.
As IO points out the cost of operating it on roaming GPRS/3G is expensive and it ties the app to laptop devices rather than mobile devices.
HTML5 anyone?
(when eventually agreed upon that is
)
(and btw, Java is so 1990's
Decent if not quite novel idea, but horrible kludge of an implementation IMO)
(when eventually agreed upon that is
)(and btw, Java is so 1990's
Decent if not quite novel idea, but horrible kludge of an implementation IMO)
(and for a last set of parentheses, may I suggest using deltas [binary diffs] for updates? I don't think nowadays "updating the whole application" is taken literally, even if conceptually true... certainly not in my domain)
The host nation should provide you with plan filing facilities though, usually through the local flight centre or departure tower. Alternatively you can send both legs before departure and activate them as required.
Join Date: Jan 2008
Location: Heathrow
Posts: 19
Likes: 0
Received 0 Likes
on
0 Posts
You can send the outbound and inbound leg for a trip to france at the same time, for example, and ask the tower to send a DEP message (activation) on departure from the UK and then ask the French to send a DEP on your departure from their airfield. As long as they were all addressed correctly everybody should have a copy of your plan and know which plan you are referring to.
Messages for onward legs can be also sent at the same time for three leg journeys, four leg, etc.
Messages for onward legs can be also sent at the same time for three leg journeys, four leg, etc.
Join Date: Jun 2003
Location: EuroGA.org
Posts: 13,787
Likes: 0
Received 0 Likes
on
0 Posts
In that case, what time/day of departure should I specify? I cannot file a FP without giving these details.
I realise I can file a FP for some date up to 5 days ahead (IFR) and then phone your ever helpful person at Swanwick and ask him/her to re-file the FP with today's date etc, but I don't think that's quite what you meant. There are at least two issues with that:
1) a Eurocontrol route which validates for say Friday this week may fail to validate if re-filed for today 3pm - this one has caught me a number of times and each time was at the most awkward situation possible (the fact that one is making a phone call to Swanwick implies that one's access to "IT" is severely limited
)
2) to some extent, in some places, a filed FP acts as PPR/PNR
I realise I can file a FP for some date up to 5 days ahead (IFR) and then phone your ever helpful person at Swanwick and ask him/her to re-file the FP with today's date etc, but I don't think that's quite what you meant. There are at least two issues with that:
1) a Eurocontrol route which validates for say Friday this week may fail to validate if re-filed for today 3pm - this one has caught me a number of times and each time was at the most awkward situation possible (the fact that one is making a phone call to Swanwick implies that one's access to "IT" is severely limited
)2) to some extent, in some places, a filed FP acts as PPR/PNR
Join Date: Feb 2002
Location: Dublin
Posts: 2,547
Likes: 0
Received 0 Likes
on
0 Posts
I understand the wish to ensure that users stay up to date with new version. However is it really essential that they do that straight away?
Would it not be possible to allow users 30 days to update, or x number of log ins. During this period they could be reminded of the need to update. After the end of it, then you would have to update before being able to continue.
That would ensure that users did stay up to date, but allow them the option of choosing to do so when connected to a non gsm network.
Workable or not?
Would it not be possible to allow users 30 days to update, or x number of log ins. During this period they could be reminded of the need to update. After the end of it, then you would have to update before being able to continue.
That would ensure that users did stay up to date, but allow them the option of choosing to do so when connected to a non gsm network.
Workable or not?
Join Date: Apr 2008
Location: UK
Posts: 8
Likes: 0
Received 0 Likes
on
0 Posts
Sorry guys, but an update has to be deployed across all 3 servers and running two different versions is not feasible. However, we will look at a better way of notification for software updates in order to give you a chance to get the update before departing from home.
On the JAVA subject, as FlyUK73 said, that was what was on the market at the time. However, that doesn't mean to say that we don't listen and don't look at options on how the system can evolve, including using a non-Java based application.
That's not a guarantee that it will change and if it did, it won't be overnight. But, never say never
On the JAVA subject, as FlyUK73 said, that was what was on the market at the time. However, that doesn't mean to say that we don't listen and don't look at options on how the system can evolve, including using a non-Java based application.
That's not a guarantee that it will change and if it did, it won't be overnight. But, never say never
Join Date: Jun 2003
Location: EuroGA.org
Posts: 13,787
Likes: 0
Received 0 Likes
on
0 Posts
I would not write off mobile users as a small group.
A mobile user is any pilot who has filed a flight plan at home, flown somewhere, stayed there doing some variable-time task (so he could not file the return flight plan from home), and then he has to file the return flight plan using some mobile means.
And somebody flying a multi-leg trip will definitely not be pre-filing.
It's of course true that there is wifi, internet cafes, etc. But things have moved on since the heyday of unsecured wifi and - where you can get a connection at all, which is basically nowhere outside city centres i.e. most airports!! - the whole business has become a giant ripoff, with £20-40/day billing and potentially recurring CC charges. Internet cafes are the last place you want to search for in some strange town, and most of them stink of fag smoke, never mind the smashed up keyboards. And one cannot run the AFPEx Java app on a typical locked-down cafe computer, which leaves own-laptop connection, and I know only too well that most cafes don't allow a laptop connection. All doable of course (cafes and bars with wifi etc) but what a hassle.
On more than one occassion (like landing somewhere where they won't sell you avgas, alleged lack of PPR, etc) I have had to file a new FP from the cockpit (on GPRS/3G obviously - no wifi on the apron).
That leaves the departure airport, but filing a flight plan the old way (handwritten form) can be another hour wasted, messing around a non English speaking airport. Once one gets out of the English-fluent countries, at most "international" airports one is hard pressed to find anybody who speaks English, and in that I include the "tourist information" desk
This is why, 99% due to the "application download" uncertainty, I still maintain a 37 euro/year Homebriefing.com account, but it almost never gets used because there is EuroFPL (which only does IFR which is no good for 99% of UK private pilots). Also HB have trashed their website by using some trendy designer; 2MB of data last time I checked.
The other 1% is that AFPEx only just about runs on GPRS, and GPRS represents the vast majority of mobile data access; 3G has poor coverage outside city centres etc. I was running it on GPRS today; it did hang in there but only just. I think the timeouts need to be a bit longer.
One could argue mobile FP-filing users are a small group, but FP-filing pilots are a tiny group anyway; you don't "need" FPs for the UK. Yet plenty of people do file flight plans... enough to create work for loads of people in the now-closed FBUs... (reportedly 3000 flight plans per month) and they must be going somewhere.
Anway I know I've ranted on about this enough, and it's good to hear you are listening 
Mac users are a totally different group - purely fashion conscious people with loads of money
A mobile user is any pilot who has filed a flight plan at home, flown somewhere, stayed there doing some variable-time task (so he could not file the return flight plan from home), and then he has to file the return flight plan using some mobile means.
And somebody flying a multi-leg trip will definitely not be pre-filing.
It's of course true that there is wifi, internet cafes, etc. But things have moved on since the heyday of unsecured wifi and - where you can get a connection at all, which is basically nowhere outside city centres i.e. most airports!! - the whole business has become a giant ripoff, with £20-40/day billing and potentially recurring CC charges. Internet cafes are the last place you want to search for in some strange town, and most of them stink of fag smoke, never mind the smashed up keyboards. And one cannot run the AFPEx Java app on a typical locked-down cafe computer, which leaves own-laptop connection, and I know only too well that most cafes don't allow a laptop connection. All doable of course (cafes and bars with wifi etc) but what a hassle.
On more than one occassion (like landing somewhere where they won't sell you avgas, alleged lack of PPR, etc) I have had to file a new FP from the cockpit (on GPRS/3G obviously - no wifi on the apron).
That leaves the departure airport, but filing a flight plan the old way (handwritten form) can be another hour wasted, messing around a non English speaking airport. Once one gets out of the English-fluent countries, at most "international" airports one is hard pressed to find anybody who speaks English, and in that I include the "tourist information" desk
This is why, 99% due to the "application download" uncertainty, I still maintain a 37 euro/year Homebriefing.com account, but it almost never gets used because there is EuroFPL (which only does IFR which is no good for 99% of UK private pilots). Also HB have trashed their website by using some trendy designer; 2MB of data last time I checked.
The other 1% is that AFPEx only just about runs on GPRS, and GPRS represents the vast majority of mobile data access; 3G has poor coverage outside city centres etc. I was running it on GPRS today; it did hang in there but only just. I think the timeouts need to be a bit longer.
One could argue mobile FP-filing users are a small group, but FP-filing pilots are a tiny group anyway; you don't "need" FPs for the UK. Yet plenty of people do file flight plans... enough to create work for loads of people in the now-closed FBUs... (reportedly 3000 flight plans per month) and they must be going somewhere.
Anway I know I've ranted on about this enough, and it's good to hear you are listening
Mac users are a totally different group - purely fashion conscious people with loads of money
Join Date: May 2005
Location: Abroad
Posts: 1,172
Likes: 0
Received 0 Likes
on
0 Posts
FlyUK73
Just for clarification, can you give us an idea as to your role in the AFPEx team? This is just so that your comments can be put in some context.
At first I assumed you were a developer, but having read this thread a bit more attentively it looks to me like this isn't the case. Project manager or team leader with little or no IT background perhaps, if I may take a guess? Again, the only reason I'm asking is to get a better perspective.
Some comments follow:
This is what told me you're not keeping up with current developments in the IT world.
This is completely orthogonal to product development. It's on the same level as deciding whether to package it in a green or in a blue box.
Mobile computing is the way things are moving. That's one demographic you need to set your eyes on, not IE6 users. I suggest you talk to someone knowledgeable on the current (and developing, as always) state of play in IT or your product will be dead in the water in the next 18 months.
Possibly because the product is so much more valuable to them?
"Should", as you say. That does not always happen--even when not flying internationally.
[ As an aside FWIW, my own solution is to carry a (borrowed) telephone which I use to call one of the French BRIAs (regional flight information and assistance centres), regardless of which country I'm flying in. They are fully competent and very efficient at doing what their name implies, i.e. providing information and assistance, including NOTAM and weather briefings, consulting foreign AIPs, and of course, filing flight plans. Their help has been invaluable on many occasions. ]
That is incorrect--or rather, your focus is wrong. You can catch most of the users, most of the time, and even keep up as the market and technology evolves. In fact, you can do that at very little cost for your organisation.
How? Publish the protocol your application uses to communicate with its servers, and let third party developers work for you, for free, by creating AFPEx clients for their platforms and demographics of choice. That's good enough for the market leaders, and it's good enough for fringe players too. Matter of fact, if your product is worth anything it's only a matter of time before someone reverse engineers it, so save him the trouble.
Just for clarification, can you give us an idea as to your role in the AFPEx team? This is just so that your comments can be put in some context.
At first I assumed you were a developer, but having read this thread a bit more attentively it looks to me like this isn't the case. Project manager or team leader with little or no IT background perhaps, if I may take a guess? Again, the only reason I'm asking is to get a better perspective.
Some comments follow:
IE6
to implement binary diffs [....] is a significant branch variation on a COTS product
mobile users are a miniscule percentage of AFPEx users
International mobile AFPEx users are [....] a very vocal minority.
The host nation should provide you with plan filing facilities though
[ As an aside FWIW, my own solution is to carry a (borrowed) telephone which I use to call one of the French BRIAs (regional flight information and assistance centres), regardless of which country I'm flying in. They are fully competent and very efficient at doing what their name implies, i.e. providing information and assistance, including NOTAM and weather briefings, consulting foreign AIPs, and of course, filing flight plans. Their help has been invaluable on many occasions. ]
It's a fact of software development today that the sheer range of operating systems, browsers and other settings/requirements within the user pool makes it impossible to catch 100% of users 100% of the time.
How? Publish the protocol your application uses to communicate with its servers, and let third party developers work for you, for free, by creating AFPEx clients for their platforms and demographics of choice. That's good enough for the market leaders, and it's good enough for fringe players too. Matter of fact, if your product is worth anything it's only a matter of time before someone reverse engineers it, so save him the trouble.
Last edited by LH2; 3rd Mar 2010 at 01:21. Reason: typo
Join Date: Jul 2006
Location: Western Australia
Posts: 19
Likes: 0
Received 0 Likes
on
0 Posts
Check this out NAIPS for iPhone This works for the iPhone to file flight plans etc etc here in Australia. The author might be prepared to do a little development work to get it to work with AFPex. Or someone could buy this and use it as the basis of their own European version.
Join Date: Sep 2003
Location: UK,Twighlight Zone
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
An iPhone/iPad version would be amazing. However an HTML version is really the way to go. There is no reason at all for using the JAVA client.
It is not rocket science, all people really want is a quick and simple way of filing a flight plan!! We don't need all the fancy messaging services of the AFPEx tool in reality.
As someone who files many flight plans, I would just love a web page with a standard flight plan form on it that has the addressing in drop down boxes and you just fill it in and click send, then check for the ACK. Or even get the ACK by email.
Assuming that mobile users are a minority is breathtakingly arrogant. They are the MAJORITY, it is just the service drives us to fixed platforms and that makes you blind to it.
God knows why it has to be so difficult.
It is not rocket science, all people really want is a quick and simple way of filing a flight plan!! We don't need all the fancy messaging services of the AFPEx tool in reality.
As someone who files many flight plans, I would just love a web page with a standard flight plan form on it that has the addressing in drop down boxes and you just fill it in and click send, then check for the ACK. Or even get the ACK by email.
Assuming that mobile users are a minority is breathtakingly arrogant. They are the MAJORITY, it is just the service drives us to fixed platforms and that makes you blind to it.
God knows why it has to be so difficult.
Last edited by S-Works; 3rd Mar 2010 at 09:08.
Join Date: Jun 2003
Location: EuroGA.org
Posts: 13,787
Likes: 0
Received 0 Likes
on
0 Posts
Check this out NAIPS for iPhone This works for the iPhone to file flight plans etc etc here in Australia. The author might be prepared to do a little development work to get it to work with AFPex. Or someone could buy this and use it as the basis of their own European version.
If the former, "anybody" can knock up such an application. Some websites do a lot of spurious token exchanges to prevent "scripting" but it never takes more than a few hours to work it out.
If the latter, it could take a huge amount of work. Not with an HTTPS browser (which uses standard protocols) but with a custom Java app like here. But the real issue, IMHO, is that NATS would pull the facility if somebody did this. It would have to be done with their approval.
It seems obvious to suggest that a cut-down version of the app, doing just FP filing with just the ICAO form and nothing else, would be useful to many pilots. This I am sure is true, and maybe NATS should examine that possibility. Like I said, AFPEx has dragged a lot of apparently totally non IT literate pilots out of the woodwork and they would appreciate a dead simple user interface.
However, some of the other features are dead handy e.g. free text AFTN messages, and the ability to delay flight plans. And if one has enough functionality for that (delaying largely implies retrieving the old one and editing it, though this isn't strictly necessary) one is practically looking at the existing app as it stands.
Join Date: Jan 2008
Location: Heathrow
Posts: 19
Likes: 0
Received 0 Likes
on
0 Posts
In that case, what time/day of departure should I specify? I cannot file a FP without giving these details.
I would not write off mobile users as a small group.
Just for clarification, can you give us an idea as to your role in the AFPEx team? This is just so that your comments can be put in some context.
At first I assumed you were a developer, but having read this thread a bit more attentively it looks to me like this isn't the case. Project manager or team leader with little or no IT background perhaps, if I may take a guess? Again, the only reason I'm asking is to get a better perspective.
At first I assumed you were a developer, but having read this thread a bit more attentively it looks to me like this isn't the case. Project manager or team leader with little or no IT background perhaps, if I may take a guess? Again, the only reason I'm asking is to get a better perspective.
This is what told me you're not keeping up with current developments in the IT world.
This is completely orthogonal to product development. It's on the same level as deciding whether to package it in a green or in a blue box.
Mobile computing is the way things are moving. That's one demographic you need to set your eyes on, not IE6 users. I suggest you talk to someone knowledgeable on the current (and developing, as always) state of play in IT or your product will be dead in the water in the next 18 months.
Possibly because the product is so much more valuable to them?
"Should", as you say. That does not always happen--even when not flying internationally.
[ As an aside FWIW, my own solution is to carry a (borrowed) telephone which I use to call one of the French BRIAs (regional flight information and assistance centres), regardless of which country I'm flying in. They are fully competent and very efficient at doing what their name implies, i.e. providing information and assistance, including NOTAM and weather briefings, consulting foreign AIPs, and of course, filing flight plans. Their help has been invaluable on many occasions. ]
It's a fact of software development today that the sheer range of operating systems, browsers and other settings/requirements within the user pool makes it impossible to catch 100% of users 100% of the time.
That is incorrect--or rather, your focus is wrong. You can catch most of the users, most of the time, and even keep up as the market and technology evolves. In fact, you can do that at very little cost for your organisation.
How? Publish the protocol your application uses to communicate with its servers, and let third party developers work for you, for free, by creating AFPEx clients for their platforms and demographics of choice. That's good enough for the market leaders, and it's good enough for fringe players too. Matter of fact, if your product is worth anything it's only a matter of time before someone reverse engineers it, so save him the trouble.
Assuming that mobile users are a minority is breathtakingly arrogant. They are the MAJORITY, it is just the service drives us to fixed platforms and that makes you blind to it.
If the latter, it could take a huge amount of work. Not with an HTTPS browser (which uses standard protocols) but with a custom Java app like here. But the real issue, IMHO, is that NATS would pull the facility if somebody did this. It would have to be done with their approval.
It seems obvious to suggest that a cut-down version of the app, doing just FP filing with just the ICAO form and nothing else, would be useful to many pilots. This I am sure is true, and maybe NATS should examine that possibility. Like I said, AFPEx has dragged a lot of apparently totally non IT literate pilots out of the woodwork and they would appreciate a dead simple user interface.
Join Date: Jun 2003
Location: EuroGA.org
Posts: 13,787
Likes: 0
Received 0 Likes
on
0 Posts
In theory, you should be able to plan and submit up to 5 days in advance, but if the route is not available on the day it is beyond all but Eurocontrol's control. Many airlines use RPLs that are planned months in advance, so they must find a way around it.
Fixing broken routes is a marvellous job creation scheme at IFPS, but one can bet that the one time you really are up the **** creek and really want the RMK IFPS REROUTE ACCEPTED to work, IFPS will wash their hands of it (as they are absolutely entitled to do).
I am no "sky god" but having been caught by this a few times I would never file a flight plan 5 days in advance and
a) expect the route to still validate when I change the DOF/ after say 3-4 days (especially if I change the DOF/ between a weekday day and a weekend day, which changes many airways)
b) expect to be able to depart as planned after such a long time (weather etc)
The only way to work the IFR system reliably is to be able to, on the day of the flight or shortly before, develop a valid route, and file the flight plan with it. Anything else is a bonus, and often breaks.
That is why a well usable mobile-internet application is desirable. It's not hard to do, at all. It should have just been in the original specification
You are nearly there now; you just need to sort out the version control and publish a fixed update schedule, say 1st of each month, not force a download of the update for the whole of the following month, and for each update publish which features of the previous version will not continue to work after the update date (for people who are unable do do the download when they are away). Downloading 4MB is trivial if people know when they need to do it.
Last edited by IO540; 4th Mar 2010 at 06:09.
Join Date: Jun 2003
Location: EuroGA.org
Posts: 13,787
Likes: 0
Received 0 Likes
on
0 Posts
I ran the (hibernated) Java app this morning, to see if it is asking for a software update, and while it did ask, the old one apparently continues to work i.e. no update is forced. This is good.
However, when I came to download a fresh one (by running the little Java loader that I always use) it didn't download a fresh one but instead started the cached version.
Going to the NATS website (using Firefox) and using the Login method does download the fresh app.
I also noticed that the Java loader (that gets downloaded when one goes to the URL) changed this morning between about 8am and about 9am, from TS1 to TS3. One of these downloaded a fresh app, while the other one started the old cached one.
So it looks like NATS are doing their load sharing by dynamically editing the loader app.
This presumably illustrates FlyUK's advice to start the app by going to the www.flightplanningonline.co.uk (NOT the one with ts1/ts2/ts3 in it) URL rather than by running the Java loader - at least, I guess, when an update is suspected and you really do want the latest version.
I do have an issue with a fresh install of IE8 on a laptop - it doesn't know what to do with the file even though that computer has been used with AFPEx many times. I suspect a filetype association issue; this may be a common thing.
I also noticed this morning that the NATS server is far faster than before; downloaded the ~3-4MB app in about 10 seconds.
However, when I came to download a fresh one (by running the little Java loader that I always use) it didn't download a fresh one but instead started the cached version.
Going to the NATS website (using Firefox) and using the Login method does download the fresh app.
I also noticed that the Java loader (that gets downloaded when one goes to the URL) changed this morning between about 8am and about 9am, from TS1 to TS3. One of these downloaded a fresh app, while the other one started the old cached one.
So it looks like NATS are doing their load sharing by dynamically editing the loader app.
This presumably illustrates FlyUK's advice to start the app by going to the www.flightplanningonline.co.uk (NOT the one with ts1/ts2/ts3 in it) URL rather than by running the Java loader - at least, I guess, when an update is suspected and you really do want the latest version.
I do have an issue with a fresh install of IE8 on a laptop - it doesn't know what to do with the file even though that computer has been used with AFPEx many times. I suspect a filetype association issue; this may be a common thing.
I also noticed this morning that the NATS server is far faster than before; downloaded the ~3-4MB app in about 10 seconds.
Last edited by IO540; 5th Mar 2010 at 08:09.