More mobile widgets in Toga

[Tzu-ping Chung]

Hi,

I’m looking into implementing more widgets for iOS, and possibly Android in the future, and to create a small app based on it. Currently I’m thinking the followings:

1. Tab control

This should reuse the OptionContainer class. The problem is on mobile platforms tabs have icons as well as label text, and 

OptionContainer’s add method doesn’t support that. Possible solutions I can think of are

 

a. Add an extra (optional) argument to “add”. This may require future updates for existing implementations so that code doesn’t crash on them.

b. Expect an “icon” attribute in inner widgets. If that attribute doesn’t exist, the tab has no icon.

2. Navigation

Android and iOS do this quite differently. I’m thinking a class with two methods push and pop to show the next view and performing “back” actions. The push method would take two arguments title and container, the first one would be the title of the next view.

3. Table

The table API for desktop OSs might work, but Table (or list view on Android) sections would be a problem. Maybe it should get its own API? If so, how should it look like?

4. Image view

This one is not mobile-specific, but should present in all implementations, really.

These, combining with existed widgets like scroll container, label, input and button, would be pretty enough for a reasonably usable app for static data display, IMO. Hope to hear your thoughts!

Yours,

--

Tzu-ping Chung (@uranusjr)

uran...@gmail.com

https://uranusjr.com

[Russell Keith-Magee]

Hi Tzu-ping,

Thanks for all this input - and for all the other bugs and feedback you're reported recently, too!

Some broad guidance before I jump into specifics:

 * At this point, all APIs are up for discussion. Just because I've written an API with a particular prototype, don't assume that just because I've committed some code that I intended that to be the final form of an API. For the most part, I've been in "get it working" mode, not "build the perfect API" mode. There are a couple of places where I've done something for a specific reason, but those are few and far between, and even then, I'm open to change if there's a good reason. 

 * With that in mind, *right now*, backwards compatibility isn't a huge concern for me. As the project matures, it will become increasingly important, and I'd expect that by the time we reach 1.0, Toga's backwards compatibility policy will be as strong as Django's. While we're at v0.1, I'm completely OK with breaking compatibility.

 * While a single API for mobile and desktop would be nice, I'm practical enough to realise that it won't work that way in reality. There will inevitably be desktop widgets that don't have mobile analogs, and vice versa. Where the same code won't work in both scenarios, a "tastes the same" API - that is, an API with similar conventions and naming schemes - is a perfectly acceptable outcome from my perspective.

On Thu, Oct 23, 2014 at 6:02 PM, Tzu-ping Chung <uran...@gmail.com> wrote:

Hi,

I’m looking into implementing more widgets for iOS, and possibly Android in the future, and to create a small app based on it. Currently I’m thinking the followings:

1. Tab control

This should reuse the OptionContainer class. The problem is on mobile platforms tabs have icons as well as label text, and 

OptionContainer’s add method doesn’t support that. Possible solutions I can think of are

 

a. Add an extra (optional) argument to “add”. This may require future updates for existing implementations so that code doesn’t crash on them.

b. Expect an “icon” attribute in inner widgets. If that attribute doesn’t exist, the tab has no icon.

I see what you're thinking here. I'm completely OK with the idea that an icon should be an optional argument to an OptionContainer - having an icon in a tab bar isn't an unusual requirement. Having a fallback strategy of "tab gets it's icon from content" is also an interesting idea - it would make things like document viewers and web browsers responsive to the content they're displaying, which I can see as potentially useful.

However, I'm not sure an OptionContainer is (necessarily) the right widget for this context in mobile. A closer analog would be to look at the way toolbars are done on desktop. 

A Container is something that can be dropped anywhere into a layout. You could, at least in theory, have a layout where two OptionContainers are stacked on top of each other.

A toolbar is a fundamental property of a Window, not a standalone widget - even though a toolbar is a standalone widget in some underlying toolkits. The reason for this is that you can't (or shouldn't) arbitrarily drop a toolbar anywhere in a UI - it needs to be at the top of a window. 

