CAP ES Smartphone App Project (Android, etc.)

[JC004]

One of my projects is a CAP ES smartphone app. 

I have two in the works:
1.  The log app that was suggested before (figure I will do aircrew log, GT log, etc.)
2.  An app that has all of your task guides, curriculum books, etc. 

The intent of my #2 app is for training and mission reference (easy and fast).

I'm looking for ideas, feedback and people who have experience with smartphone development.

I know it might be a long shot to find developers since I had basically no luck with that before and CAP web developer-types that I asked didn't have any smartphone experience.  Mine is very limited.  It would also be good to have someone who could make the app work for iPhone... I can't find ANY iPhone development people in CAP from my asking around.  Not one person with this experience so far.  Maybe if I could at least find someone who CAN develop for iPhone and simply hasn't before?

Ideas?  Input?  Feedback?  People?  Someone who can make the graphics (have limited success finding CAP graphics people too)?

I want to get this done but my experience here is limited.  I also want to integrate the resources I'm compiling (http://captalk.net/index.php?topic=13700.msg247688#msg247688).

Would you use an app like this (either of the two)?

[ProdigalJim]

I definitely would use both.

I'd also like to see something like an integrated "briefing/sortie" package...you'd have your CAPF104, your ORM, Weight and Balance, observation log, the ability to upload and attach imagery (stupid Safari...), all in one place, referenced to grid squares, etc. Basically all that stuff that, today, we have to grab from different places and scribble on a kneeboard, scratch pad, and so forth.

[JC004]

That might be good to run on Android and also have for iPad and such.  I don't do a lot of aircrew and I'm still trying to figure out some different things about integrating the app, so I'd probably need a couple people - maybe some aircrew people to submit an idea of how that would work/flow/be laid out.

Being able to have CAP apps for tablets could be pretty great.

[HGjunkie]

I don't have many ideas, but I'm willing to help.

[JC004]

Have you developed anything for Android? 

A couple things that I'm trying to figure out right now are how to structure it correctly and how to integrate search.

One idea I just had is to add a checklist for ES gear (which can be customized) and you can check off the stuff you have or wipe the checks clean to do an inspection of your gear.

I am also trying to decide if I should make kind of a training app and a separate operational app, or an all-out ES app that grows and implements different things as people contribute.

[MilesDyson]

I am an software engineer and have worked a little with Android in the past.

What I wanted to do with it was to make use of the compass and GPS to allow a ground team unit member to be tracked on a Google map by mission base, and also to allow the ground team member to see where he is in relation to other CAP members, vehicles and aircraft. It would allow the IC to see where all his assets were on a  map at mission base. It would be great to integrate it with our digital P25 radios for situations where we are away from wireless coverage - use a highbird aircraft to relay the data to/from base our even AFRCC / NOC. I have inquired a bit about doing this but have gotten no interest from leadership, so I am not willing to spend time doing it at this point.

[Eclipse]

It's already done.

https://www.google.com/latitude

Works great, and has native app support for Android and iOS, with web-based support on Blackberry, Windows Mobile, Symbian, and Sony Ericsson.

Cap is light years away from doing anything data-related via P25, and for the most part it is unnecessary.  In 80-90% of our use, cellular data
is up and running, and in the few instances where it isn't, we just make do until it is with old school long/lat manual reports.

The wheel exists, embrace it.

[MilesDyson]

No. Latitude is first of all dependent on a working cellphone system. Does not work in emergencies. Latitude does not provide a CAP specific solution to running a CAP ES mission. Latitude is slow, and frequently in great error (it showed my wife in New Mexico last week when she was out shopping in the midwest).

CAP engineers cannot do anything with data because CAP leadership won't give us an opportunity to show what we can do.

[Eclipse]

Yeah.  OK.

A "CAP-specific solution" is wholly unnecessary and an excuse to leave proven technology and tools lying on the table while pursuing something which
may or may not even be feasible, let alone a good idea.

