I want to implement custom HDividedBox using Flex 4 API. Splitter should be dynamic skin part.
I can't find any examples of controls where skin parts position should be calculated depending on the number of children and their sizes. Seems like this kind of controls does not fit into the standard Flex 4 model: Skin, Control, Layout. Can somebody please give me some tips on this?
In our last project we had to implement a Splitter, but we approached this from a bit different perspective. We decided that creating a HDividedBox component is not flexible enough - imagine the case where you'll need to extend the UI with an additional splitter, so that you have 3 areas divided by 2 splitters... The splitter should be somehow decoupled from the actual containers that are split by it.
I'll try to summarize our solution:
<s:VGroup>
<components:Container1 id="container1"/>
<components:Splitter id="splitter"
topComponent="{container1}"
bottomComponent="{container2}" />
<components:Container2 id="container2"/>
</s:VGroup>
The Splitter component is a component with a relatively simple behavior - depending on how you drag it, you update the height of container1.
I know I'm not addressing your technical question, but sometimes it is more feasible to restate the problem and to address it in a bit different way. This often leads to a more elegant solution as in the case above.
Related
I have a lot of FlexLayout element in my template and it is so slow on iOS devices.
i replaced that with StackLayout and now it became little fast than before.
I'd like to know which Layout Container is fastest layout in Nativescript.
There is never one right solution for all various needs, which is why we always have options and that applies to layouts in {N} too.
Learn more about layouts interactively at nslayouts.com and choose the one that suits your use case.
If you show use what exactly you are trying to achieve, we may able to give you some suggestion. There are some general guidelines you may have to follow for better performance,
Avoid nested layouts
Use GridLayout when you need known number of partitions in your UI, the less the number of partitions are, the better the performance would be. Use FlexboxLayout otherwise.
If you just want to stack items in vertical or horizontal order, StackLayout may be a good option. Use FlexboxLayout only when you want to use flex box specific features, like when items has to be wrapped to next line, change order of items etc.,
Try to not use StackLayouts just for the shake of borders around, since you can add border to the component itself.
If you have really complicated heavy UI components, you may load it once the page has completed navigation, that may be faster.
Prefer ListView over Repeater / for loop as much as possible.
By following the above at least I can confirm, I don't hit performance issues in my apps where I have 100s of elements and 10s of partitions on screen. If you still face issues, try creating a Playground example where we can see the issue.
I noticed this same thing with FlexboxLayouts on IOS where I was doing animations with the layouts. It worked great on Android, but was very slow on IOS. I switched it to a GridLayout, and things worked a lot better.
I'm analyzing my approach with Gmail's android developer's team approach in order to optimize drawing times and generally create more efficient apps.
My approach:
Below is the hierarchy inside a listview. It's quite straightforward. ExpandableListContentItem extends a Relative layout which has 3 Views:
Gmail app:
The following screenshot is how the listview in Gmail app works (SwipableListView). It's interesting to see that there is only one View (I guess aY extends ConvertationItemView) which in reality is quite more complicated than mine (I see 3 texts, 1 photo, 1 icon/button).
Question:
I would assume that this is a more lightweight approach to get rendered, is it so? Even if it takes me more time to code an optimal single customview per listview item it is worth the performance that it offers?
Finally the only way I know so far is to inflate an existing view inside another which is basically the first approach. I guess now my challenge would be to combine that relativeLayout with the 3 nested views into one. Is that correct?
PS:examples, open source code are welcome.
I would assume that this is a more lightweight approach to get rendered, is it so?
Yes it is. When you consider hierarchy, every parent measures their dimensions and passes it to child views from top to bottom. Reducing layers and having more flat view will save time.
Even if it takes me more time to code an optimal single customview per listview item it is worth the performance that it offers?
Depends on application you are developing. Depends on number of items in a list and how you get them. When you scroll through the list, if you think it is slow you might want to try that approach. I tried it on my previous applications and I could see the difference.
I guess now my challenge would be to combine that relativeLayout with the 3 nested views into one.
I don't know what you mean by combining them but the way Gmail does it that they have their Custom View. You can create your custom view.
Besides that, another thing to consider is overdraw. It is as important as having flat views. If you activate GPU Overdraw from developer tools and look at Gmail app row, you will see 0 overdraw. Make sure your code has no overdraw.
For further reading I would recommend you to check these blogs :
Performance Tuning On Android
Android Performance Case Study
I'm pretty new to programming and want some advice on the basic app structure so forgive me if this is pretty obvious.
The main part of the app is a series of 20 pairs of views which the users moves through sequentially (1a,1b,2a,2b,3a etc). Each a view and b view have the same layout as other a/b's but have different image, audio and text.
I could set out all 40 views in storyboard in one long line but that seems like I'm duplicating a lot of work (as well as creating a larger size app) although it would be conceptually very simple (and more stable?)
Alternatively I could just have two views (a and b) with all the content and some sort of counter so that Xcode would know which content to serve up depending on where the user is in the sequence. What would be the easiest way to implement this? I'm afraid however that this could also get unwieldy and perhaps keeping it simple really is the way to go.
Any advice gratefully received.
Many thanks
Design is totally dependent on complexity of screens not on the number of screen. If Screen won't have much variation then you can go for second approach having only 2 views and conditionally loading the data.
Alternatively if you want to go with approach first you won't need to duplicate all the steps. You can programatically create two super class which contains all the functionalities, and the part which varries for that you can create separate class(Inheritance concept). This will make the thing easier, you can reuse the code as well as increase the maintainability of app.
I'm creating a library of UI elements, and I want the graphics to be custom. At first, I was going to draw everything with code, and take properties such as "background-base-color", "background-gradient-color", etc. I was concerned that the user would need to modify too many properties and might get confused. I eventually talked myself into using external graphics, such as button_top_left_over.png and etc. Now I'm back and forth. I want people to easily be able to change the skin, so my options are, have them create external graphic libraries, or have them update properties in a front end that would write to XML, such as background-base-color, background-base-highlight,etc. Anyone have experience with this, and can offer advise?
You may "guess" gradients by a given single color, and it should fit in the most of the cases. Here is an algorithm: ColorUtil.as
Customizing components is a common problem. The user shouldn't need to step that deep into the implementation but we sill want a maximum of flexibility. For that, I have created a CSS framework: Jakute Styling Engine. Using Jakute you may set up your component using states.
Instead of declaring tons of properties for each state:
Button top_left_over: red.png
Button top_left_down: blue.png
Button top_left_disabled_over: grey.png
With Jakute you may specify stateful rules:
Button:over top_left: red.png
Button:down top_left: blue.png
Button:disabled:over top_left: blue.png
In this case the user only needs to know the list of button states and the single property "top_left". The styles can be loaded from an external style sheet or directly set to the component.
Finally, here is an example that shows you how to create a stateful styleable component: States Example. Even if you are not plan to incorporate Jakute, you might get an idea of how others create such components. :-)
am looking to prototype the UI for an windows application. The app will be deployed on several display devices with different (physical) screen sizes and aspect ratios. Would like to be able to generate scenarios optimized on one display and quickly check if the layout is OK on different screen sizes, orientations. That is, I'd like to prototype one set of scenarios and "automatically" generate the same scenarios on different screens. Have superficial knowledge of MS Sketchflow. Have seen some best practices at http://www.wpftutorial.net/LayoutProperties.html#best . Am wondering if folk can advise on best practices to follow in sketchflow.
Bye
To quickly be able to check how things will look, I have 2 possible suggestions:
Use the states panel to create a state group/states that change the size of the layout container (such as layoutroot) you are working with. Then in the sketchflow player, you can select the state from the navigation menu and see how it looks.
Use a ChangePropertyAction behavior from the asset panel attached to a button. You can set the height or width to the size you want. If you use 2, you can set both the height and width. This would give you the ability to control the layout size and see how it is rendered.
Hope that helps, let me know if you need more info.
Keep a consistent theme between the pages, kind of goes without saying.