Preferences are on a per account basis about andlytics HOT 11 CLOSED

Just gave the actual master a spin... and must say I love it! It is done really nice!

from andlytics.

Thats good, I like it too. Should look even better once we decide on how to do the global preferences and which additional ones we need to introduce as it would then make sense to use preferences categories on the main screen to visually break it up.

from andlytics.

So I've just looked at this and the changes would take <15-20 min so that is all fine except for the following problem:

The app lists all the google accounts, which it fetches when needed (on start up). Then as each account is accessed it asks for an auth token, if it hasn't asked for (and got one) before, you get prompted to allow the app access. I don't think there is a way to hide that prompt (i.e. test if we have access and it would add an unneeded delay) so that I only display preference categories for the accounts that are allowed. Therefore a change will probably be needed.

On first run, ask the user to add/associate an account and list all available google accounts + and option to add a new google account to the device. When the user adds an account, we store that account name in the preferences and we only display the accounts that have been associated in the main login screen/future account switcher. If the user wants a second account, they press add, see a list of google accounts (currently associated accounts are greyed out with a tick saying already added or similar) plus the option to add a new google account to the device. From then on, when the app starts up, load the list of associated accounts (we can also store default/last used for seamless resume). Then in the preference screen, when the user for example configures change notifications, we can dynamically build up prefrence categories for each associated account, rather than each google account on the device which we may/may not have access to and may not have any apps in the first place.

Estimated effort, a good few hours for propper testing. Could even do it all in one go and replace the login screen at the same time and go straight for gmail like account switching.

Any thoughts?

from andlytics.

Sounds fine with me :)
Like your idea on how to add accounts and showing all "active" accounts greyed out, so you see which one you already added! Question is should this change be made before or after the next release?

Any opinions on that?

from andlytics.

I probably won't be able to do it until the end of the month as I am very busy right now. We easily have enough for 2.1 atm, and improved multi account management could easily be the feature in 2.2, so I think it should be delayed so that you can do a release. Will be good to show that we are making process for those not checking gitbub.

Also when you do make sure you create a tag each time.

from andlytics.

Same here. I also won't find much time to spend on the project before the end of the month.

Tag has been created: https://github.com/AndlyticsProject/andlytics/tags

from andlytics.

This is one of the next things I want to deal with when I have some free time later next week. Before hand I would like peoples thoughts on it.

First part is how do we display it. For example, in gmail, you have:

General settings
account1 specific
account2 specific
....

Or we could have account specific lists as we go.

Second part is which settings should be global, and which should be account specific, i'm not really sure on this after playing around with it all.

from andlytics.

I guess the way gmail handles it would be fine just because we (probably) have general and account specific settings and I wouldn't like to have two menu items for this. Another reason would be do have the same structuring as the gmail app, which isn't a great reason but it brings consistency with a google app.

As for general vs. account specific.... This really is a tuff one. I am a fan of general setting so I have to configure less since I would configure all accounts the same way but other people might want to have the flexibility to configure it deffenrently per account.

The best way imho would be to have general preferences and being able to override them in each account if a person wants to. Never found a way to do this because you would need things like true/false/not configured to be able to determine if a user has set the setting's option...

On the other hand you could have an app specific option "override general preferences" but would then have to "reconfigure" all general settings that can be account specific (technically that would be possible). This would be the most comfortable and flexible solution that comes to my mind but also the most complex/time-consuming.

Any thought's?

from andlytics.

So which ones would you have seperate?

Considering the number of them, I don't think it is worth giving the choice to override them, its not worth the effort at our end for the implementation and at their end for working out which setting is being used. We either leave it how it is, with everything account dependant (which is not quite right), or we make settings that we feel are general general, and settings that are account specific, account specific.

from andlytics.

I would put notification trigger/signal and auto sync setting into general preferences and just leave the "apps to hide" in account specific.

This I a personal preference of mine and I also think that most people won't have more than two accounts and I don't think people would configure different sync times or notifications. Putting this stuff into general preferences would lead to a consistent behavior for all accounts :)

from andlytics.

That was a giant pain in the ****, but I think it is done now. https://github.com/willlunniss/andlytics/tree/global-and-account-specific-preferences

Note, this is a breaking change (for upgrading, hopefully I haven't actually broken anything :)), users will have to re-setup all global prefrences if they changed them. Is this acceptable with everyone?

Ideally can some one give this a test before I merge it.

from andlytics.