Similarly, the tabs in a mobile interface can really only appear as a list of options along the bottom of the screen. It's a "top level" navigation element, similar to the "Navigation" concept you flag in your next point. 

 

That said, this might indicate that there's a need to differentiate between Containers as a top level structural element, and Containers as layout boxes in a UI. Tabs, Split panes, and other widgets like this are all 'top level" structure; a top level container can either hold another top level container, or it can hold "content"; but content can't hold anything but other content. Does that make any sense?

2. Navigation

Android and iOS do this quite differently. I’m thinking a class with two methods push and pop to show the next view and performing “back” actions. The push method would take two arguments title and container, the first one would be the title of the next view.

This is pretty close to what I was thinking. I would also add the concept of "container level actions" - the "back" icon is a "top left" button; but on the top right you can put other buttons to do things (such as Add or Search buttons)

 

3. Table

The table API for desktop OSs might work, but Table (or list view on Android) sections would be a problem. Maybe it should get its own API? If so, how should it look like?

I can think of at least three approaches for this:

 a) Treat this as a "same flavour, slightly different API". Keep the API as close as possible to the desktop, but acknowledge that on mobile, there are differences.

 b) Treat "sections" as an outer container - i.e., a structural widget that contains table views. Each section is an independent table, rather than being one big table with sections. This ins't a good match for the underlying widgets, but it would keep a consistent API. A variation on this would be to have two widgets - a multi-section table, a single-section table, and only provide a single-section table on the desktop API.

 c) Come up with a visualisation of sections in the desktop table widget. I'm not sure what this would be - maybe an accordion-style widget?

 

4. Image view

This one is not mobile-specific, but should present in all implementations, really.

 

Completely agreed. The only reason they don't exist on mobile at the moment is because I've been focussing on getting the basics working.

 

These, combining with existed widgets like scroll container, label, input and button, would be pretty enough for a reasonably usable app for static data display, IMO.

Agreed - that's what got me going in the first place - you don't need too many basic widgets to get an app up and running.

 

Hope to hear your thoughts!

I hope I've shed some useful light on the situation! If there's anything else I can do to help you get going, let me know.

Yours,

Russ Magee %-)

[Tzu-ping Chung]

Hi Russ,

I have you to thank for the wonderful project. I’ve always wished for something like this for a long time, and Toga’s approach just makes sense. Really looking forward to contribute. :)

I’m going to try out a few things., and hopefully will come up with something soon.

1. Tab control

This should reuse the OptionContainer class. The problem is on mobile platforms tabs have icons as well as label text, and 

OptionContainer’s add method doesn’t support that. Possible solutions I can think of are

 

a. Add an extra (optional) argument to “add”. This may require future updates for existing implementations so that code doesn’t crash on them.

b. Expect an “icon” attribute in inner widgets. If that attribute doesn’t exist, the tab has no icon.

I see what you're thinking here. I'm completely OK with the idea that an icon should be an optional argument to an OptionContainer - having an icon in a tab bar isn't an unusual requirement. Having a fallback strategy of "tab gets it's icon from content" is also an interesting idea - it would make things like document viewers and web browsers responsive to the content they're displaying, which I can see as potentially useful.

I got it from how iOS sets the text in the navigation bar. Every view controller in iOS has a “title” attribute, and the navigation view controller uses it for the text in the bar (the title attribute has other uses too). If something is generic enough to exist everywhere it might be a good idea.

However, I'm not sure an OptionContainer is (necessarily) the right widget for this context in mobile. A closer analog would be to look at the way toolbars are done on desktop. 

A Container is something that can be dropped anywhere into a layout. You could, at least in theory, have a layout where two OptionContainers are stacked on top of each other.

A toolbar is a fundamental property of a Window, not a standalone widget - even though a toolbar is a standalone widget in some underlying toolkits. The reason for this is that you can't (or shouldn't) arbitrarily drop a toolbar anywhere in a UI - it needs to be at the top of a window. 

