Is there a tree control for the iphone? - iphone

Is there a Tree control available for the iphone?
I need to represent a tree with sub nodes in a tree, how can I do it?
Thanks

No tree widget by default. It's basically not there because you shouldn't really need one and most cases it should probably be avoided.
A table navigation controller is the most common way to navigate down nodes in a hierarchy/tree usually.
It's hard to fit a tree like control we have on our desktops in the touch world where you have huge fingers (so huge nodes) and with the nodes offset to show depth, there isn't much space left over. Adding it to the iOS environment would create a weird UX flow so I would probably rethink my design flow if I think I need one.
If you need to fake it, you can use a table view and offset the left side of each subitem with some padding to show depth.

See this help
Rolling your own iPhone treeview control
part 1 : http://dotnet.kapenilattex.com/?p=566, part 2 and part 3 are in the pages : 585 and 633
part 4 : http://dotnet.kapenilattex.com/?p=648&cpage=1#comment-59842

I would use a UITableView and expand and collapse items further down the tree. You can set an indentation level for each UITableViewCell as it is displayed, depending on its position in the tree. You would need to keep track of which items in the tree are expanded/visible in order to always provide the tree with the correct data.
I just did just that for a project. Unfortunately I am not at liberty to share the full code. But it should not be terribly hard to write.
Let us know if you find an out-of-the-box solution.

From what I see, the best solution for my problem will be a BreadCrumbs control. I am looking for a ready solution of breadcrumbs, but if there isn't, it is not a big deal to write it.

OK, I did it.
I added a WebView and I am adding to it the crumb list. The design is similar to the Apple's official site.
When a user clikcs on the link, I call the popToViewController function and I am there.
This prevent the user from clicking Back and Back.
Hope this will help somebody.

Related

How to create a virtualized, reorderable list with dynamic sizes, and animated item adding and removal in Flutter?