Anecdotal comments about a situation where one person has an issue which could be anything from user error to poor choice of device isn't going to
do much for your argument, nor does it negate the simple fact that "mature" technologies like HF are just as prone to failure and are no more "guaranteed to work" than anything else.  Not to mention the expense and single-threaded nature of their use.

There are other proven technologies similar to Latitude which might be better or different, most rely on infrastructure of one kind or another,
and everything has fail points and weaknesses, however that doesn't mean you simply dismiss the idea because it "might fail".

Drive a car?  It might fail.  Store your food in a refrigerator?  It might fail.

When it does, you simply adapt.

How long have you been a member?  What most successful members understand, is that in an environment like CAP, the response you will
receive will be much different if you ask "What can do you need?" vs. telling people "This is what you need."

[MilesDyson]

How would you know it is "wholly unnecessary"? You don't even know what I am talking about.

[Eclipse]

You didn't answer the question about your CAP experience.

How would you know it is "wholly unnecessary"? You don't even know what I am talking about.

My experience and understanding of CAP's requirements.

That doesn't mean your idea isn't "cool", or even "better", only that in a world of free / cheap off-the-shelf products, services, and capabilities, for people to be concerned about CAP-specific solutions is generally energy better spent in other areas.

[MilesDyson]

Five years. What does that matter?

[Eclipse]

Five years. What does that matter?

It matters a lot, because the statements you are making would lead one to believe you are brand new and don't have a clear idea how CAP works.

For a new member who hasn't spent any time with the regs and the environment, that's understandable, but for someone who is presumably of a
company-grade with a rating or two under his belt, that smacks of the little guys who spend their time asking for money under bridges.

[N Harmon]

Have you developed anything for Android? 

I have developed for Android using both the AppInventor as well as eclipse with the Android SDK.

AppInventor is pretty limited, but development is very fast. The types of programs you appear to be wanting to make (like weight & balance calculators) can all be done in AppInventor. With the Android SDK you need to have a handle on Java, but you will be able to take full advantage of the features in Android.

[wuzafuzz]

No. Latitude is first of all dependent on a working cellphone system. Does not work in emergencies. Latitude does not provide a CAP specific solution to running a CAP ES mission. Latitude is slow, and frequently in great error (it showed my wife in New Mexico last week when she was out shopping in the midwest).

CAP engineers cannot do anything with data because CAP leadership won't give us an opportunity to show what we can do.

One word: SPOT

It even works where cell phones don't.  The Air Force has had positive things to say about SPOT devices when CAP has used them.

http://www.findmespot.com/en/

Yes, it costs some money.  So does feeding that high-bird.  Heck, it'll even work when the high-bird can't fly.

BTW, if you had watched the national communicators meeting a couple of weeks ago you would have heard them discuss the possibility of sending data over the radio.  If it happens it will be a secure solution, so off the shelf gadgets from Ham Radio Outlet won't cut it.  The goal should be to accomplish the mission for our customers, not to "show what we can do."

[MilesDyson]

No. Latitude is first of all dependent on a working cellphone system. Does not work in emergencies. Latitude does not provide a CAP specific solution to running a CAP ES mission. Latitude is slow, and frequently in great error (it showed my wife in New Mexico last week when she was out shopping in the midwest).

CAP engineers cannot do anything with data because CAP leadership won't give us an opportunity to show what we can do.

One word: SPOT

It even works where cell phones don't.  The Air Force has had positive things to say about SPOT devices when CAP has used them.

http://www.findmespot.com/en/

Yes, it costs some money.  So does feeding that high-bird.  Heck, it'll even work when the high-bird can't fly.

BTW, if you had watched the national communicators meeting a couple of weeks ago you would have heard them discuss the possibility of sending data over the radio.  If it happens it will be a secure solution, so off the shelf gadgets from Ham Radio Outlet won't cut it.  The goal should be to accomplish the mission for our customers, not to "show what we can do."

Would something like this cut it?

http://openhpsdr.org/index.php

[Eclipse]

Would something like this cut it?

http://openhpsdr.org/index.php

As what?

That appears to be a platform, not a system.

However, assuming this incorporates self-hosted / built / maintained servers and systems?

No.

[JC004]

