As we are aware that we can use the react-navigation for handling the navigation with multiple screens in react native app, my question is- Consider we have a to load a sequence of more than 300 screens dynamically, then what is the best way to handle this scenario?
The screens can be templates which will render differently based on the data loaded each time. Say I may have 30 types of different templates and each one need the API data for rendering the layout. The total 300 screens are a kind of repeating templates from the 30 different types. This is an app something based on e-learning platform.
Appreciate your suggestions in advance
Related
I'm allowing users to select an icon from the full list of FontAwesome icons (using a List<ImageVector>). I'm going to open a dialog, and show the icons as IconButtons arranged in the list. There are ~1600 icons.
I implemented it using a LazyVerticalGrid, with a fixed number of columns. It works, but there's some lag loading the icons, and lag when scrolling the icons.
I'm converting this from a React Native project where I did the same thing (with a larger set of icons, actually) and scrolling that was pretty snappy, so I'm assuming it's possible to do performantly on native. Perhaps ImageVectors are heavier than the SVGs I was using in React Native?
I'm planning to provide a search box in the dialog where users can filter the list down by doing a fuzzy search on icon names, so the grid will change over time.
What sort of patterns should I be looking at here? Is LazyVerticalGrid the way to go, or should I be using a different approach entirely?
On Laziness
For an overview of use cases and appliable patterns you might be interested in the Android Dev Docs' page on Lists and Grids, încluding the topics Large data-sets (Paging) and the Tips on using Lazy layout.
This might wake your interest on the Android Jetpack Paging Library androidx.paging, which is designed for loading and displaying pages from large datasets, basically uniting the concepts of Laziness and Caching.
Currently you're only using Laziness. As Bartek Lipinski commented, that should usually be fine when the graphics to display are static. However, when they have to be loaded asynchronously, Paging will probably improve your performance.
Some Rules of Thumb
Scrolling
Pattern
No
Column or Row will be enough
Some
Column or Row with modifiers verticalScroll and horizontalScroll
More, static content
LazyColumn or LazyRow, resp. for gridding LazyVerticalGrid or LazyHorizontalGrid
More to mass, dynamic content
LazyColumn or one of its relatives with LazyPagingItems, so using the Paging Library androidx.paging
Also, as the docs say, consider adding contentType
. However, as Bartek Lipinski remarked, one usually benefits of contentType when there are scrollable elements of various types -- not only SVGs as maybe in your case. Still, giving hints to the system doesn't hurt, at least.
On Vector Graphics
As discussed in the comments, esp. by Subfly and Bartek Lipinski, though Laziness should be the main thing here, another bottleneck could be the loading of vector graphics during runtime.
If the graphics used are of static nature, then consider the usage of vector graphic assets. Those are supported for SVG and PSD since Android 5.0 (API level 21). Take also a look on the recommendations and some aspects of support and restrictions on SVG.
Summary
The basic formula is Laziness + Vector Assets with focus on the first. One might spice that with contentType and Paging.
I'm trying to put together a complication for my app, I'd like to have it potentially display different images depending on the content of the complication entry but am not sure how best to handle this.
I've got a complication group added to my watch extensions asset catalogue but it only seems to have slots for a single icon in multiple versions, for complication family and device size. I'm presuming this one that is linked to my watch's complication group is only for use by placeholder content, but then as you construct this template yourself I'm not sure why it has this project setting association with a group.
As I would like to add around 10-15 icons to choose from do I need to add multiple complication image sets to my watch app assets? Last years WWDC video on creating complications was early and had them working with images directly instead of image sets, but for the different watch sizes etc I'm presuming image sets are the preferred way to go about this.
Thanks for your help in advance, cheers!
At the moment it seems I'm able to work with normal images that are shared in my app between my iOS app, today widget and watch app. They work ok at the moment, but I'm not sure if they're the right way to go about it as they're definitely not the right size for complications being 30,60, and 90 pixels depending on the scale they're targeting. Still not entirely sure what the complication set is for in the assets as they don't seem to match the image size outlined in the apple guidelines for complications
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 have an app which has quite a lot of activities, and all of the activities' layout have lots of views (TextViews, to display different kind of data in different styles, ImageViews etc).
When the activities load, they take too much time to load the layout/UI (more than a second).
Ques: Is there a way to reduce the time it takes to load the activity, because the activity takes too long to load the UI?
A short description of what I have:
All the layouts have at least 30-35 views
I am using Relative Layout
I am not nesting layouts, most of the views are parallel to each other, and the overdraw is at max 2x
All of the text views are custom, setting a custom font for them
The UI is being loaded in onCreate() of the activity
I am thinking of doing either of the following things:
Converting the app into Fragments in a way there are less number of activities, and more number of fragments. For example, there is one Home Activity which loads the first fragment, and further interactions with the app keep loading/switching between fragments for different purposes via Fragment Transactions. I would spawn a new activity only when I am hitting a limitation of Fragments.
Will it help improve the speed?
Disintegrate the UI in a way were the most basic UI is loaded in the view once the activity starts, and all the other UI elements are inflated in a background thread (AsyncTask) and are then added to the root of the current view.
In different opinions, which approach would be better?
Is there a better or standard way of solving this problem?
Appreciating all the inputs. Thanks in advance!
Here are some more suggestions to what you've already going to do.
If you inject views in onCreate() method, make sure you use design-time injection frameworks (Bufferknife or AndroidAnnotations) and not runtime ones (Guice, RoboGuice). Runtime frameworks definitely slow startup time down.
If you have views, which are not visible to the user initially, you can use ViewStub and load them on demand.
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.