CAP Android App?

[JC004]

I spent a few hours this morning building a couple Android apps for some projects of mine.

I got to thinking...if you could have an Android app for CAP ES purposes - mission management and such, what would it do?

Are there specific tasks that could be made into an Android app for CAP that would make things easier than having existing or separate apps?

[HGjunkie]

Making an eServices App would be a good start.

[JeffDG]

One that I've thought of would be an Android "Observer's Log", where you had buttons for stuff like wheels-up time, in area, able to log observations (all tagged with date/time and GPS location), ultimately with an e-mail option to send to the debriefing officer.  Even better would be the ability to use DropBox to send the file, then the IC/OSC/PSC/AOBD could set up a mission share in DropBox, and everyone could dump logs into there for the final mission paperwork.

It takes advantage of the features of the phone (GPS location, timestamping) while doing a discreet job.

[Eclipse]

Geo-located logs would rock for both air and ground teams, especially something which could be tracked ala Latitude by mission base.  Something which
could also be intercepted or watched by Comms would make them happy.

Direct access to WMIRS and eServices would be great as well.

[JeffDG]

Geo-located logs would rock for both air and ground teams, especially something which could be tracked ala Latitude by mission base.  Something which
could also be intercepted or watched by Comms would make them happy.

Direct access to WMIRS and eServices would be great as well.

The problem with WMIRS is they keep changing it...anyone who develops an app that interfaces with WMIRS will spend all of their time fixing it when unannounced changes to the interface break the app.

[JC004]

I just made my first app and it seems pretty easy to do something like a log with geotagging, but how (for air) would data work for interception by mission base?  Ground would be fine, I'd think.

Since there's no API for WMIRS or eServices, someone would have to create a way to connect 'em, but I certainly thought about that.  Secure connections would also be required.

The problem with WMIRS is they keep changing it...anyone who develops an app that interfaces with WMIRS will spend all of their time fixing it when unannounced changes to the interface break the app.

I don't know that I could constantly update like that if I developed an app.  There's a lot that I've wanted to do but I've had limited time to get it done.  I still have tons of ES, CP, and other CAP materials that I've wanted to update and get out but I keep getting wrapped up in other priority projects.

[a2capt]

WMIRS appears to be a miserable task.. IMU essentially presents itself to WMIRS as a browser and takes the returned data and parses the heck out of it, and builds it's submissions as if it were a browser with the submit data being handed back to the server.

[Tubacap]

I love the geotagged log idea... that is sweet!

[Eclipse]

I just made my first app and it seems pretty easy to do something like a log with geotagging, but how (for air) would data work for interception by mission base?  Ground would be fine, I'd think.

The GPS could be active and upload the data as soon as the aircraft is back on the ground.  I use my 3+ in the aircraft on my knee board to record flight tracks, but the ability to log other information would be great as well.

A waypoint or photo logging tool with big onscreen buttons could make life easier as well.

[JC004]

WMIRS and all are lacking.  I'd really like to see a member-developed mission management system.  I developed a prototype once based on a project management system, some GIS, and all that but Wing was dead set on using IMU and they never even looked at it.  I think there are enough coders in CAP to develop a fantastic system like that but that is one of the things, like a spectacular web site and great marketing program that National does not seize upon the potential of the membership by establishing written goals and an infrastructure to support the development.

I only started coding with it yesterday but I'd think if I can get the time, I could develop something like JeffDG proposes.  It would perhaps be a lot easier and faster if there were other developers too.  This is the great potential of member-based, grassroots development of new programs (not computer programs), systems, materials, etc. on which the National people should be focusing in order to move the organization forward in leaps and bounds.  Right now, you have NHQ doing their own things like using their own LOGOS, the volunteer leaders doing something completely different, and the members doing their own things that rarely rise above the squadron, group, or in limited circumstances, the wing.

I don't see any reason why there can't be one or multiple smartphone apps that would greatly enhance the membership's abilities to do their work, but I think it would have to be developed at the grassroots level without the support of higher headquarters.

I love the geotagged log idea... that is sweet!

You're a beta tester.

The GPS could be active and upload the data as soon as the aircraft is back on the ground.  I use my 3+ in the aircraft on my knee board to record flight tracks, but the ability to log other information would be great as well.

A waypoint or photo logging tool with big onscreen buttons could make life easier as well.

Are there any rules that would prohibit the ability of it just uploading when it got data coverage?  I do not know the deal with FAA rules on phones and such.  I don't know if a data transmission could cause an issue.  I am not sure how this works except for the whole "turn off your devices" thing.

[Tubacap]

bring it!

[Eclipse]

Are there any rules that would prohibit the ability of it just uploading when it got data coverage?  I do not know the deal with FAA rules on phones and such.  I don't know if a data transmission could cause an issue.  I am not sure how this works except for the whole "turn off your devices" thing.

