OI Shopping List vs Android Design Guidelines

[aap]

Since recently updating my phone to JellyBean, I have become more aware of some oddities of OI Shopping List's UI. OI Shopping List was relatively consistent on GB but on JB it tries to use the action bar a little bit, with less than thoroughly satisfying results. The underutilized action bar takes up extra space, which wouldn't be so bad if some of the other stuff would move in there. Time will tell whether I actually get annoyed enough to do something about it, but meanwhile I'm at least thinking.

Friedger recently pointed out this video about how Android design guidelines can be applied to shopping list apps. There are lots of interesting ideas in there that could be applied to OI Shopping List. Of course some might make more sense than others.

As usual we have to consider how to make changes in such a way that they can still be supported on the older Android releases that we support. So I've been wondering: is there some reason we don't want to use ActionBarSherlock? It seems to be a popular way to use near-native ActionBar APIs with similar results down to version 4, with a flavor not too different from the platform support library we are already using for fragments.

If we are willing to try that, perhaps we should also consider HoloEverywhere for other backward-compatible widgets and behaviors. Looks like it would allow us to consider most of the design patterns mentioned in the video without needing to keep separate behavior coded for Froyo.

Thoughts?

-- Aaron

[pjv]

Hey Aaron,

I've recently been converting my app to better post-Honeycomb support
and I couldn't stop thinking that ActionBarSherlock really sucks in my
investigation of it. That said, I only did a short investigation. I was
lucky I did. I went with an own solution based on ActionBarCompat and
iosched2011 that was super easy. Probably saved a lot of time. If I had
better claims against ABS, I'd voice them more publicly. It's on my todo
list. I'd name it ActionBarWatson :).

ActionBarSherlock + HoloEverywhere obviously deliver the same Holo UI
also on older platforms. This is a big nono. Look at Dianne Hackborn's
and Adam Powell's comments.

I've also seen some issues with ABS, like the hassle with the library
project and the issue Johan Pelgrim ran into recently. I'm not sure if
things like ShareActionProviders work correctly with it yet. In my
solution, I was even able to create a custom (Share)ActionProvider for a
frequent action I was using intents and a chooser activity for.

Finally, my way of doing things are way way better if you are a heavy
user of intents (you're not using a menu xml for instance). You would
also not be locked in to the ABS Activity inheritance hierarchy.

ABS is a lazy cheap way for new apps where time-to-market matters. I'm
not convinced it works at all for conversions.

Best regards,

aap schreef op di 22-01-2013 om 19:22 [-0800]:

> --
> You received this message because you are subscribed to the Google
> Groups "OpenIntents" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/openintents/-/moMNytx9tQQJ.
> To post to this group, send email to openi...@googlegroups.com.
> To unsubscribe from this group, send email to openintents
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/openintents?hl=en.

--
Pieter-Jan Vandormael

[aap]

Hi pjv,

Thanks for commenting.

It's surprising to hear you say that ABS is hard to use. People seem to really like it. This stackoverflow response suggests that ActionBarCompat lacks setNavigationMode()... and I think we want that. I'd love to see the list selector move into the action bar.

Regarding having the same UI on older platforms, I'm not sure why it's "a big nono." The people in the video mentioned ABS in passing, in such a way that did not give the impression that it would be a bad idea. Also, another response on the same stackoverflow question linked above suggests that ActionBarCompat also supports older platforms.

Among the apps I use, several were probably using HoloEverywhere and/or ABS, because they already used the new style when I was still running GB. I actually liked the fact that some apps-- generally, the better looking ones-- didn't change at all when I upgraded to JB.

Can you elaborate on the intent issues?

-- Aaron

[pjv]

Hi Aaron,

1) ActionBarCompat isn't really a thing/library/framework. It's a thing
you have to build yourself. Don't be fooled by the Koolaid. So does the
SO answer also seem to say that a Contextual Action Bar is lacking?
That's not true. I have it working very well. I didn't need tabs just
yet though but I see no reason why it wouldn't work.

Just to be clear: ActionBarCompat means you'll take an example from
iosched2011 but you'll build an abstraction yourself that either does
the old action bar you had on pre-Honeycomb, or does the native action
bar on post-Honeycomb. Take into account that you already have the
pre-Honeycomb solution sorted out.

2) The end goal for Android is to offer the same user experience between
apps on a single phone (with one version of Android). If your app uses
Holo it breaks with the other Gingerbread apps on a HTC Desire. Only
developers see a difference between phones (and versions) because they
use multiple. That's a secondary use case that gives way to the first
one.

3) I'm talking about implicit intents here and the loose coupling you
get with them. I didn't say I thought there were issues with ABS and
intents, did I? Only that ABS samples are focused on explicit intents
and defining menus in xml. The question is, do you have a framework that
deals with code-based options/context/CAB menu actions and is easily
portable to ABS? I've found a way to allow CATEGORY_ALTERNATIVE actions
and combine them with the few actions you really need to specify
prominently on the action bar. I've created a UIActionManager for it and
it turns out it works swell, much better than I expected, with both old
action bars and the new native action bar along with CABs etc. It's
being used in https://code.launchpad.net/~pjv/collectionista/ics-main
but the whole app migration is unfinished.

Here are some of the links I mentioned before:
https://plus.google.com/u/0/114227856179062761851/posts/ei71PSkxyBK
https://plus.google.com/111197851104743856547/posts/7EaKHwU6LoG
https://plus.google.com/112617873637231221858/posts/dek4wsbG65G

