Move general preferences into a view

[andlyticsproject]

Move general preferences into a view

[willlunniss]

It is deprecated but it still works and the alternative is not great due to the lack of a PrefenceFragment in the support lib. For now I would vote to stick to reading preferences from XML using an Activity rather than Fragments simply because ActionBarSherlock does not yet have a SherklockPreferenceFragment (but does have a SherklockPreferenceActivity) so it will be a pain when the time comes to use ActionBarSherklock.

Having said that, there are some work arounds including what you linked to and something mentioned in JakeWharton/ActionBarSherlock#43 such as http://forum.xda-developers.com/showpost.php?p=19719977&postcount=1 although I've never tried any of them

[AndyScherzinger]

I agree! Question is if it is a good idea to implement it the legacy way since we might get into trouble migrating it when we integrate ABS and their solution in case they will provide one... on the other hand we are talking about general preferences. Worst case scenario is the user needs to reconfigure the app. Which would be bad but from the dev's point of view the actual implementation is hard to maintain....

[willlunniss]

The user would never need to re-configure the app as long as we used the same key to store the data.

If we use a PreferenceActivity now then to move to ABS, we literaly change it to a SherklockPreferenceAcitivty and its done, so it will be very easy. As for the actual implementation it will be very minimal, the xml file will contain all the magic, the java itself will be onCreate to load the xml (one line), and at most a few listeners, but they should be able to be in the code that needs them (update service/code to show available apps). There may also be a DialogFragment for selecting which apps to shown/hide, but that is very portable.

[easye1161]

Wouldn't the easiest solution just be to make a regular Activity that uses a SharedPreference to store settings? That's what PreferenceActivity/PreferenceFragments to internally anyway. I've never used PreferenceActivity/Fragments in any of my apps (let's be honest...they're pretty ugly) and have had no problems at all. This would have the added benefit of keeping the UI as cohesive as possible.

[AndyScherzinger]

That's true. Just mentioned the point since I have no idea how ABS will implement it in case they do.
So how would you imeplement it then? I kind of like the style of the preference activity or the ABS version of it respectively.

My question would be then how to implement it with XML and not using the PreferenceActivity.

[fda77]

I'm not sure if its a dumb question, but
" ...deprecated with the newest Android version"
means it will not running on older devices like my Android 2.3.6?

[willlunniss]

No it means it works fine all the way back to 1.X i think. Just that from 3.0 + you are supposed to use fragments for managing your preferences. And in the future, maybe 6.0 or greater, it will eventually be removed. While it definately makes sense to use fragments if you have a lot of options, andlytics doesn't have a lot and we don't need to do anything complex such as use loaders or anything else when preferences are changed so there is no benifit for moving forward just yet and we might as well wait for google to release a backwards compatiable class.

@easye1161 I quite like the look of the settings, and users are certainly familiure with it and I though the goal of this UI shakeup was to standardise this app a bit + make it easy to maintain. So my vote will be for using xml rather than doing it ourself.

[AndyScherzinger]

Also my point of view. Not sure if we should wait though... I takes a lot of space and isn't the way we want it to be implemented/looking anyways, so since this will be the first or second release we might as well change it to XML. Don't you think?

[willlunniss]

The only slight pain thinking about it is there is no multiselect list preference so will need to use a dialog fragment or something for that to also enable having the app icons. Otherwise the simple version is something like http://blog.350nice.com/wp/archives/240
Other than that I would go for it.

[willlunniss]

Just looked through a few gaps (play, reader, maps, gmail) and they are all using what looks like PreferenceActivity/Fragments, haven't checked the source code though.

[AndyScherzinger]

A comment seems to be gone...

Anyways... it'll look like this (for non ICS devices)
http://3.bp.blogspot.com/-7o_tn0B8Scs/TfFKStmBjPI/AAAAAAAACHg/HzdIHrjUCo8/s1600/android-elements-preferences-screen-light.png

and will then after implementing ABS look like this:
http://cloud.addictivetips.com/wp-content/uploads/2012/05/MIUI-4-Launher-Port-Android-Settings2.jpg