Similarly, the tabs in a mobile interface can really only appear as a list of options along the bottom of the screen. It's a "top level" navigation element, similar to the "Navigation" concept you flag in your next point. 

 

That said, this might indicate that there's a need to differentiate between Containers as a top level structural element, and Containers as layout boxes in a UI. Tabs, Split panes, and other widgets like this are all 'top level" structure; a top level container can either hold another top level container, or it can hold "content"; but content can't hold anything but other content. Does that make any sense?

Certainly. I was under the impression that there’s nothing similar to tab bars (a la desktop OS style) on mobile devices, but that is certainly not the case. The level differentiation makes sense, but I don’t feel it needs to be made explicit. It might be awkward to add seemingly top-level elements into a content element, but nobody will stop you from doing it—we just expect the user to do it the reasonable way.

Thinking along that line, NavigationContainer and TabContainer would be top-level, while Container would be content, right?

2. Navigation

Android and iOS do this quite differently. I’m thinking a class with two methods push and pop to show the next view and performing “back” actions. The push method would take two arguments title and container, the first one would be the title of the next view.

This is pretty close to what I was thinking. I would also add the concept of "container level actions" - the "back" icon is a "top left" button; but on the top right you can put other buttons to do things (such as Add or Search buttons)

The problem here is that different platforms do things quite differently. On iOS it’s reasonable to allow only one extra button on top right, and require all others to go into the bottom toolbar, but on Android it is more common to use one single top bar (ActionBar) and stuff everything in it. So it would need some kind of abstraction.

3. Table

The table API for desktop OSs might work, but Table (or list view on Android) sections would be a problem. Maybe it should get its own API? If so, how should it look like?

I can think of at least three approaches for this:

 a) Treat this as a "same flavour, slightly different API". Keep the API as close as possible to the desktop, but acknowledge that on mobile, there are differences.

 b) Treat "sections" as an outer container - i.e., a structural widget that contains table views. Each section is an independent table, rather than being one big table with sections. This ins't a good match for the underlying widgets, but it would keep a consistent API. A variation on this would be to have two widgets - a multi-section table, a single-section table, and only provide a single-section table on the desktop API.

 c) Come up with a visualisation of sections in the desktop table widget. I'm not sure what this would be - maybe an accordion-style widget?

Or maybe treat it as something completely different? Android’s rough equivalent to UITableView is actually called ListView (there’s a TableView that do two-dimention layout), so maybe it can be named like lister or something. I think most would agree that UITableView is completely differently from NSTableView, although with very similar names. On desktop both one- and two-dimentional tables would be available (with or without similar names), but on mobile only the one-dimentional one works (or maybe both can work if there’s a way).

Yours,

TP

[Russell Keith-Magee]

On Sun, Oct 26, 2014 at 1:35 AM, Tzu-ping Chung <uran...@gmail.com> wrote:

Hi Russ,

I have you to thank for the wonderful project. I’ve always wished for something like this for a long time, and Toga’s approach just makes sense. Really looking forward to contribute. :)

I’m going to try out a few things., and hopefully will come up with something soon.

1. Tab control

This should reuse the OptionContainer class. The problem is on mobile platforms tabs have icons as well as label text, and 

OptionContainer’s add method doesn’t support that. Possible solutions I can think of are

 

a. Add an extra (optional) argument to “add”. This may require future updates for existing implementations so that code doesn’t crash on them.

b. Expect an “icon” attribute in inner widgets. If that attribute doesn’t exist, the tab has no icon.

I see what you're thinking here. I'm completely OK with the idea that an icon should be an optional argument to an OptionContainer - having an icon in a tab bar isn't an unusual requirement. Having a fallback strategy of "tab gets it's icon from content" is also an interesting idea - it would make things like document viewers and web browsers responsive to the content they're displaying, which I can see as potentially useful.

I got it from how iOS sets the text in the navigation bar. Every view controller in iOS has a “title” attribute, and the navigation view controller uses it for the text in the bar (the title attribute has other uses too). If something is generic enough to exist everywhere it might be a good idea.

