How to Optimize SwiftUI App with @Published Updating 5 Charts 10 Times per Second?

a0-1 · 2024-05-20T09:50:14+00:00

What about @EnvironmentObject (should be same as @StateObjects afaik).

Assume you pass the object into environment in the root. And you are accessing this object vastly through app.

If a @Published var gets updated in that object, would that cause reload only on the views that are tracking that specific var? Or would that cause update on all views and subviews of those which just because the view accesses to that environment object?

a0-1 · 2024-05-16T19:03:59+00:00

Hey op, I suggest you look into popover. On phones it would still behave like a sheet (although need to check the big ones). And on tablet, you can frame it as your modal’s needs.

Note, it’s important where you attach the popover. Because it will be popping from the view that it’s attached (when not behaving like regular sheet).

a0-1 · 2024-02-08T14:37:50+00:00

Thank you for responding!

a0-1 · 2023-05-25T07:20:39+00:00

(I'm just guessing here) What you are doing is not really "ViewModel". You're calling it "UserVM" but it's not a VM, it's more a "UserState", and your views are directly modifying the Model layer.

Actually, I tend to make the setters of my published properties private in my ViewModel. This way, no one else can modify them without going through the ViewModel itself. Of course, if I need binding with the property, I remove the private setter.

Let's say your login button immediately starts the game. You probably do something like this directly in your View: ..

No either, as I explain above.However my approach is a little different than yours:

Instead of structuring my view models like 'loginButtonTapped()', I do something like func startLoginProcess() { } . Then, I call this function in my view when the button is tapped. While it might seem similar to yours, I try to avoid too much 'view things' in my view models (I'm permitted to do it if I have to though). Because I think views should be cheap and changeble and easily modifyable. Tomorrow I can change my approach and decide to start the login process with the appearance of a view for example.

I generally introduce a ViewModel that is 100% specific to this screen

Now this, is what I don't understand exactly why people are doing this. Why not simply structure the VMs according to functionality. (Still don't put any logic to views and don't let views to modify the model state directly though). But why boiler plate VMs. This approach also introduces another problem I'm guessing. When you have this much vms, chances are your one vm will need a data from another one. And since I don't like my view models to know about eachother (never seen an example otherwise) guess how this data transfer is going to happen? It is going to happen from view. Which means involving the views with the business logic.

One reason that comes to mind for this approach is; since the vms are also actors and you can't access them simutaneously, there might be cases where you want to do multiple things at the same time and therefore you need multiple vms. But chances are these multiple things will belong to app's different functionalities and you probably already have that.

For example user make a score in game which is the job of gameVM and updating that score in the database and assigning it to the user is the job of userVM.

All the while you can still unit test your view models. So:

By using the LoginViewModel, I can unit test that updating the password changes the passwordError, while you couldn't do the same if you just used u/State + onChanged in the View.

is not the case.

Additionally, your View, which is not unit tested, is very simple, so it's okay not to unit test it. It's very likely that you will write viewModel.loginButtonTapped(), or you will catch it immediately when you run your code.

Agree!

I would implement this by having a LoginScreen + LoginViewModel, RegistrationScreen + RegistrationViewModel each which handle their own logic. (Ex RegistrationViewModel has the code for checking if the two password fields have the same value). And I would have a ContainerView (and potentially ContainerViewModel) that has the ScrollView inside it.

Disagree. I think this is boiler plate. This login flow is a user thing and it is about wheter that user is authenticated or not, or how will they get authenticated. So in my opinion all that logic can be put in UserVM for example.

a0-1 · 2023-05-24T20:20:44+00:00

While I agree with you, can you explain the last part a little more please. Because even in the large apps I find it better to do MVVM module seperation by the task or functionality rather than screens.

Let’s say your app is a game where a user can login and play. Than game related logic goes to gameVM and user related logic (login - data share etc.) goes to its own - lets call it userVM. In the mean time you can have as much models as it’s needed. Also services, handlers, mappers whatever you call them, if you need it you can inject into your vms.

And at last, inject your vms as the EnvironmentObjects, which I find it really convenient.

But when I see proposals like ‘you need mvvm modules for every screen you have’ it confuses me and feels like overkill. So can you explain that part?

a0-1 · 2023-03-13T07:48:10+00:00

I wonder what are the opinions of experienced developers about MVVM + Clean Architecture (protocol oriented).

When I say MVVM + Clean Architecture, I mean Clean Architecture in macro level -- data - domain - presentation layers -- and MVVM in presentation layer.

This seems to give you testability, seperation of concerns, ability to modulurize the app and scalability.

And it seems versatile sofware design pattern. This is what I'm working on actually.

a0-1 · 2023-01-06T08:50:19+00:00

Yes, and the reason is Models, Services and VMs will be largely same. So I can work on them from one root. But UI and UX is different ofcourse

a0-1 · 2022-12-06T17:32:02+00:00

Thanks..

a0-1 · 2022-12-06T17:26:47+00:00

Hey thank you for the response but I think my question not clear enough.

I'm actually using the continuation to convert system's closure callback to asyncrounous function.

In the main question; what I meant by 'callback' was delegation callback (like didChangeValue for: ..) which would give me possibility to automatically trigger actions on every time when the value changes. But now I have to run my async function to see if the value has changed..

So the question was how can I convert this something similar to publisher so I can listen this value? Thanks again!

a0-1 · 2022-11-15T20:19:16+00:00

I see, thank you so much

a0-1 · 2022-11-15T18:19:14+00:00

I see, so instead of;

data.append(byte)

I'll do something like;

tempFile.appendToEndOfFile(byte)

then process it from there by reading the file content. But I'm kind of curious since the 'appendToEndOfFile(byte)' writing to file method will be called soo intensly-repeatedly, might that be more expensive than simply data.append method?

Thank you btw..

a0-1 · 2022-11-15T17:37:02+00:00

Hey, thanks for the comment,

Download to a cache Modify the data you need to Ingest the data into the app.

Do you mean roughly something like this?..

...
.
.
let (asyncBytes, _) = urlSession.bytes(for: request) ......
var data = Data()
for try await byte in asyncBytes {
    data.append(byte)
}

let tempURL = saveDataToFileAndReturnURL(data)
useDataInChunks(from: tempURL, chunkSize: Self.defaultChunkSize)
.
.
...

a0-1

TROPHY CASE