On Friday, May 27, 2011 3:27:41 AM UTC+1, Jake Colman wrote:
String,
Where did you find the documentation to do this?
I'm not sure now (I've been doing it for quite a while), but I just looked
and there's an example in the API Demos app, under Advanced Preferences. I'm
sure it's documented
Kostya/String,
Is nothing ever easy? So close, yet so far... :-)
Some of my preferences have dependent keys. Since the keys are being
renamed to be widget-specific I, of course, have to rename the dependent
keys accordingly as well.
Pref2 is dependent on Pref1. Pref1 comes through my
Jake,
I just tried it with a simple test, and yes, I get the same exception.
The reason is that setDependency() tries to register the dependency right
away, and doesn't find the depndency because the process of loading
preferences from XML hasn't completed yet (which it does not check).
It
Kostya,
You did not waste my time at all! First of all, this was a great
learning opportunity. Second of all, the suggestion was great - this
should have worked! Maybe I need to do a second pass, somehow, to reset
the dependent keys. But if I need a second pass, maybe I just do it all
at
Actually, the reason we went down this path in the first place was
because if I did not reset the keys during the inflation process the
Preference Screen did not reflect the current values. I can still use a
second pass, however, inside of onCreate() but after inflation to reset
the dependent
True. The initial values are set by onSetInitialValue, which is called
during initialiation (the last phase, onAttachedToHierarchy).
Resetting the values after adding preferences to the activity should work,
although might require some knowledge in the activity about what the default
values are.
On Thursday, May 26, 2011 2:44:37 AM UTC+1, Jake Colman wrote:
The only issue is when I launch the Preference
Activity from the widget it does not display the widget-specific value
but displays the preference's default value.
Are you actively setting the value for each of your widget-specific
S == String sterling.ud...@googlemail.com writes:
S On Thursday, May 26, 2011 2:44:37 AM UTC+1, Jake Colman wrote:
S The only issue is when I launch the Preference
Activity from the widget it does not display the widget-specific value
but displays the preference's default value.
Preference.onSetInitialValue is triggered by addPreferencesFromResource,
which in turn is called from within your activity's onCreate - not before.
However, this happens before your code has a change to call findPreference /
setKey.
One of the methods that gets called while this is taking place
Kostya,
Maybe I'm missing something obvious here but where do I get an
opportunity to provide Android with my extended PreferenceGroup or
PreferenceScreen? I need to make sure that my addPreference method
called during the processing sequence initiated by
addPreferencesFromResource. But how
Jake,
My turn to think I'm missing something.
I imagine you have a subclass of PreferenceActivity, with onCreate
calling addPreferencesFromResource(R.xml.some
xml id here).
In that XML file, you have your preference item definitions.
You can use your own {sub}classes in that XML file, just
Kostya,
Bingo! I didn't realize that you can use your own subclasses in the XML
file! And I also tripped over that convert between integers and strings
issue way back when. Thank goodness for being able to Google and fine
that it was a known problem with a known workaround.
Now I have to
Kostya,
Googling for android preference subclassing didn't quite do it. Can
you point me in the right direction? What is the format of the XML
entry so that it know how to find my subclass? Does the subclass have
any requirements if all it will do is override addPreference? Where can
I find
In your XML settings-definition file, here's what you need. Just use:
com.my.package.PrefSubclass
android:key=pref_key
...
/
where com.my.package is your package name, and PrefSubclass is the class
name of your Preference subclass. Use this instead of:
Where your preference class needs to have the standard constructor, just
like with views:
public class MyPreferenceCategory extends PreferenceCategory {
public MyPreferenceCategory(Context context, AttributeSet attrs) {
super(context, attrs);
}
}
And here is another useful
Thanks Kostya and String, these were great answers.
I can see how I can create my own subclass and use them instead of my
the android classes. My problem now is that it is the Preference
Activity, through an intent extra, that knows the specific widget ID for
which it is being displayed. I
Preferences are inflated with a Context, which in this case is your
PreferenceActivity subclass.
I'd make two classes, WidgetOptionsActivity and
WidgetOptionsPreferenceCategory, with the expectation that the latter is
always used within the former (like maps API and MapActivity).
The widget id
All the magic happens from addPreferencesFromResource which inflates my
preferences XML and instantiates the Preference objects. With
everything we've discussed until now, I know what/how to subclass so
that I can hook into things at the correct level to reset my key. But
if it's
On Thursday, May 26, 2011 10:55:43 PM UTC+1, Jake Colman wrote:
Unless you are suggesting that I can call a method via the context which
is, in essence, my Activity? So cast the context into the Activity and
call the method?
I believe that's *exactly* what he's suggesting.
String
--
You
Yes, a cast is what I'm suggesting. From the design point of view, you'll
end up with two classes that are meant to be used together.
You could even do an instanceof check before the cast, and throw an
exception with a nice descriptive message if the check returns false :)
--
Kostya Vasilyev
String,
Where did you find the documentation to do this?
I would like to add my own XML attributes to my derived preference and
would like to know how do it.
I considered your's and Kostya's suggestions elsewhere in this thread
and decided to implement a derived PreferenceGroup with an
Jake == Jake Colman col...@ppllc.com writes:
Jake I am looking to implemented widget-specific preferences in my
Jake app. I have reviewed numerous blogs and posts, including
Jake Kostya's, and am familiar with the overall approach of using
Jake the widget ID as a suffix to the
Jake,
With each widget having its own settings, you are pretty much forced to
update them individually.
I would have the alarm receiver obtain all widget Ids and send them
using startService all at once. The service would then do the filtering
for stale Ids, combined with loading actual
KV == Kostya Vasilyev kmans...@gmail.com writes:
KV 3 - Each RemoteViews update needs to be self-sufficient, that is,
KV contain all the data items (setTextViewText, etc.) as well as
KV PendingIntent's.
KV Do not push separate, incremental, RemoteViews: one for text
KV views,
04.05.2011 16:41, Jake Colman ?:
So it*is* correct always set up the onClickPendingIntent every time I
build and push update. I thought maybe I had missed something and was
making a colossal error.
Not pushing a complete update can lead to errors later on.
I guess I will recode my
Kostya,
I've been noodling around thinking about this problem while working on
other features but I'm stumped on one part of it. When the Preference
Activity is launched as a Configuration Activity the intent contains
widget ID. But I can also launch the same Activity if the user touches
the
Jake,
You have the widget id where you're building your RemoteViews and
setting the PendingIntent for the click.
So the only thing is how to get the widget id into the PendingIntent, so
you can retrieve it later in the config activity.
Probably the easiest way is to use the same extra,
Kostya,
Gee, I hope I'm not revealing my ignorance here...
I build my RemoteViews in an IntentService. I suppose I have to find a
way to pass the widgetid into the Intent that is used to start the
service. If the service knows the widgetid, it can putExtra that
widgetid into the Intent used
Jake,
You can get a list of widget ids by doing something like:
AppWidgetManager appWidgetManager =
AppWidgetManager.getInstance(context);
ComponentName provider = new ComponentName(context, Widget.class);
int[] widgets = appWidgetManager.getAppWidgetIds(provider);
Kostya,
Hmm.
Whenever the alarm in AppWidgetProvider is triggered, I have to update
all widget instances as per the widget-specific preference. Based on
what you have suggested, does the following make sense:
1) In the AppWidgetProvider's onReceive() method when it receives the
intent
Kostya,
I like your second suggestion.
So in my Preference Activity's onCreate() I should get every preference by
original key name and then reset the key name to include the widget.
That means I'll have a full set of non-unique preference keys without
any data but that should not really be an
24.04.2011 19:35, Jake Colman пишет:
Kostya,
I like your second suggestion.
So in my Preference Activity's onCreate() I should get every preference by
original key name and then reset the key name to include the widget.
Basically, yes.
That means I'll have a full set of non-unique
KV == Kostya Vasilyev kmans...@gmail.com writes:
KV 24.04.2011 19:35, Jake Colman пишет:
If I use an onClickListener() and on
SharedPreferenceChangeListener() to detect specific preference
clicks or changes to a preference, I can parse out the widget ID
from the key so that I
Well, in that case you already know the widget id for a particular instance
of your configuration activity - it's passed in as an intent extra.
25.04.2011 1:21 пользователь Jake Colman col...@ppllc.com написал:
KV == Kostya Vasilyev kmans...@gmail.com writes:
KV 24.04.2011 19:35, Jake Colman
34 matches
Mail list logo