Best regards,


aap schreef op wo 23-01-2013 om 20:09 [-0800]:

> https://groups.google.com/d/msg/openintents/-/y6I9wM4kHr8J.

[George Venios]

Hello pjv and Aaron,

I thought I'd chime in as I've followed both approaches in production projects. 

While I generally agree that native platform experiences are the best as they provide (or should provide) consistency within the same environment, I believe there is a place for ActionbarSherlock today. Can't say the sam for HoloEverywhere though.

More specifically:

I'm against HoloEverywhere in every circumstance I've thought of. The way I see it it's just theming your app in a style that's irrelevant in that platform. However more refined the widgets might look, it's too much of a difference -- some widgets don't even look the same (spinners for example). I see no reason in going through the trouble of using it, restricting ourselves, only to provide something that wasn't meant to be provided in the first place. All in all, Holo feels out of place in older platforms.

ActionbarSherlock is useful. It provides easy access to navigation, interaction and theming facilities that would otherwise be out of reach, or even worse take too much time to develop to be viable. Until recently, I was taking a similar approach to pjv in my app (Little Diary), essentially using a custom implementation of the Actionbar in older platforms and the native one in newer ones. Seeing all the buzz around ABS I decided to try it out and I can sincerely say there's no turning back. It sure has its share of problems and quirks, but 1) it's open source and you can tailor it to your needs, adding any features you might require on top of a mostly stable base and 2) it reinvents the wheel for you, and it's pretty good at it. Features that would take days to implement by hand are ready to use and be extended. 

Generally, I'm considering ABS a good solution today (especially for new projects) as it helps cut development and design time, while the percentage of Actionbar enabled devices is increasing in a fair pace and is meant to continue doing so. I don't know if I'd recommend against using it anymore.

Best regards, 

George.

To unsubscribe from this group, send email to openintents...@googlegroups.com.
Visit this group at http://groups.google.com/group/openintents?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.

[pjv]

Hi George,

Hey, someone who also doesn't like holo everywhere!

Does ABS do GoogleTV? I've just today learned that the LeftNavBarLibrary
doesn't do (native) action items, so I'll have to roll my own .. yes ..
again.

Just saying that if the same is true for ABS, maybe it isn't that
complete after all, and it might be less confusing and flexible to use
our own compatibility layer.

Best regards,

George Venios schreef op do 07-02-2013 om 20:37 [+0200]:

> +unsub...@googlegroups.com.

> Visit this group at
> http://groups.google.com/group/openintents?hl=en.
>
> For more options, visit
> https://groups.google.com/groups/opt_out.
>
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "OpenIntents" group.

> To unsubscribe from this group and stop receiving emails from it, send
> an email to openintents...@googlegroups.com.

> To post to this group, send email to openi...@googlegroups.com.

> Visit this group at http://groups.google.com/group/openintents?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Pieter-Jan Vandormael

[George Venios]

Hi pjv,

AFAIK, ABS doesn't do GoogleTV, which is a shame, but given the lack of support it has from even Google itself it's to be expected.
Regarding its completeness, I was referring to it vs a new hand written solution. If another solution is already in place in a given project, I as well am against using it (well, at least most of the time).
That being said, I don't think it's going to be hard to use a custom LeftNavBar implementation with ABS, though this is just an assumption based on my previous ABS (minor) customization experience.

Best regards,
George.

[aap]

All,

Not sure what took so long, and/or why they decided to do it now... but in r18 of the support library Google has added support for ActionBar down to v7. So it seems if we would be willing to move our minSdkVersion to 7 (eclair) instead of the current 4 (donut), this discussion becomes moot.

-- Aaron

[Friedger Müffke]

I'm all for it :-)

2013/8/7 aap <aa...@peromsik.net>

To unsubscribe from this group and stop receiving emails from it, send an email to openintents...@googlegroups.com.

To post to this group, send email to openi...@googlegroups.com.

Visit this group at http://groups.google.com/group/openintents.

[aap]

I pushed a branch "ui_update" in which I tried, as a first step, to move to the v4/v7 libraries. It doesn't quite compile due to a resource conflict -- apparently appcompat defines an attribute named "divider" which is not an integer.

Description Resource Path Location Type

error: Error: Integer types not allowed (at 'divider' with value '0'). themes.xml /OI Shopping List/res/values line 24 Android AAPT Problem

error: Attribute "divider" has already been defined attr.xml /OI Shopping List/res/values line 38 Android AAPT Problem

I guess we could rename ours, but would that require updating all shipped themes? Any other ideas?

-- Aaron

[cketti]

On 14.08.2013 14:08, aap wrote:

I pushed a branch "ui_update" in which I tried, as a first step, to move to the v4/v7 libraries. It doesn't quite compile due to a resource conflict -- apparently appcompat defines an attribute named "divider" which is not an integer.

Description Resource Path Location Type

error: Error: Integer types not allowed (at 'divider' with value '0'). themes.xml /OI Shopping List/res/values line 24 Android AAPT Problem

error: Attribute "divider" has already been defined attr.xml /OI Shopping List/res/values line 38 Android AAPT Problem

I guess we could rename ours, but would that require updating all shipped themes? Any other ideas?

As far as I can tell you could get away with updating the local themes and adapting the code to use a different attribute name for local themes while still using "divider" with external themes.