Which looks fine to me. Anything else is bad from my point of view since the implementing it this way enables consistent design throughout a device in case it has a non default Android theming (quite common).

[willlunniss]

Just an FYI i've got some WIP stuff on this. Turned out to be harder than expected because there are seperate preferences per account (the keys have the account appended to them), so it pretty much all has to be built dynamically.

There are also some potential isseus with blocking access to the db, I'll need someone to help review the code once it is done.

[willlunniss]

Ok, i've done this and it is ready, except I cannot work out how to open a second pull request while my previous one is open.

[willlunniss]

Ahh crap, its merged it all into the same pull request #101 don't know why it did that :(

[nelenkov]

It might be a good idea to start a new branch for each feature you are working on and never work on master to prevent this from happening. You can delete your branches once they are merged.

[willlunniss]

Yeah I realised that after reading some guides :-( . Still getting used to the git way of doing things.

Sent via Hubroid

[AndyScherzinger]

So anyone any idea how to split this up now? :(

[nelenkov]

Add a remote branch and only merge the relevant commit(s) using cherry-pick. Here's a helpful article:

http://beust.com/weblog/2010/09/15/a-quick-guide-to-pull-requests/

[willlunniss]

@nelenkov Thanks for the guide.

@AndyScherzinger It might not be worth bothering to split them up this time around as only one of the commits isn't related to this issue and it is very simple (willlunniss@987d71c) so it shouldn't effect testing/reviewing the rest of them.

[AndyScherzinger]

@willlunniss so we could merge the pull request and the name=subtitle should be fine too. Probably just add an "else" condition for appName == null and have a fallback to the packagename

Off topic: Do you want to be added to the organizations members so you can merge pull requests yourself?

[willlunniss]

@AndyScherzinger yes just merge the whole thing and I will use dedicated branches going forward. Good point (although it should never be null, and that check is actually a bit pointless thinking about it as calleding setSubtitle(null); will simply hide the subtitle). I'll leave it for now though until it is all merged to avoid future problems.

Can do, although I'm going to be very busy now until the end of July so probably won't be able to contribute much more until august. I just felt that getting preferences done was blocking other improvements that might require the new preference system. Its very much a rough first go that needs improving and cleaning up, e.g. I failed at naming my variables to match the rest of the code and went into auto pilot mode - we should set up a basic coding guidline. We also need to think about which preferences should be account dependant and which shouldn't going forward as that effects how they are built up as you have to use fixed keys if you do it in xml.

[AndyScherzinger]

@willlunniss just added you to the member list.

Account settings vs. app wide settings really needs to be discussed. I checked and Andlytics treated every thing on an account level. I am not sure if people really want to have different notification setting per account. At least I don't don't :)

I guess most people never realized this since most of them have one account only. In my personal opinion the only thing that should be account specific is the "apps to hide" setting. Everything else looks app wide to me.

Any comments anyone?

[willlunniss]

@AndyScherzinger thanks.

As long as there is maybe an option to dissable an account/dissable syncing an account, then yes everything sould be fine being app wide. It would also make things a lot easier to implement as a lot of the extra code code be ripped and it can almost all be done via xml which is what I was planning for.

Apps to hide/apps to sync can be displayed in per account groups.

It kind of depends on how we plan on working with multiple accounts, so yes lots to think about first.

[AndyScherzinger]

In the end the big question is: Where do you need/want the flexibility to configure things on an account basis?

So I am looking forward to people's feedback on this! :)

[willlunniss]

My use case is I have two accounts, my personal one with apps, and my work one which doesn't have any apps/developer account so I don't want it to check my work one when it won't find anything. Other than that, it should all be the same.

Re the pull request, anyone have any objections to me merging it so that people can try it out? I'll then clean it up later on this week based on any feedback.

[AndyScherzinger]

Sounds fine to me.

One question: why would you add your work account if it doesn't have a console?

[willlunniss]

I haven't, the app picked it up on it's own as it is a Google account.

Sent via Hubroid

[willlunniss]

If its OK, i'll close this issue as it is sorted apart from the code needing a clean up, and use this new one #103 for talking about what to do about per account prefrences as it will impact/is impacted by how multiple accounts are handled in general.