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.
Related
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
I'm caching a view's html output. (I'm caching a view response (html) myself without using django's caching framework.)
I need to invalidate this cache in various places.
eg) Suppose I develop StackOverflow (woohoo), and caches its main-page.
I definately want to invalidate the cache whenever a new question is posted.
or new featured article needs to be shown in the main page.
Among other things, I would like to store cache_key for the main page, and invalidate_page (a function) somewhere near main page 's view code.
I could define them separately near main_page view. but just thought it would be nicer for the main_page view to have those constants, methods attached to itself.
I'd like to encapsulate stuff in main_page view somehow as we do with object oriented programming if it's possible.
I only use FBV and thought maybe CBV can help here, but any other suggestion is welcome.
I have an application scheme implemented in Ember that basically follows this layout:
The concept is that the user can interact with features on the Map View (which is always present) and basic navigation occurs between various views in the Parent View and an arbitrary stack of Sub Views. The user can create new features on the map, edit existing ones etc.
The URL for a particular feature could be /features/123/edit
Since input into my interaction panels is very much dependent on interaction with the Map View (drawing a polygon, placing a marker etc.) my controllers for these views are setup to "need" the Map Controller. When a particular panel view is present interaction with the map should affect the panels in various ways.
My question is - how does one scale such tight controller coupling? I essentially need to switch between different Map modes based on which panel is currently active. I also, I believe, need to observe events on the map and act upon such events depending on the current active panel.
I setup a proof of concept where a certain Sub View Controller observes certain properties of the Map Controller (with for example .observes("controllers.map.activecoords") however, such an observer will continue to trigger even after the user has navigated away from the particular Sub view (i.e. as soon as the controller has been initialised). Must I setup and tear down such observers manually (i.e. using addObserver) when entering and leaving the route? Is this the right pattern? I've gotten the impression that requires that I manually remove all such observers during transitions to avoid unexpected behaviour and memory leaks.
Perhaps I'm going about this completely the wrong way? Are there any others patterns that fits my use case with an always present map with different states and intercommunication with interaction panels?
Perhaps the architecture of your application shouldn't be connecting controllers, but rather ask yourself "What is the model here, really?"
In each case, I think the model is your map, or at least its "contents". The features are really decorating the interaction with your central model, which is the map, underlying it all.
So really you have a single model here. You effectively have a map resource, and many feature routes on that resource, viewed from the URL/API.
The question is now not so much "how to manage a dependency hierarchy between controllers?" as "how do I manage a view and a subview on the same model?" which is answered quite simply in the standard ember nested route. Your outer view is always present and it has an outlet which is where your feature goes. How it's rendered is the inverse of how the standard nested route is rendered, but nevertheless it's the same pattern.
So, the TL;DR answer is... go through your model and the routes... use them to talk about your common data: the model is, afterall, your data, and the controllers and views are simply augmenting and enabling the user experience, presentation and interaction of them.
Most of these sorts of architectural problems can be resolved by moving the data up and down the hierarchy (template view / component / controller / route / model) until you find a place which is low enough to still be accessible to objects that need access to it, yet high enough that it makes sense by not being tightly bound with too many things, but still is in the right spot and "feels right".
If it's too high, you'll tend to be doing the wrong kind of work with your objects (ie controllers should not be mucking with view mechanics, models shouldn't really have presentation stuff in them, etc.
If it's too low, you'll tend to be doing too much work with the framework and you'll tend to be repeating yourself a lot... ie controllers will be doing a lot of work to get the data they need, for example.
Background
We use the Model-View-Presenter design pattern along with the abstract factory pattern and the "signal/slot" pattern in our application, to fullfill 2 main requirements
Enhance testability (very lightweight GUI, every action can be simulated in unit tests)
Make the "view" totally independant from the rest, so we can change the actual view implementation, without changing anything else
In order to do so our code is divided in 4 layers :
Core : which holds the model
Presenter : which manages interactions between the view interfaces (see bellow) and the core
View Interfaces : they define the signals and slots for a View, but not the implementation
Views : the actual implementation of the views
When the presenter creates or deals with views, it uses an abstract factory and only knows about the view interfaces.
It does the signal/slot binding between views interfaces. It doesn't care about the actual implementation. In the "views" layer, we have a concrete factory which deals with implementations.
The signal/slot mechanism is implemented using a custom framework built upon boost::function.
Really, what we have is something like that : http://martinfowler.com/eaaDev/PassiveScreen.html
Everything works fine.
The problem
However, there's a problem I don't know how to solve.
Let's take for example a very simple drag and drop example.
I have two ContainersViews (ContainerView1, ContainerView2). ContainerView1 has an ItemView1. I drag the ItemView1 from ContainerView1 to ContainerView2.
ContainerView2 must create an ItemView2, of a different type, but which "points" to the same model object as ItemView1.
So the ContainerView2 gets a callback called for the drop action with ItemView1 as a parameter. It calls ContainerPresenterB passing it ItemViewB
In this case we are only dealing with views. In MVP-PV, views aren't supposed to know anything about the presenter nor the model, right ?
How can I create the ItemView2 from the ItemView1, not knowing which model object is ItemView1 representing ?
I thought about adding an "itemId" to every view, this id being the id of the core object the view represents.
So in pseudo code, ContainerPresenter2 would do something like
itemView2=abstractWidgetFactory.createItemView2();
this.add(itemView2,itemView1.getCoreObjectId())
I don't get too much into details. That just work. The problem I have here is that those itemIds are just like pointers. And pointers can be dangling. Imagine that by mistake, I delete itemView1, and this deletes coreObject1. The itemView2 will have a coreObjectId which represents an invalid coreObject.
Isn't there a more elegant and "bulletproof" solution ?
Even though I never did ObjectiveC or macOSX programming, I couldn't help but notice that our framework is very similar to Cocoa framework. How do they deal with this kind of problem ? Couldn't find more in-depth information about that on google. If someone could shed some light on this.
I hope this question isn't too confusing ...
Ok the technique I found is actually coming from Cocoa, so it's objective-C but you can definitely do the same in C++.
The solution is simply to use a PasteBoard (developer.apple.com documentation).
In the hope it helps someone ...
The whole point of an MVC framework is to separate design (templates) from logic (controllers). However, template languages often afford a limited degree of "design logic" to occur. This includes basic if statements, loops, filtering, etc.
I've created a Django template tag that can take any list or QuerySet and "pagify" it. It splits the list up into pages based on a specified page size then adds the pages into the Context. The usage is as follows:
{% pagify articles by 20 as pages %}
I can then call a separate include to iterate over the pages and produce a nice list of pages wherever I needed it.
This seemed like an optimal way to do it because it allowed me to page any list in the context; I didn't have to rely on the controller to return paged results. But a colleague argued that this seemed like too much logic for the template. I thought this still fell within the realm of design-based logic since the page would still function even without paging, and determining page size feels like a template responsibility.
My question, is this too much logic for the template? or is this a clean way to be handling this?
It's always been my understanding that the view isn't supposed to be devoid of logic. It's just supposed to be devoid of any controller logic. Paging just has to do with how the data is displayed which is exactly what the view logic is supposed to contain.
Put it this way; what if you were using your data model in another medium, say, not on the web but via some kind of console-based application or background task? Wouldn't it be nice to be able to get "pages" of data through a controller (or manager) rather than having to somehow rely on a template to do this work for you?
While I'd certainly agree that the "look" of the paged data should be handled by your template, the "act" of paging should be left up to a controller (Django view) or even through some kind of custom manager (models.Manager) method.
The view should not contain business logic or navigation logic. What you are describing is presentation functionality (carefully avoiding the l-word here), which can be placed in the view layer.
You may want to check out django-pagination, which provides a similar template tag.
I agree with your colleague; the template should be fed paginated data rather than performing the pagination. The key question, I think, is whether determining page size is a template duty, and I don't think so; I'd say it should be handled at a higher level.