I'm working towards designing an interactive menu. The main idea is a dashboard with some buttons within (see picture for example). After an user clicks on the picture, the app would render a similar dashboard, but with different buttons.
The flow of the dashboard would have depth 3 => Main categories => sub categories => sub sub categories.
My question here is, what is the best practice to avoid the user from generating a lot of screens within the app (by clicking a lot of buttons)? Does flutter automatically take care of this? I guess my main concern is, what could go wrong in terms of designing something like this in terms of cell phone using too much power to render the app?
Thanks!
My humble approach toward this is to create only one view (screen) and use a state management package to update the view. I'm familiar with flutter_bloc.
In your state you would define an int to keep track of the menu level:
menuLevel == 0: main memu
menuLevel == 1: sub menu
menuLevel == 2: sub sub menu
Then in your view's BlocBuilder you update the view based on the menuLevel state property.
This answer might sound a bit vag because it assumes that you are familiar with state management in Flutter. In particular with flutter_bloc. If not, I strongly recommend you learn a bit more about state management as it will save you time and help you better tackle this kind of situation in an efficient manner.
Related
I'm trying to make a Gym app. You can add a workout by pressing the + on the appbar, and this takes you to a new screen where you can add the information about all the exercises and the workout name. When you press the check button, it goes back to the main screen where it displays all the workout that you've created, so that if you tap on a list tile it displays all the exercises.
My problem is that I don't know how to pass all the information about the exercises back to the main page. The only thing that I pass back is the workout name. My idea was to pass a Map<String workoutName, List> so that in the main page I have everything that I need. What do you think about it?
P.S. Rn I'm not storing anything in LocalStorage yet, mainly because I don't know what to store I was thinking about storing the Map<String workoutName, List> But I'm a fresh dev on Flutter so there may be easier solutions.
There are many ways to do this. Because of the inevitable growth of your requirements, I suggest going with the most common way to both pass variables and control your state. Meaning: when your variables change, when you return to your original screen, the screen also rebuilds to show your new information. Riverpod has become the successor to the previously Flutter team recommended State Management solution.
I suggest finding a nice, popular tutorial on Riverpod, perhaps building an app entirely with the video to give yourself a good start.
Im currently working on a project where I want to the user to be able to chose between two layouts (list and grid) at runtime. I was searching for examples in the UI5 documentation (Sample Apps) and on GitHub, I did not find examples for how to to this or best practice examples. So I thought about how I could achieve this behaviour and had multiple ideas, but somehow none of them feels like doing this would be best practice.
Idea 1 - Destroy the "old" controls and generate the new controls inside the Controller
My first idea was to destory the controls I do not longer need. For example if the user wants to switch to the grid layout, the list and every control related it to it gets destoyed. In the controller the needed controls for the grid are created and then rendered in the view. In my eyes this would mix up view and controller logic inside the controller and does not feel like best practice
Idea 2 - Create two views and switch between them
My second idea was to create two views, each for the layout I need and switch between them. This would mean a lot of code replication in both the controller and the view. Does not feel like this would be the right way.
So I would be glad if you have own experience on this or if there is really something like a best practice for such a behaviour.
Thank you and kind regards!
I would say, idea 2 because of the following reasons:
It is best practice to work according to the MVC methodology which means separating logic, view and data. Since the controls define your view it is best to instantiate your controls in the files that are meant for it (the XML Views).
Performance: Destroying all controls means that if the user decides to switch between views, the controls have to be re-instantiated by the controller every time. This is, even though you probably won't notice it, not performant.
You don't need code replication: The argument of code replication is not necessarily true. If you can execute the same actions in the list and grid-view, it should be enough to just link the controller to both views and in that case you'll hardly have to replicate any code. Just make sure that you split your logic in enough functions. That way you might need to write some extra public functions to handle events, but not much more.
We have built a large scale application over eclipse rcp framework. This issue we are facing across the application if large number are objects are selected say 4000 or 5000 objects. In this case, following actions takes time and UI goes in Not Responding state.
1.Select and Right Click Context menu display
2. Keeping selection, change the view and come back to earlier view.
3. Keeping selection, change the application(like excel, word) and come back to view.
My analysis says, the eclipse rcp takes time to evaluate the menu contributions and handlers for the current selected objects. We are also using Property Testers nested inside Iterate expression which I think is taking time to evaluate. Pain is it does the evaluation every time I switch the view and does not cache the result.
I need your opinion:
Has anyone else encountered this issue before? Is there any good way to handle large selection in handlers, menu contributions which will improve the performance.
Thanks in advanced.
~Prasad
It might be that the main problem are your property testers, because those are evaluated each time something changes visually in your app: new shell (like menu, dialog, wizard etc.) is opened or some panel is expanded/collapsed or you switch perspective or view/editor or you go switch application.
May be as a first step you could try to disable those (or make them dummy and do nothing/or constant action) to see if it affects performance of the application. If it does, then you might think about redesigning your application and replace property testers with, for example combination of org.eclipse.ui.AbstractSourceProvider and org.eclipse.ui.contexts.IContextService.
I am not sure, of course, about your real use cases, but here is some idea:
Source providers can also be used within plugin.xml as a variable.
Then you can register a bunch of contexts (I am not sure, of course, about real use cases, just suggesting here), which can be programmatically activated under some conditions:
final IContextService contextManager = (IContextService) activeWorkbenchWindow.getService(IContextService.class);
contextManager.activateContext("your context id");
Another step would be to register context activation listeners:
final IContextService contextManager = (IContextService) activeWorkbenchWindow.getService(IContextService.class);
contextManager.addContextManagerListener(new IContextManagerListener() {
#Override
public void contextManagerChanged(ContextManagerEvent contextManagerEvent) {
if (!contextManagerEvent.isActiveContextsChanged()) {
return;
}
[process context changes: possibly notify source providers about context changes]
}
});
Make your SourceProvider listen to context changes and refresh state, when something has been actually changed:
#Override
public void contextActivated() {
fireSourceChanged(getSourcePriority(), refreshState());
}
If it is not the case or not possible in you application, then, may be, some other workaround would be to introduce caching in source provider or improve your algorithm performance, by, for example, making some long running operations on parallel with multiple Thread. If you are using Java 8 this should be fairly easy.
Of course there is always a case, that SWT is slow by itself to redraw all the widgets - in this case you may be should look into using alternatives to standard SWT widgets with better performance. For example, using Nattable instead of default SWT/JFace viewers.
I hope this could give you some ideas.
Im pretty new in using the MVVM architecture and looking for some advice on the "correct" to approach this task.
2 page app.
Page 1 displays the alphabet.
Page 2 displays the selected character's details.
Example - Select "A" and screen 2 displays apple, Apricot, Aprium. Select "B" screen 2 displays Banana, Blackberry, Blackcurrant, Blueberry.
Data is being retrieved from a web service everytime the user selects an alphabet character.
Would the correct approach be to create a static menu for screen 1 (as you would never have anything else other than the alphabet characters) and on the click event load the second screen with the items as above using the MVVM approach (i.e. pass in the selected character to the LoadItems method). Or is there a simpler way to do this using a MVVM structure?
Ive read around and its not very clear on when to use which approach but then again as i say im new with MVVM too and would like to learn the correct/preferred way so i can get a better understanding.
Another approach which maybe more in-keeping with the Windows Phone experience would be to have a single page containing a LongListSelector. Fruit bound to this view could then be grouped by letter. Implementing a JumpList would allow users to quickly navigate this list by jumping between groups. You can find a sample implementation here- http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj244365(v=vs.105).aspx
Microsoft actually prefers that when you use a list in windows phone it is always better to display it in another page. So you should populate the list in another page. And if you are selecting some thing to show then pass them as parameters using the NavigationService.Navigate or store the data in Phone Application State if you have to use app wide. Phone.Application.Resources . Its good that you are going through Mvvm You'll know Xaml, WP7,8, Get Metro Application Idea also Silverlight.
Heres a toolkit that might help you. It also displays the same way in a new Windows Not a popup
Long List Selector
I want to implement navigating a tree structure like it is done in e.g. the WinRT file picker. I then want to be able to drop this behavior as part of any page.
My current attempt, is to try and register a secondary FrameAdapter/INavigationService in the container and use that for a frame that is different from the app root frame. So far, I could not get it to work.
My motivation behind that, is, that I do not want to reimplement sth. that the INavigationService already provides.
Basic structure:
ShellView that represents the general app layout (header, footer, navigation) and is currently an OneActive conductor.
Frame control (x:Name="ActiveItem") on the ShellView inside which the hierarchical navigation should occur
The chosen conductor has no relevance yet, since I'll probably have to nest the FrameControl inside another view later to really set up a MDI interface. I'll will want to have multiple screens that should be able to hierarchically navigate
I could not find a CM WP7 example of such a scenario
Can you help me out here?
My problems so far:
How do I access the container from a view code-behind without resorting to using the Application.Current. I figured, it is in the code-behind where I would want to setup the secondary FrameAdapter, since it is here that I have access to the FrameControl
How do I setup the INavigationService so that the initial loading by CM (populating the ActiveItem) is registered with it. There does not seem to be a navigation event for this initial display of the ActiveItem.
Many thanks in advance,
Tobias
PS: I have cross-posted to the Caliburn Micro discussions (Discussion over at CodePlex CM)