Can we be calm please?  OK...good...thanks.

While we're doing that, let's not discourage people from posting ideas lest they be immediately shot down. 

NOW, there are perhaps different options here.  For example, perhaps a CAP-specific app could interface with, or use another app as a base (Latitude or something else).  I have limited experience with Latitude because I did not have good luck with the location-detection for some reason.  Works fine on my phone in general but for some reason, Latitude wanted to show me somewhere else.  I am not sure why because I thought it would also happen in Google Maps.  I am playing with it right now.  The office in which I am sitting is listed as half a mile away.  Regardless, whatever.  If we built a CAP interface for something else and hooked it together, maybe we get the advantages of the other app and can make it EASY TO USE for members.  That's a HUGE deal.  If I am on a mission, I don't want to try figuring out how to cram another non-CAP technology into a CAP world.  I just want to use it.

It would help to have various ideas out there and work things down from there.  Even potentially sucky ideas can perhaps become good ideas.  You all see?  k.  Good.

I am an software engineer and have worked a little with Android in the past.

What I wanted to do with it was to make use of the compass and GPS to allow a ground team unit member to be tracked on a Google map by mission base, and also to allow the ground team member to see where he is in relation to other CAP members, vehicles and aircraft. It would allow the IC to see where all his assets were on a  map at mission base. It would be great to integrate it with our digital P25 radios for situations where we are away from wireless coverage - use a highbird aircraft to relay the data to/from base our even AFRCC / NOC. I have inquired a bit about doing this but have gotten no interest from leadership, so I am not willing to spend time doing it at this point.

I like this concept and perhaps it would be best built as a CAP app or as an app which interfaces with/feeds off something else.  One concern we have to have is this:  We build on Latitude or something, we have to be prepared for the something to GO AWAY.  Google has been known to shut down a project in a hurry.  Wave, anybody?  Same goes for other companies.  I disagree that we should rely on data coverage being there and not even consider radio.  We had our earthquake last week and I couldn't call anyone for a good while.  Data was totally messed up too - for HOURS.  The other consideration is that there are isolated places where we may need to operate.  There are isolated places in Pennsylvania (well, mostly just one place - north central PA) where data coverage may be spotty or non-existent.  Given the ability to get lost in, say, the Pennsylvania Grand Canyon, we need alternatives to that data coverage.  REDUNDANCY is GOOD in emergency services. 

With that said, let me address your issue with the leadership.  When possible, do not wait for them.  I have been doing CAP technology projects for a lot of years now.  I have been in CAP communications for about 10 years.  When you talk about things with buttons and lights to the leadership in many cases, their heads spin around, their eye glaze over, or they proceed to the nearest cliff and jump. 

I have decided to try some apps (even with my limited experience in this area) specifically because it is something that I can do WITHOUT a huge involvement from the leadership (if any).  Take a look at your project and see what can be done without a commander's buy-in.  See what we could do and just present to them.  I found in the past 12 years that in some cases, the best thing to do is just create it, then show them.  THEN they see it, get it, and say "this is great."  You approach them with just a proposal and something like the aforementioned situation happens. 

If you have read "Solutions for Civil Air Patrol," you have some idea of the types of things that I am experimenting with to see if I can get them implemented despite the election.  You will see that some would ABSOLUTELY REQUIRE leadership buy-in from day one, some would need it to a lessor degree, and some won't need it at all.  Would you be willing to look at this and see what we can accomplish without a huge buy-in?

Don't just throw up your hands as I did a couple years ago.  You will probably regret it and all of us who would benefit will have less great tools.  I will guarantee you that members will use great CAP apps.  I can almost guarantee you that leadership will start getting interested once they see something they can use.  If you trust anyone's experience with this situation, trust mine.  I am the king of collecting great technology ideas for CAP that have been ignored by leadership. 

Have you developed anything for Android? 

I have developed for Android using both the AppInventor as well as eclipse with the Android SDK.

AppInventor is pretty limited, but development is very fast. The types of programs you appear to be wanting to make (like weight & balance calculators) can all be done in AppInventor. With the Android SDK you need to have a handle on Java, but you will be able to take full advantage of the features in Android.

ooooooo.  I have only done one app (as an experiment).  I will probably end up using AppInventor because I went with PHP and therefore know about nothing Java-related.  At one of the places I worked, the president (a Java guru) actively discouraged me from going the Java route and I didn't.  Would you be interested in projects like these?  I think they could make a huge difference to people in the field.

What if I create something in AppInventor and I am limited?  Can I create the app's base, then someone with more experience and skill in this area could just take the code and add what AppInventor can't do?

[MilesDyson]

JC004 - thanks for your comments.

[wuzafuzz]

No. Latitude is first of all dependent on a working cellphone system. Does not work in emergencies. Latitude does not provide a CAP specific solution to running a CAP ES mission. Latitude is slow, and frequently in great error (it showed my wife in New Mexico last week when she was out shopping in the midwest).

CAP engineers cannot do anything with data because CAP leadership won't give us an opportunity to show what we can do.

One word: SPOT

It even works where cell phones don't.  The Air Force has had positive things to say about SPOT devices when CAP has used them.

http://www.findmespot.com/en/

Yes, it costs some money.  So does feeding that high-bird.  Heck, it'll even work when the high-bird can't fly.

BTW, if you had watched the national communicators meeting a couple of weeks ago you would have heard them discuss the possibility of sending data over the radio.  If it happens it will be a secure solution, so off the shelf gadgets from Ham Radio Outlet won't cut it.  The goal should be to accomplish the mission for our customers, not to "show what we can do."

Would something like this cut it?

http://openhpsdr.org/index.php

That's a question for the National Communications Team.  Their comm permissions address was provided to you in another post.  Ask them and see what they say.  However, since it's open source its unlikely it would satisfy the need for secure communications.  Unless your data layer is bulletproof it probably wouldn't fly.

Unfortunately data modes aren't permitted over the air right now.  So experimentation and tinkering are off limits unless prior permission is obtained.  (I know, I know, P25 IS data.)  I look forward to the day we can use data modes; it would be nice to do the kinds of things that MARS does. 

[MilesDyson]

Experimentation and tinkering shouldn't be off limits. We should be constantly trying to improve our abilities to provide service and save lives.

[JC004]

Would something like this cut it?

http://openhpsdr.org/index.php

That's a question for the National Communications Team.  Their comm permissions address was provided to you in another post.  Ask them and see what they say.  However, since it's open source its unlikely it would satisfy the need for secure communications.  Unless your data layer is bulletproof it probably wouldn't fly.

Unfortunately data modes aren't permitted over the air right now.  So experimentation and tinkering are off limits unless prior permission is obtained.  (I know, I know, P25 IS data.)  I look forward to the day we can use data modes; it would be nice to do the kinds of things that MARS does.

Open Source does not equal unsecure.  Ask the NSA:  http://www.nsa.gov/research/selinux/

Experimentation and tinkering shouldn't be off limits. We should be constantly trying to improve our abilities to provide service and save lives.

That is correct.  It is unfortunate that we can't transmit data over the air currently.  This is the disadvantage of not having the packet frequency anymore.  Perhaps this could be fixed or at least a waiver granted for some experimentation. 

We can, however, experiment with various things in smartphone apps.

[Spaceman3750]

I think an application where comm can have general message form on a computer and direct it to a person (PSC, AOBD, GBD, whoever) and when they submit it, it instantly "pings" the recipients phone and computer telling them they have a new message to respond to would be pretty cool. Eliminates the problems lag when comm doesn't have any runners.

If you want the general message forms for your mission folder, the system would have an option to spit all the messages out to a printer on the ICS forms at the end of the day.

[wuzafuzz]

Would something like this cut it?

http://openhpsdr.org/index.php

That's a question for the National Communications Team.  Their comm permissions address was provided to you in another post.  Ask them and see what they say.  However, since it's open source its unlikely it would satisfy the need for secure communications.  Unless your data layer is bulletproof it probably wouldn't fly.

