Description of the issue and brute force fix from #18.

"I also fixed a crash I encountered multiple times, when returning to the LocationActivity from a permissions request. When onBackPressed() was called, I was getting an IllegalStateException because onSaveInstanceState() had already been called. It's kind of awkward, since we're not doing FragmentTransaction, which is the normal reason this crash happens. Instead, AppCompatActivity inherits from FragmentActivity, which accesses the fragment manager in onBackPressed(), in case there's a fragment showing. So, the normal fixes don't work. I looked for an elegant solution for a while and couldn't find one, so I brute forced the solution by getting rid of the optimization to call onBackPressed(). I think this is fine because, with the current UX, we wouldn't expect people to be going back and forth between the MainActivity and LocationActivity frequently."

On Android N.

Steps to reproduce:

1. Open the app and enter a zip code.
2. Hit the 'Edit' button next to the entered zip code. (Currently selected zip code is pre-populated in the text field)
3. Hit the android system back button
4. Hit the android running apps button and select 5calls
5. Hit the 'Edit' button next to the entered zip code. Text field is not pre-populated any more.

Otherwise it could get out of hand.

Like the website, add buttons to "tweet" and "share" issues. Or maybe make it a "sharing" menu? TBD.

Most mobile apps support scrolling with "inertia" so that the page keeps scrolling if you flick it up or down. This doesn't work on the 5calls app.

If you like this app please leave us a review!

And maybe also an email for feedback.

see web:
const reason = c.reason == "" ? "This organization is driving legislation related to the issue." : c.reason;

After a user completes a call they get a congratulatory snackbar, which is promptly lost if they have no more reps left. We should send this info back to MainActivity to re-create the snackbar so the user still knows their call was recorded, etc.

Right now, when a user chooses to use their current location to get a list of calls the zip code field does not update with the new location chosen.

For flexibility for users who live in a split district so can't use zip, but aren't in the right GPS location when they download the app.

Low-priority but nice to have.

Right now for long scripts or small screens it's not clear that a new contact has loaded.

Since we don't go back to main, it'd be good to show a check mark that the contact was contacted.

java.lang.IllegalStateException: Fragment ThirdTutorialPageFragment{489deda} not attached to Activity
at android.support.v4.app.Fragment.getResources(Fragment.java:646)
at org.a5calls.android.a5calls.controller.TutorialActivity$ThirdTutorialPageFragment$1.onCallCount(TutorialActivity.java:210)
at org.a5calls.android.a5calls.model.FiveCallsApi$3.onResponse(FiveCallsApi.java:124)
at org.a5calls.android.a5calls.model.FiveCallsApi$3.onResponse(FiveCallsApi.java:118)

The issue card could expand to fill the IssueActivity, or
The MainActivity screen could scroll to the left, like a swipe, to reach the IssueActivity

Definitely a future enhancement, but it'd be cool if we could launch the app from the browser, using Intents with Chrome. The UX would be pretty simple - the user opens a 5calls issue link in the website and gets some sort of toast/landing page to ask if they want to open it in the app (or something like that). Would obviously require coordinated frontend work to roll out, and some better UI/UX consideration. But I doubt this is high priority right now, so just leaving here for now.

We should escape that character on the DB side.

123456 should be 123,456

Links to 5 calls' twitter, facebook and instagram also would be cool.

Also track the office that was called in the local database so that later we can prompt the user to use a different number.

In contacts, local offices json is like:

"field_offices": [
{
"phone": "559-485-7430",
"city": "Fresno"
},
{
"phone": "310-914-7300",
"city": "Los Angeles"
},
{
"phone": "619-231-9712",
"city": "San Diego"
},
{
"phone": "415-393-0707",
"city": "San Francisco"
}
]

The issues list may not have all the issues ever created, so we should store those locally so that the user can always see what issues they've called about. Same with reps.

Some sort of green check next to numbers you've already contacted, or other visual indicator on the issues page.

@dektar

I'm trying to run the project, but I'm getting the error "File google-services.json is missing. The Google Services Plugin cannot function without it."

Should that file be in source control, or can I use one that I generate here?

Along with a turn off and snooze option.

After sharing is implemented on the "your impact" page, go even further with badges / milestones so users can hit goals and share their impact in a more exciting way.

If the device is offline, e.g. in airplane mode, and a user attempts to change the zip code, a notification fires that the device is not online and the list of issues is not updated (as there is no connection).

However, the header that shows which zip code is currently selected does update and thus does not match the displayed list of issues.

This will make error handling nicer for the user.

A webview might be nice here, to deal with all the links and formatting.

Get more of the content from https://5calls.org/about

Bug!

Maybe even graphs of cumulative calls over time.
Certainly stats on how many issues you've called for, how many representatives, and how many times for each representative.

Background color in newer APIs, plus button and text formatting styles, for cleaner XML

Could be linked from the about page. Should do whatever the form does on the site, if possible. A webview to that form is OK.

With some UX support perhaps, create a more standard & friendly TutorialActivity with fewer words and more colors and pictures, and maybe a few screens.

Probably a BroadcastReceiver that listens for time changes and resets the notifications

More here: http://stackoverflow.com/questions/39527582/alarmmanager-alarm-start-when-system-time-is-changed-by-user

IssueActivity in particular would look bad on a tablet - the buttons would get super wide.

Probably have big margins for all activities on tablets, with more centered content, for starters.

java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String org.json.JSONArray.toString()' on a null object reference
at org.a5calls.android.a5calls.model.FiveCallsApi$1.onResponse(FiveCallsApi.java:94)
at org.a5calls.android.a5calls.model.FiveCallsApi$1.onResponse(FiveCallsApi.java:82)

Unclear if this is working as intended:

1. enter a zip code and get to the list of calls
2. turn on airplane mode
3. go into an issue and give the result of the call (e.g. 'unavailable')
4. a notification fires that the device is offline, but the call is logged locally and a green checkmark shows on the issue.

unclear if that call gets eventually logged to the server or not.

https://developer.android.com/reference/android/location/Geocoder.html

avoids things sent to the civic API which it recognizes as valid, like
https://5calls.org/issues/?address=%0A
https://5calls.org/issues/?address=f
https://5calls.org/issues/?address=7

Basically, how do we want to encourage or force people to upgrade the app? Android users are generally bad about upgrading, and if we ever deprecate part of the API, or make other breaking changes, we may want a way to make sure no one is using the affected old versions.

There are generally two ways to go about this:

1. Soft upgrade (dismissable)

• Something like an in app modal or push notification that's dismissable, alerting the user that there's a new version, and/or that their current version is now broken.
• Pros: Not as intrusive.
• Cons: Not 100% effective.

2. Force upgrade

• Lock the user out of the app with a link to the Play store to upgrade.
• Pros: It guarantees that we get users off the affected old versions.
• Cons: It's obviously intrusive to the user.

In my opinion, if we include a force upgrade code path, it should be for emergencies only. Emergencies can include hotfixes (if we release a version that is unusable for some reason). I would generally shy away from using the force upgrade to move users off of old versions, unless those versions are REALLY old, and they are becoming a significant maintenance burden.