No, other than the data service should be turned off when the plane is off the ground.  In this case the FAA allows for the use of various devices at the discretion of the pilot, but the FCC prohibits the use of cell phones in the air.

Assuming the app could queue the information until the data service was turned back on, there should be no problem.

[JoeTomasone]

The problem with WMIRS is they keep changing it...anyone who develops an app that interfaces with WMIRS will spend all of their time fixing it when unannounced changes to the interface break the app.

Same with CAPWATCH; they change the fields periodically.   I have a web based app that ingests and processes CAPWATCH data, and it must be tweaked every so often to account for changes.

[JC004]

Would anyone venture to create a mockup of what such an app might look like?

http://www.droiddraw.org/

For more advanced users, one might want to use http://pencil.evolus.vn/en-US/Home.aspx  and   http://code.google.com/p/android-ui-utils/

or

http://mockupsgallery.com/

[Fubar]

The problem with WMIRS is they keep changing it...anyone who develops an app that interfaces with WMIRS will spend all of their time fixing it when unannounced changes to the interface break the app.

Same with CAPWATCH; they change the fields periodically.   I have a web based app that ingests and processes CAPWATCH data, and it must be tweaked every so often to account for changes.

It's not often enough to create too much heartache though. A direct API would be better, it stinks having to manually upload the text files.

[Spaceman3750]

Are there any rules that would prohibit the ability of it just uploading when it got data coverage?  I do not know the deal with FAA rules on phones and such.  I don't know if a data transmission could cause an issue.  I am not sure how this works except for the whole "turn off your devices" thing.

No, other than the data service should be turned off when the plane is off the ground.  In this case the FAA allows for the use of various devices at the discretion of the pilot, but the FCC prohibits the use of cell phones in the air.

Assuming the app could queue the information until the data service was turned back on, there should be no problem.

According to our wing DO, FAA/FCC rules only prohibit phones on the 800MHz band, which apparently isn't used by modern cell phones, so it could be used. I haven't done any investigation into either claim though.

[Eclipse]

^ He has a somewhat "creative" interpretation of what is still a pretty clear prohibition, still technically necessary or not.
There is no allowance for what band, etc.

See 47 CFR § 22.925

§ 22.925 Prohibition on airborne operation of cellular telephones.
Cellular telephones installed in or carried aboard airplanes, balloons or any other type of aircraft must not be operated while such aircraft are airborne (not touching the ground). When any aircraft leaves the ground, all cellular telephones on board that aircraft
must be turned off. The following notice must be posted on or near each cellular telephone installed in any aircraft:
''The use of cellular telephones while this aircraft is airborne is prohibited by FCC rules, and the violation of this
rule could result in suspension of service and/or a fine. The use of cellular telephones while this aircraft is on the
ground is subject to FAA regulations.''

[JeffDG]

The problem with WMIRS is they keep changing it...anyone who develops an app that interfaces with WMIRS will spend all of their time fixing it when unannounced changes to the interface break the app.

Same with CAPWATCH; they change the fields periodically.   I have a web based app that ingests and processes CAPWATCH data, and it must be tweaked every so often to account for changes.

But at least they announce the changes to the data tables in CAPWATCH...not so with WMIRS...

It seems that they simply figure out how IMU is doing stuff and intentionally make changes to break it.

What is needed is a set of documented, change-controlled Web Service calls into IMU for things like authentication, Creating, Editing and Deleting Sorties.  Along with that would be a commitment from NHQ not to change these interfaces without prior notification.  Same goes for eServices.

These are critical to any member-created mission management tools...otherwise you spend so much time fixing the WMIRS interface that you can't make the tool work better.

[JC004]

Let's try not to create a whole argument over FAA and FCC rules.  If someone knows a legal officer or someone else with authority on this topic (like an FAA person), that would be great.  That would offer some insight on interpretations and such that have been issued as well.

I'd like to see what such an app should look like in its different screens, so if some people would like to play with the tools at the above links (or others), that would be a great place to start.

If there are other people who would like to develop, that would be great because most of my programming experience is limited to the web and PHP.

If there are people who have Android and would like to test, they should make themselves known so that we can make them beta testers, if we can get this thing going.

Based on what I experimented with, I would think that something like the logs would not be too difficult.  Other ideas might be interesting as well.  That is, things that could be used either by teams/individuals/whatever or by mission base people.

Just for clarification:  If I can make time for this and create a deploy-able product, The Triangle Thingy will not be included (except perhaps in a hidden game in which you destroy The Triangle Thingy).  Angry Birds for CAP.  Angry Members in which you fling little CAP aircraft at Triangle Thingies and destroy them.

[HGjunkie]

I've got android, I am willing to beta-test any CAP apps.