jesse
Touchdown! Greaser!
I dunno. Let me guess at a quick number of records here... There's what, um... Guessing here... Let's use round numbers... 300 charts including Canada, VFR, IFR, etc. Call it 500... (I'd go count but I'm being lazy.)
The next is an even bigger guess but I'll go high... 100,000 ChartCase users? (Probably way high.)
Tagging each chart with a, say... Ten character unique hash (also a guess as to how many uniques you'd need before you could re-use one... 'cause I don't want to do the math while I'm eating lunch), that's 5000 characters to transmit from the mobile device to know what charts it has installed at first, and need only transmit changes after that if the DB says it has the list.
Add some overhead since it'd probably be wise these days to stuff that into XML to make the coder's lives easier. Go crazy, call it 6000 characters to send.
As for the DB, a 100,000 by 500 record table is tiny. There'd obviously be some overhead there too, but they already have a DB of subscribers, so this is an addition of a table with 500 booleans to the existing DB. Could just stash the incoming string and post-process it later, into the booleans, too.
So 500 booleans in a referenced table against "customerID"... From a DBA perspective, that's tiny.
The challenge is the code to send the update, something to parse it on the receiving end, on the inbound side. That's cake. Much of the code stricture is already there. If you launch the App it sets a badge and knows what needs to be updated.
Just need to move that code from iOS to a central server.
All depends on how they implemented that piece as to how portable it is from iOS to say, C or Perl, or ... shudder... Python.
The heavy-hitter code would be the SQL query to compare each user against a master "current release" table, and build the badge notifications and send them. I think a modern RDBMS could easily handle the queries for that in a reasonable amount of time, the CPU burnt by the program/script could be throttled since it doesn't need to be done in near-real-time. A few hours after chart release is great. Up to a day is tolerable. And the fallback is the already existing code on the iOS side if the notification system barfs.
I don't think it's as insurmountable as it might seem on the surface. But I do understand if it's not a priority. I definitely don't think it's a "huge" database. They're storing almost as much data against my userID just to have my address info, contact info, etc. And booleans are wicked fast in any good RDBMS. Way faster than retrieving a VARCHAR with my e-mail address.
Just thoughts. I'm not complaining. It isn't *that* hard. Not quite "low-hanging fruit" either, though.
It's not really that it's that big of a database - as much as it's a project that requires man hours and it's obviously not that big of a concern for them.
What your missing is the knowledge of iOS and what you can and can't accomplish (which equates to not much without the user executing the app).
It'd be difficult to build it in a way that would be accurate. For example, if iOS suddenly decides to delete charts in the application (which it can do), the application then has no idea it happened and neither does the Foreflight central server. Therefore it can't push a badge to the device to tell it that it needs to download charts.
Basically I can think up about 10 ways this could get out of sync. That's only with about 30 seconds of thought into developing this feature. There are probably some other major PITA issues I haven't thought of.
Instead of them trying to track all this with an incremental badge that informs you when you have available downloads -- I'd prefer they just push a notification to *ALL* devices everytime a new chart comes out that pops up and tells you that it happened (which they could do).
Honestly it's never really an issue for me....
Last edited:
