Preferences should be cleaned up about avare HOT 11 CLOSED

I am looking at trying to fix this up for you, but after cloning the code, I must admit, I'm at a loss as to how this thing works.

First, I see that there's a central service class that says it "stores all states so when activity dies, we dont start from no state." I don't really understand what this is used for. Android has plenty of ways to quickly store and retrieve states.

Does this class handle states that should continue processing in the background, like GPS/weather receiver logging and/or downloads? It looks like it does a lot more than that.

Even without understanding how the service works, I figured I should be able to start work on the PrefsActivity, but then I saw that it does some stuff with the service that I don't understand. Are you also using the service to store the settings? If so, why, and is this required for a particular reason in your app?

Next, I can't figure out where the code is that launches the file browser for the chart storage location. I want to ensure that I don't mess that up, or maybe can find a better way to represent it to the user.

Finally, I don't understand why the preferences activity needs access to the GPS interface. In best practice, the preferences activity shouldn't do any processing other than setting/retrieving preferences. In some cases it can also notify the app that preferences have changed and should be re-read elsewhere.

If you want to explain all of this, I will look into starting a rework on the preferences activity for you as I get time. I figure this is low in your priorities list, so speed isn't necessary.

from avare.

Storage Service has several uses.

• It stores state in run time memory, which is faster than storing in disk
• It keeps the GPS alive even when the app is is background - for 2 minutes
• It stores bitmaps which should not be unneccasrily recycled
• It stores weather caches that need immediate access

Pref activity is just that. Preferences acvtivity.

• It connects to the service to keep the GPS alive
• Any activity that wants to keep the GPS alive needs to tell the service about it

Handling GPS is tricky, and there are many states that deal with application life cycle without users noticing anything being wrong with the GPS, and / or ADS-B/external units.

If you can devote some time to the app, I suggest finding ways to make LocationView class more manageable, or as recently discussed, writing a static function that, given a space separated line of waypoints, determines if each space separated entry is either an airport, a fix, or a navaid (across US and Canada). Of course all other suggestions are welcome too.

What's your plan about Preferences Activity?

from avare.

I was going to rebuild PrefsActivity to use a headers file. This would require each section to be broken into its own xml file, and then the PrefsActivity to load the headers file. On 3.0+ this works fantastic and automatic, but on older devices you additionally need a little bit of manual handling to get the same effect.

It's not difficult and uses all the same files, except instead of the headers file, you use an additional preferences file that pretends to be one. Instead of

The problem with doing this, however, is the way your preferences are currently deeply tied into the gps, Prefs object, and storage service. If I were to proceed with this plan, it would take quite a bit of work, but bring the Preferences activity into compliance with best practices, and letting it stand alone and handle all the preferences work.

The following would need done:

Rework the Service slightly:

Work

Turn the service into a started service (instead of just a bound service) if it's not already, allowing it full life-time control of the gps. This would hopefully prevent the need to call the gps APIs on any activity other than the service itself. Then the service can just report the position to any activities that bind to it.

Problems to solve

Ensure the service knows how and when to quit itself, because a started service will run forever if you let it. We'll have to shut it down manually in the application exit code. Any time the app itself is not visible in the foreground, we should provide a notification that the service is running in the notification bar.

Listen for preference changed events

Work

Instead of handling changes that affect the running app from inside PrefsActivity, I'd need to create a listener in another class (MainAcivity probably) that would subscribe to the android-supplied events indicating when preferences have been changed. Then the listener would handle making any changes to the state of the app if, and only if, the preference modified needs to update the state. Android supports this already from API1, eliminating any issues with backwards compatibility.

Problems to solve

Reworking how the Prefs object handles inputting new values. Currently it takes a reference to the existing PrefsActivity in its constructor, pulls some values directly, and writes them to static variables within the prefs object. I'd need to change this to allow the listener to be able to set the needed values directly on the object and remove the code from the constructor. This shouldn't be hard at all since they're already public static. Additionally this would remove the need to instantiate a new version of Prefs every time we save preferences.

Implement the new settings menus

I've been learning about settings menus recently anyhow, and I know how to do this already.

from avare.

The hardest part of doing this entire thing would be refactoring the service. I know how central it is to the app, and I wouldn't want to break its functionality for anything else it does. Luckily, a started service can also be bound, so I honestly think the only difference would be how its initially started, and the fact that we'd have to shut it down manually, and show an icon.

These three things should all just be simple additions to the service.

from avare.

Another question. Why do all the strings have " around them? The quotes don't appear anywhere in the app.

from avare.

Sent you a pull request with this issue hopefully resolved.

from avare.

OK will check it out after I am done with plan string. I have found an
acceptable solution to plan string automatically recognized.

On Mon, Jan 20, 2014 at 4:45 PM, damccull [email protected] wrote:

Sent you a pull request with this issue hopefully resolved.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-32800079
.

Zubair Khan
apps4av.com
zk4u.blogspot.com
Sudbury, MA 01776

from avare.

Oh, sweet. That sounds fun. Let me know where it goes in the code cause now I'm curious as to how you're doing it.

from avare.

I checked the database
Anything 1, 2, 3 letters is a Navaid

Anything 4 letters is an airport, if not then its a navaid (only 1 entry),
if not then its a fix (only 1 entry). Canadian airports are all 4 letters.

Anything 5 letters is either an airport if strating with K, otherwise a fix

Anything 6 letters is a fix

Anything which has an & is a GPS coordiate like 42&-70.

Anything more than 6 is a raidal like BOS010101

On Mon, Jan 20, 2014 at 5:13 PM, damccull [email protected] wrote:

Oh, sweet. That sounds fun. Let me know where it goes in the code cause
now I'm curious as to how you're doing it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-32802138
.

Zubair Khan
apps4av.com
zk4u.blogspot.com
Sudbury, MA 01776

from avare.

Weird. I thought airports were 4 letters. Maybe there's formatting I'm not aware of. Cool!

from avare.

There are corner cases in databases. I checked in. You can try.
On Jan 20, 2014 9:53 PM, "damccull" [email protected] wrote:

Weird. I thought airports were 4 letters. Maybe there's formatting I'm not
aware of. Cool!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/25#issuecomment-32817143
.

from avare.