Unfortunately data modes aren't permitted over the air right now.  So experimentation and tinkering are off limits unless prior permission is obtained.  (I know, I know, P25 IS data.)  I look forward to the day we can use data modes; it would be nice to do the kinds of things that MARS does.

Open Source does not equal unsecure.  Ask the NSA:  http://www.nsa.gov/research/selinux/

Experimentation and tinkering shouldn't be off limits. We should be constantly trying to improve our abilities to provide service and save lives.

That is correct.  It is unfortunate that we can't transmit data over the air currently.  This is the disadvantage of not having the packet frequency anymore.  Perhaps this could be fixed or at least a waiver granted for some experimentation. 

We can, however, experiment with various things in smartphone apps.

You got me there, open source does not equal unsecure.  I should have been more careful about what I typed.  However the referenced system was an amateur radio project so it is not secure.  Encryption is prohibited in the amateur radio service.  So it's unlikely an amateur radio project would satisfy any need for secure comms in CAP.

I would love to see APRS in CAP, or something like it, but National has pointed us in a different direction.  We can't do some of the things MARS does, some of which would seem pretty useful in CAP. 

[MikeD]

My brain is fried after 6+ hours of PowerPoint but here's some incoherent thoughts.

Android already has plenty of PDF readers, so I wouldn't bother building an app to contain task guides, etc.  It might be easy (and useful) to have a software hook to call "Open this PDF", and install those PDFs in a known location as part of the app install.  It's not worth the effort to do anything more, like hard-coding all of them, and then having to update the code every time one of them changes.

Putting on my software engineering hat:
Don't reinvent the wheel.  For things like the PDF viewer, don't try to make it, just use what's out there.
Come up with a small, doable list of what you want to do.  Do multiple iterations, do beta/field testing, don't get bogged down trying to make the first version do everything.  Think Spiral and Agile development instead of waterfall.  On those same lines, I'd think of doing multiple apps for multiple things instead of trying to create one unified app.  Early UI prototypes with feedback are a must, even before you start cranking out functional prototypes.  Keep the end user in mind, and get their feedback often.  If it gets the job done faster, do some rapid GUI prototypes in Visual Studios Express, and run them on a PC to show users what they'll look like.

Overlaying the CAP grid on Google Maps would be very useful.  I see a logging app that has the moving map in real time with the grid, and the ability to note things like ELT signal acquired with a note in the log file of time/location, then if able send an SMS or email.  Maybe record a bread trail of time/position every X unit of time (user selectable and/or based on speed if you want to be really slick). 

Read up on how successful open source projects are lead and managed, and talk to the Free Software Foundation to see what advice they can offer.  There's multiple people in CAP who can do software and would want to help.  Don't try to take it all on, and again don't try to take everything on head-on at once.  Small chunks.  If stock Latitude, some other app, or a quick adaptation works in some but not all situations (such as say just for UDF when you have a cell signal), do it, as a proof of concept. 

Also, I'm a notorious Android fan, so of course I'm going to suggest that as the target platform over iOS.  :angel:  However, those phones and tablets come from multiple vendors, are on the big 4 and some of the minor carriers, so you in theory have a wider target audience. 

Documentation is a love letter to your future self.  if you have a good set of documentation and virtual interface prototypes, then you could have multiple independent coders and/or teams porting the design to Android, iOS, and whatever else makes sense, such as WinMo, or possibly webOS if it gets picked up by Samsung as some rumors are starting to talk about, or whatever the next big thing is.

I hope this makes sense and helps.

[Майор Хаткевич]

What about my HP TouchPad?

[davidsinn]

What about my HP TouchPad?

Put Android on it. Someone has hacked Cyanogen on to it already.

[MikeD]

What about my HP TouchPad?

Well, if you install CyanogenMod on it, in a couple of months or so it'll work.  Right now it's a rough beta.  I honestly don't see any kind of CAP app being truly useful faster then that. Unless we have some CAPers who need a Senior Design Project or similar in CS/CoE?   

[davidsinn]

Here's a thought I just had...Make an app for meeting sign in that scans the barcodes on the id cards and generates an output file to be printed and filed or imported into the popular unit management packages out there. Nice and simple and a good place to start the learning process.

