I am working on a todo app that interacts with an API to store data. My view structure looks like this (simplified):
ContentView: List of { ProjectView }
ProjectView: List of { TaskView }
The ContentView has a webServer variable that provides functions like storeTask(task: Task) and deleteTask(task: Task).
So now I want my TaskView to be able to modify tasks. The most straightforward pattern seems to provide storeTask and deleteTask to TaskView to keep the view ignorant of the implementation details. That means that I have to pass these two functions through the whole tree of sub-views: ContentView -> ProjectView -> TaskView. But then, a minor change in function signature requires a changes for every view that's part of the view hierarchy.
This feels like an inefficient pattern as it's already complex for the simple app I am building. What are other approaches? For context, I remember this same issue from working on React, and using approaches like Redux to deal with this. I'm wondering whether there's a standard approach for simplifying this in SwiftUI?
The most common architecture pattern in SwiftUI is MVVM (Model-View-ViewModel). There are many articles online explaining it, but essentially the layers break into:
Model - manage a piece of data
View - manage the UI
ViewModel - manage the data (models) to be displayed in the UI (view)
To answer your question, you would need to create ViewModel layer that manages your data and pass that ViewModel throughout your Views (as #Asperi mentioned in the comments).
Here is a great article explaining MVVM: https://matteomanferdini.com/mvvm-pattern-ios-swift/
Here is one of my Github repo's that uses MVVM Architecture in SwiftUI to make a todo-list app, similar to your project. If you take a look at the ViewModel layers you will find examples of what you're trying to do. https://github.com/ndsarno/TodoList-MVVM-Advanced
Related
I'm working on a app that is written with swift3 in Xcode8.
My app implements the Cosmicmind-material-framework.
While the working i tried to understand what the difference between NavigationController and ToolbarController is. (maybe someone can additionaly explain the difference to PageTabBarController, too)
I don't really get it because it seems that the navigationController contains a toolbarController.
So why should i use both if i can only use the navigationController and prepare all "toolbar-items" there.
Shortly to the app:
NavigationDrawerController
NavigationController
Site 1
Site 2
PageTabBarController
Site Red
Site Blue
Site Yellow
good question.
The main difference between a NavigationController and ToolbarController is that a NavigationController is a subclass of UINavigationController and gives you all the benefits of that class while allowing you to customize the look and feel as if you would a ToolbarController.
The ToolbarController provides a different type of flow, one that transitions the rootViewController using the transition method between view controllers. It also provides a floating view controller that can effectively be used in many ways.
Like the ToolbarController, the PageTabBarController inherits from the RootController, which provides the same rootViewController transitioning, but by default offers a UIPageViewController as the initial rootViewController.
So what is the point of all these different controllers? The main design reason is to allow you to stack view controllers that have these special controls in order to create more complex navigational architectures without the fuss of maintaining their organization. Each is accessible within the hierarchy while managing their own code complexities. The user has the perception that they are all working together seamlessly.
A good example of this is the CardTableView sample project, which also shows how to layout Cards within the PageTabBarController using TableViews that have dynamic heights based on content. For the most part, the entire UI is driven using persisted data powered by Graph.
Hope that helps :)
How implement adapter in xamarin.forms (xaml) simple ? But all example is for andorid or iOS. Can writing example for xamarin.forms
Adapters are part of the native Android UI framework for displaying data using the MVC pattern. In the world of Xamarin Forms, the best analogue is a ViewModel and the Model View ViewModel pattern (MVVM). In its simplest form, a ViewModel is any class that the view binds to by having an instance of that class assigned to the View's BindingContext. This is, by itself, enough to perform one-time binding where the values in that class' properties are read by the View when the View is created. If you want more advanced binding where updates to the underlying ViewModel are reflected in the View, you need to implement INotifyPropertyChanged and send notifications to the View. Also, rather than roll your own, I would recommend that you look into using an existing MVVM framework such as MvvmLight.
To acheieve what you are looking for, you would have a ViewModel expose a property that is of an IEnumerable or IList. You could then bind one of the repeating views such as ListView to this property and see the underlying data reflected in the view. By implementing INotifyPropertyChanged (or using a framework that does that for you), you can have new items added to the collections exposed by those properties appear in the UI.
Mortar view do not directly inflate it's content. Instead there is an assumption that layout with mortar view will have view content nested in it.
I feel it makes little harder to manage connection between view and it's layout.
What was the reason to put view classes to layout instead of inflating layout inside view class?
It's not a requirement, but for one thing it helps with responsive layout. Android can inflate totally different views for you based on configuration. And we like having a single convention in our code, less to think about.
Originally the #Layout annotation could also take a view class reference. We screwed up that code in a way that broke theming, liked this pattern better, and yanked the broken code since we weren't using it anyway. But there's no requirement that you map screens to views that way. That's why the Layout helper is an annotation, not built into any api. And it's why the new PathContainer delegates view construction.
Are controllers in ember.js meant to be tied to main view areas/scenes a la iOS, or more tied to a set of data?
Is it common/wise to have several main views tied to the same controller in ember?
In iOS main portions or sections of the screen are tied to a single controller. If you want to present another main interface, say a modal window to create a new element, you (typically) have an entirely separate controller to manage that view and its data/logic.
In something like Zend Framework, you have controllers that might perform some common spinup steps of ensuring authentication, but largely the actions play the role that controllers do in iOS, handling the logic and providing the data for 1 main section or view (being the web, this usually ends up being the whole page).
What is that typical role or advised pattern for using controllers in ember?
You have a couple different questions here so I'll address them one at a time.
First, you asked if controllers should be data oriented or view oriented. In my experience both behaviors are allowable. Controllers are an excellent way to manage data sets for your application, including things like filtering and searching. Evin Grano wrote a good post about this from the SproutCore perspective and most of the concepts should apply to Ember as well: http://www.itsgotwhatplantscrave.com/2009/07/30/root-controller-paradigm/. Controllers are also well suited for controlling the application state and behavior. For example, you might put a method in a controller that is bound to as a button action elsewhere in your app. However, you should also examine Ember States to see if these might be better suited to your scenario.
Secondly, you asked about tying multiple views to the same controller. Personally, I see no concerns with this as long as the controller maintains a distinct purpose. If the views are logically related and share in the same state or data then a single controller makes sense. If you find the controller growing to cover too many different areas, you should consider splitting it into multiple controllers.
From my limited experience in Ember.js, I have regulate to the following:
The view handles user actions related to changes in the presentation layer, limited to its own instance.
A navigation controller/statemanager handles complex manipulation of what is presented (add multiple views, remove some other, etc.).
The controller responds to user actions related to the data layer.
I just having a little trouble to implement a special kind of view for Ember, I'm digging on the source for days but can't find how to make it work... Can you take a look and tell me what's wrong? It's a small code, a specific problem when rendering one view from another (it's not doing the binds right...).
The sample code (with comments) that demonstrate the problem is here: http://jsfiddle.net/wilkerlucio/rUUuN/
Edit:
Just to clarify, I'm trying to do a view that dynamically render another view. It can be useful for a lot of implementations, like tabs for example. On tabs you have the tabs and the container that shows current tab, so, the view that I'm trying to accomplish is like this current tab container. Each tab has it own view, and I need that my view be able to render the view for the current tab.
I know I can do things like just hide a view and show the other, but it's not the way I want it right now. This CardView that I'm creating should have a binding to a property that will return a view instance, and the CardView will render this view, and will update if the property that points the view updates.
You can see a more full covered example about what I'm trying to do here: http://jsfiddle.net/wilkerlucio/Ztdpb/
Thanks
I think that you need to specify the template as such:
App.CardView = Ember.View.extend({
defaultTemplate: SC.Handlebars.compile('{{App.obj.value}}')
});
or
App.CardView = Ember.View.extend({
templateName: 'sample'
});
If you are planning to have many child views, then you may want to try to use a collection view.
This link is a bit old, but it is still not bad: http://guides.sproutcore20.com/using_handlebars.html
I've also blogged about how it implemented CRUD operations with Ember (SC2) here.
Hope this helps.