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?
Making an eServices App would be a good start.
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.
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.
Quote from: Eclipse on April 24, 2011, 11:17:30 PM
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.
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.
Quote from: JeffDG on April 24, 2011, 11:22:03 PM
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.
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.
I love the geotagged log idea... that is sweet!
Quote from: JC004 on April 24, 2011, 11:26:34 PM
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.
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.
Quote from: Tubacap on April 25, 2011, 01:13:23 AM
I love the geotagged log idea... that is sweet!
You're a beta tester.
Quote from: Eclipse on April 25, 2011, 01:21:35 AM
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.
bring it!
Quote from: JC004 on April 25, 2011, 01:22:53 AMAre 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.
Quote from: JeffDG on April 24, 2011, 11:22:03 PM
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.
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/
Quote from: JoeTomasone on April 25, 2011, 02:01:25 AM
Quote from: JeffDG on April 24, 2011, 11:22:03 PM
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.
Quote from: Eclipse on April 25, 2011, 01:57:11 AM
Quote from: JC004 on April 25, 2011, 01:22:53 AMAre 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.
^ 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.''
Quote from: JoeTomasone on April 25, 2011, 02:01:25 AM
Quote from: JeffDG on April 24, 2011, 11:22:03 PM
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.
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.
I've got android, I am willing to beta-test any CAP apps.
Quote from: JC004 on April 25, 2011, 01:22:53 AMAre 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.
They are FCC rules, not FAA rules.
The FAA says, if its not in writing it doesn't exist. Keep that in mind.
Plus, there was a monthly safety briefing on geo caching. You may want to read on capnhq befoe you go into detail. I have a epic 4g, I would love an app for cap. Though, keep low battery power inmind.
Quote from: SarDragon on April 25, 2011, 04:44:47 AM
Quote from: JC004 on April 25, 2011, 01:22:53 AMAre 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.
They are FCC rules, not FAA rules.
Yes. They said. ^^^
Quote from: ElectricPenguin on April 25, 2011, 04:50:59 AM
Plus, there was a monthly safety briefing on geo caching. You may want to read on capnhq befoe you go into detail. I have a epic 4g, I would love an app for cap. Though, keep low battery power inmind.
Actually, the briefing was on geotagging. Geocaching is a whole other thing entirely.
Interesting parallel story
http://www.cnn.com/2011/TECH/mobile/04/22/first.army.smartphone.android/index.html?hpt=Sbin (http://www.cnn.com/2011/TECH/mobile/04/22/first.army.smartphone.android/index.html?hpt=Sbin)
Quote from: Tubacap on April 25, 2011, 02:05:15 PM
Interesting parallel story
http://www.cnn.com/2011/TECH/mobile/04/22/first.army.smartphone.android/index.html?hpt=Sbin (http://www.cnn.com/2011/TECH/mobile/04/22/first.army.smartphone.android/index.html?hpt=Sbin)
No reading stories! You're supposed to be dropping your work to make plates for an app!
Something like this may already exist, but I'm not the most tech savy guy in the world so I don't know about it...
As a PAO and PIO in training, also R&R, ES, and general "hey I need help come here" guy, I use my IPhone extensively to shoot off texts and emails on the go. It becomes a MAJOR pain in the but to dig through all my contacts to find the 5 staff officers I need. And, if I want to send something to all members, forget it, I'll just wait till I get to a computer...
What would really help me is a contact management app that allows me to:
1. Create a CAP contact list (phone number and email, and hmm maybe even address and emergency contact info could be useful during missions) that is separate from my personal and business contacts, as that section is cluttered enough already. An icon on my home screen taking me straight to it would be best to keep it separate.
2. Create "sub-lists" or mailing lists for mas texts/emails. For example all SM's, all command staff, all media contacts (for press releases, etc during missions,) Group and Wing PAO's, etc.
3. Enables contact sharing
4. Is easy to use on the go, during busy multitasking and high stress situations.
I'd think that could be done with a contacts app.
I've been playing with the Android development a bit more. If people have additional ideas or would like to use some of the tools below to draw up a concept for this, I can try to develop something before I run out of time.
Quote from: JC004 on April 25, 2011, 02:21:00 AM
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/