[MikeD]

Here's a thought I just had...Make an app for meeting sign in that scans the barcodes on the id cards and generates an output file to be printed and filed or imported into the popular unit management packages out there. Nice and simple and a good place to start the learning process.

We don't have that yet?

[davidsinn]

Here's a thought I just had...Make an app for meeting sign in that scans the barcodes on the id cards and generates an output file to be printed and filed or imported into the popular unit management packages out there. Nice and simple and a good place to start the learning process.

We don't have that yet?

No. I wish we did.

[SarDragon]

At one time, WMU, or one of its variants, was able to accept bar codes to do log-ins. This was back in '02 or '03, right after WMU hit the street. We had it kinda working at a SAREX one time, but I haven't seen anyone try it since then.

[a2capt]

You're thinking of MMU, the precursor to IMU, and I've been doing barcode scanning with both of them anytime I've ever setup or othrwise participated in a mission base environment. I have a plethora of USB and PS2 laser based scanners. Not those "Mr Magoo" blind LED ones, and a lot of times it's the first time anyone saw that and they seem "amazed".

But.. yes, the barcode is just the CAP ID number. Nothing sinister.

[JC004]

There's some good ideas here.  I am also working on another heavily-ES training project (http://training.cap811.org) and trying to integrate things where possible.  I have been trying to teach myself as much as I can with my available time about Android development. 

I should have a decent plan/sketch of this thing soon. 

I hope that people will continue to put CAP ES app-related ideas out there...

[davidsinn]

I hope that people will continue to put CAP ES app-related ideas out there...

A simple app that will generate aircraft search patterns (expanding square, grid, route, etc) and output them into GPX, and KML format for import into other GPS programs (my favorite is Back Country Navigator). Make sure I can specify parameters such as start point, initial heading, track spacing, etc. That way I can have a moving map display with my planned track on it to help me as an observer.

[JC004]

That I would need help with.

[elipod]

I know it might be a long shot to find developers since I had basically no luck with that before and CAP web developer-types that I asked didn't have any smartphone experience.  Mine is very limited.  It would also be good to have someone who could make the app work for iPhone... I can't find ANY iPhone development people in CAP from my asking around.  Not one person with this experience so far.  Maybe if I could at least find someone who CAN develop for iPhone and simply hasn't before?

I may have something useful for you.

While browsing the Apple App store today, I found a CAP app. It is the only Civil Air Patrol App out there. Needless to say, this guy is obvs a developer, and he made an app for ribbons.

It is called "Rack 'Em Up". 

http://itunes.apple.com/us/app/rack-em-up/id307076730?mt=8

You might try contacting this developer.

[N Harmon]

A simple app that will generate aircraft search patterns (expanding square, grid, route, etc) and output them into GPX, and KML format for import into other GPS programs (my favorite is Back Country Navigator). Make sure I can specify parameters such as start point, initial heading, track spacing, etc. That way I can have a moving map display with my planned track on it to help me as an observer.

Check this out: http://nharmon.multics.org/cap/sarplotter.php

The formulas are all in there, should be easy to adapt to output to KML.

[davidsinn]

A simple app that will generate aircraft search patterns (expanding square, grid, route, etc) and output them into GPX, and KML format for import into other GPS programs (my favorite is Back Country Navigator). Make sure I can specify parameters such as start point, initial heading, track spacing, etc. That way I can have a moving map display with my planned track on it to help me as an observer.

Check this out: http://nharmon.multics.org/cap/sarplotter.php

The formulas are all in there, should be easy to adapt to output to KML.

Almost exactly like that except add the ability to define a grid for parallel line search as well. I just want to be able to import those lines into my program of choice and see it below my moving cursor and use my program's tracking ability to compare where I've been to where I wanted to be.

[JC004]

Keep sending or posting ideas (which ever).  I've received some good stuff and it has given me other ideas or helped me developed others.

I should have a bit of a plan together soon.

Still learning what I can and still looking for some people to help make these things reality.  I can't do it myself but there is a TON of potential here.