However, I'm not sure an OptionContainer is (necessarily) the right widget for this context in mobile. A closer analog would be to look at the way toolbars are done on desktop. 

A Container is something that can be dropped anywhere into a layout. You could, at least in theory, have a layout where two OptionContainers are stacked on top of each other.

A toolbar is a fundamental property of a Window, not a standalone widget - even though a toolbar is a standalone widget in some underlying toolkits. The reason for this is that you can't (or shouldn't) arbitrarily drop a toolbar anywhere in a UI - it needs to be at the top of a window. 

Similarly, the tabs in a mobile interface can really only appear as a list of options along the bottom of the screen. It's a "top level" navigation element, similar to the "Navigation" concept you flag in your next point. 

 

That said, this might indicate that there's a need to differentiate between Containers as a top level structural element, and Containers as layout boxes in a UI. Tabs, Split panes, and other widgets like this are all 'top level" structure; a top level container can either hold another top level container, or it can hold "content"; but content can't hold anything but other content. Does that make any sense?

Certainly. I was under the impression that there’s nothing similar to tab bars (a la desktop OS style) on mobile devices, but that is certainly not the case. The level differentiation makes sense, but I don’t feel it needs to be made explicit. It might be awkward to add seemingly top-level elements into a content element, but nobody will stop you from doing it—we just expect the user to do it the reasonable way.

Thinking along that line, NavigationContainer and TabContainer would be top-level, while Container would be content, right?

 

Correct - although in the current formulation, and Container *could* act as a top level container, too (ads the empty box without any navigation elements). Given the conversation about containers having labels, I'm wondering if the abstraction might be that there are "Containers", which are top level, and "Boxes" which are organisational; containers have labels, boxes don't.

2. Navigation

Android and iOS do this quite differently. I’m thinking a class with two methods push and pop to show the next view and performing “back” actions. The push method would take two arguments title and container, the first one would be the title of the next view.

This is pretty close to what I was thinking. I would also add the concept of "container level actions" - the "back" icon is a "top left" button; but on the top right you can put other buttons to do things (such as Add or Search buttons)

The problem here is that different platforms do things quite differently. On iOS it’s reasonable to allow only one extra button on top right, and require all others to go into the bottom toolbar, but on Android it is more common to use one single top bar (ActionBar) and stuff everything in it. So it would need some kind of abstraction.

 

Agreed that a platform abstraction may be needed.

 * iPhone can allow multiple buttons top right; Twitter, for example, has a search and compose button.

 * iPad has a lot more room and allows multiple menus; Keynote has 3 buttons on the left, and 2 (plus a notification text) on the right.

 * Android also has the "action" hardware menu that can provide contextual menus, which is an additional source for context-based options. 

I'm not completely sure what the right abstraction will be - we may need to survey a few apps across platforms to see how they handle various options.

3. Table

The table API for desktop OSs might work, but Table (or list view on Android) sections would be a problem. Maybe it should get its own API? If so, how should it look like?

I can think of at least three approaches for this:

 a) Treat this as a "same flavour, slightly different API". Keep the API as close as possible to the desktop, but acknowledge that on mobile, there are differences.

 b) Treat "sections" as an outer container - i.e., a structural widget that contains table views. Each section is an independent table, rather than being one big table with sections. This ins't a good match for the underlying widgets, but it would keep a consistent API. A variation on this would be to have two widgets - a multi-section table, a single-section table, and only provide a single-section table on the desktop API.

 c) Come up with a visualisation of sections in the desktop table widget. I'm not sure what this would be - maybe an accordion-style widget?

Or maybe treat it as something completely different? Android’s rough equivalent to UITableView is actually called ListView (there’s a TableView that do two-dimention layout), so maybe it can be named like lister or something. I think most would agree that UITableView is completely differently from NSTableView, although with very similar names. On desktop both one- and two-dimentional tables would be available (with or without similar names), but on mobile only the one-dimentional one works (or maybe both can work if there’s a way).

I've got no problem with it being a completely different widget, if that's what we need to do. 

Yours,

Russ Magee %-)