I need a flutter list package with the following features:
Only renders items in/near visible range (virtualized)
Supports different item heights.
Reorderable through drag and drop
When an item is dragged to the edge of the screen, the list scrolls
When items enter or exit, the list animates nicely
The package ReorderableListView.builder (https://api.flutter.dev/flutter/material/ReorderableListView/ReorderableListView.builder.html) supports 1,3 and 4. No support for 5. Reordering animation was bad for items with differing heights (2) when I tried it out.
The package implicitly_animated_reorderable_list
(https://pub.dev/packages/implicitly_animated_reorderable_list/changelog) supports 3 and 5. Nothing mentioned about 1 or 2 in its readme, and a comment from January here (Flutter: Reorderable AND Animated ListView - any idea?) suggests 4 is missing.
Looking for advice on how to achieve this:
An amazing package that can do all 5.
A way to add features of these different packages together somehow. Is that at all possible?
Advice on forking or not forking and just starting from scratch.
In regards to forking what in your opinion is the most/least trivial of these features to build from scratch?
I'm new to Flutter, so anything I don't know enough to ask about in relation to this subject is also greatly appreciated.
Own answer:
There really isn't a need for any plugins or forks. ReorderableListview.builder can be used to accomplish all 5.
Not sure how I botched the code that made me think ReorderableListView.builder wasn't handling different heights of items correctly, but whatever the glitch was (maybe related to keys?), I'm not able to reproduce it. Interesting that all the docs/tutorials I found only show statically sized list items when dynamically sized list items are no problem.
As for the animated exits and entrances (i.e. not letting the list items seem to jump up and down in a disorienting way), this is really trivial to do by animating height with AnimatedContainer. The existence of a separate AnimatedList widget and ImplicitlyAnimatedList plugin threw me off a bit.

Turning scrollbar, ListView into timeline slider

I've been seeing this UI technique quite often at Dribbble, mostly demonstrated on iPhone as timeline, and I am really wondering if it's possible to do so on Android. The idea is to exploit scrollbar, make it activate each row it is passing.
Consider these schematics of a list of contact.
The first one is the list (photos on the left side, names on the right) split roughly in the middle with scroll track.
The scrollbar cannot expand and has to be smaller than the smallest row. I believe it is possible to produce this kind of arrangement by combining two listviews and make them roll together.
The second one shows the screen when scrolled and when the scrollbar moves to the second row. After it stops, the second row will expand its height. All hidden elements there like address, phone, etc will show up. Also, the moment the scrollbar leaves the first row / hits the second, the first row will toggle off. It will shrink and remove all elements except name.
I have been thinking about this scenario and one key question in this technique is whether the scrollbar has the ability to activate the row it hits. The only tool I know in regard to scrolling is onScrollListener but I wonder if it's sufficient. Does anyone have any insight into such scenario ?
Thank you in advance.
I've been seen something similar to this in lots of applications. Some of them are just using ListView with design tricks to look like that, others with custom views or something else. The idea which I have in my about this implementation is using two Fragments: left and right which are placed in one FragmentActivity. Left Fragment will be your image holder, where for example you will have a ListView or some other view depending on your choice which will communicate with the Right Fragment and when LeftFragment's ListView stop scrolling, fire an event to RightFragment's ListView to scroll to position 5 for example and expand that item. Not really sure if it's the best option and if it will work properly as you want, but that's the first idea which I can think of to do some implementation like this.
Hope this help you find the right answer.

Left-aligned tabs in GWT

I have a project in which I need a way to display essentially a list of tabs, each with their own content pages, down the left side of the page. I'm using TabLayoutPanels elsewhere to good effect, but after looking at how they are constructed it seems like it would be quite a bit of work to undo Google's carefully constructed layout and get it to work in any other orientation than top-aligned.
This doesn't seem like it would be an uncommon layout, so does anyone know of a successful implementation of this kind of container?
Best you can do is use DeckPanel, and make your custom tab controls to switch visible widget in that DeckPanel.

Arrange GUI elements in WPF in a similar way to the applications on the iPhone

I would like to arrange UIControls in WPF in a similar way to the applications on the iPhone. They should be positioned on a grid, but a user should be able to drag them somewhere else, after releasing the mouse button (or the finger in case of an iPhone) the selected UIControl should snap back to the next position in the grid. The other UIElements should be rearranged automatically.
Further the user should also be connect two elements with a line or something.
I'm not experienced with WPF. The first question is if there is a container which is suitable for something (System.Windows.Controls.Grid ?) or if I have to extend canvas or somethig else for this.
I would like to know which elements from the WPF framework can be used and which elements I have to write myself.
For people who do not own an iPhone: http://www.youtube.com/watch?v=3omhu2AUWC8
Update
I've looked at AnimatedTilePanel in the BangOTricks examples (see below), this one explains how to create your own Panel and how to let it arrange things there.. However I still need an idea how to implement drag and drop correctly in this example..
Unfortunately, you'll have to write a lot of things yourself, as WPF doesn't automatically do what you're looking for.
For positioning the controls, you can use either UniformGrid or Grid. Assuming it's much like the iPhone video you showed, you can just use the UniformGrid with 4 columns and however many rows you need.
For the dragging animation, layout-wise, you could start by manipulating the RenderTransform property on whatever is being dragged, but you'll have to set a handler to check once you've met whatever threshold necessary to move into the another "cell" -- and at that point, you'll have to changed the order of the items in the tree.
Take a look at AnimatedTilePanel from Kevin's Bag-o-Tricks at:
http://j832.com/bagotricks/
It doesn't do everything you want but it will show you how to write a panel that animates its children when changing size or order.
New input to this old post in 09. Earlier this year (2012) someone has wrote a FluidWrapPanel and open sourced it. I tried it and it works like a charm - just like that on the iPhone menu.
You can also apply to other UI Elements or UserControl.

Do edit pages and view pages need to have the same basic layout?

From a design and usability perspective is it best that an edit page mimics the layout of the view page?
Our view page is very dense. The data is tightly packed together, but when editing there are going to be extra controls next to each entry field. If we leave the layout the same it will be overly crowded. Will this cause problems with usability if the fields are rearranged?
It definitely impairs usability. Two hazards of re-arranging fields are:
Confusing users about which field they are editing
Making it difficult for users to find the field they want to edit.
These problems are exacerbated on high-density pages.
There are some times when this is ok. The best example I can think of is where the editor and viewer are different users. Another (more ambiguous) case is a situation where the edit screen needs to be highly optimized for fast throughput.
If possible, you might consider splitting the screen up, or making collapsable regions to give the user (and the screen) a little room to breathe.
In general you want to keep the edit page as simillar as possible to the view page. In general. There are cases where this just doesn't make sense especially if you have to input a lot of extra data that is not shown in the view, which it sounds like is your case.
What I would try and do is make sure you continue to group and order the fields in the same manner as if you were viewing so while they might be in slightly different places at least they would be logically grouped the same.
It depends upon your workflow.
If the user has to go back and forth between edit and view, it will be very confusing to the person, as fields may jump around, they might lose which field they are on, etc.
If your view page is very dense, you might try breaking it up into sections, each with its own edit function. You could have it shoot to its own edit page or be all 'web 2.0' and throw up a lightbox with the section edit form over the view page.
The more that things are similar, typically, the easier it is for a user to use. I don't know what your particular layout looks like but from a general point of view, a crowded view is often hard to look at and cluttering it up with additional controls would make it worse.
As much as I'm not a spreadsheet guy, editing in Excel or similar products is easy because it doesn't clog up the view with lots of controls. The edit panel is the view panel. For my own products, when things are consistent, the users are generally less confused.
I have had a similar problem. What I did was have a View page that lets you see everything, but you need to drill into individual edit pages for logical sections. Within the logical sections the fields are always in the same order (and with the same labels) as on the view page. It's things like this which make your application just feel a bit nicer.
Don't throw everything onto a massive edit page just because they all relate to the same thing in your database model. Break them out into sets that make sense each with 3-7 fields on them.
If they really need to edit everything (like when creating a new thing) then I would go for a wizard approach which steps through through, presents a view-only summary and then lets them save.