Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 days ago.
Improve this question
I am writing a SwiftUI app and am having a hard time understanding the best architectural pattern to go with. I know MVVM is the go-to in mobile development in general, but have also seen sources that say that swiftUI has MVVM built in, so all that is needed is MV. Here is one such source: https://developer.apple.com/forums/thread/699003. This and many other articles say that using swiftUI with MVVM is redundant.
I've also seen other sources that say MVVM is just fine for swiftUI.
Is it just a matter of personal preference? Or, is explicitly defining viewmodels redundant in swiftUI?
Should you factor out the logic that adapts your data model for use by your views? Sometimes.
Do you need a four-letter initialism, a rigid process, or a slew of wannabe-influencers and pundits telling you how to do it? Rarely.
Keep in mind that MVVM was designed specifically for Windows Presentation Framework. If you're looking for an app architecture designed for SwiftUI, try the Composable Architecture.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I started build an e-commerce app that allows people buy one item by turn. However, I don't have deep knowledge about Flutter app architecture to follow. The app will get all data from a server and will persist only basic user data in the mobile device. I want to know which are the patterns and architectures (state-management) to study and apply considering that I am a beginner in Flutter.
I think that your question is pretty subjective as it could have as many answers as State management libraries+architectures exist in flutter.
But I would step up and recommend something like shown here.
The architecture uses Provider + ChangeNotifier which is recommended by google, and to me personally is both a simple and powerful approach.
You might be advised to use Bloc , which is indeed good too and also recommended by google here but in my opinion more complex for beginners. And there is nothing you can you do with Bloc that you can't achieve with provider.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
In general, do you feel that Combine has developed enough that it can replace Cocoa Bindings?
I want to create a data model that is totally based on Combine #Published properties and attach it to my view controller and view with Combine.
But before I spend all the effort, I wanted to get you all’s thoughts on potential pitfalls or considerations I should be taking into account. Should I just stick with tried and true Cocoa Bindings?
Thanks!
Cocoa Bindings are great but they only work on macOS. Apple has signaled in multiple ways that the future of their frameworks is cross-platform (SwiftUI, Combine, etc). Combine is going to enter its third year soon. I'd say it's still early, but not too early.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am studying the current architecture of uber rider app and I got to know the current rider app was evolved from MVC to a specific architecture called riblet, which is designed on top of viper by Uber themselves. As I understood riblets is independently testable pieces that each have a single purpose. I'm aware that the new architecture is capable of handling performance and scalability. I am interested in knowing the cons of riblet architecture.
Okey. I found some cons of the riblet architecture. I will post them here to discuss with anyone who is interested. The main cons are as follows,
Since there is a higher number of independent riblets communicating through their interfaces, there is a probability of failure of a particular interface compared to a system with fewer components.
Yes testing a single riblet is easy yet it makes integrations and handling the requests among riblets more complicated.
Changing the technology stack in the long run is difficult
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I wish to make an iOS application that includes a document library, log/journal, forums, possible randomized quotes ?and coaching tools?, and have built applications of that size in other contexts but this is my first iOS application.
Right now I'm working through http://www.raywenderlich.com/1797/how-to-create-a-simple-iphone-app-tutorial-part-1 , and I'd welcome comments on other tutorials, but I wanted to ask: does it work to work out the logical gears of an application before developing the graphic design? I would like to have somewhere between a Dirtylicious and Nature look, but my natural bent (no pun intended) is to get most the gears working and then defer most of the design work until after the gears. I expect they should not be completely separated, and there are cases where you apply the design and then realized that what the gears are doing only looked good on paper, but I wanted to do a sanity check on whether it makes to look up tutorials appropriate to a document library, a log/journal, forums, etc. and get them to work together first, and then skin it.
TIA,
It is recommended that you follow the MVC pattern, which strives for separation between layers.
http://developer.apple.com/library/ios/#documentation/general/conceptual/devpedia-cocoacore/MVC.html
Xcode helps you implementing that pattern.
I think you should try to put in "paper" everything you want to do, before doing any actual coding, check how many views you are gonna have, what you need, the flow between views, try to diagram everything, that will save you a lot of pain later. You don't have to be so specific about the GUI at this stage, you only need to know what kind of visuals you need in the views, (buttons, labels, etc...)
And yes, I think you're safe doing the Model first.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I maintain an app for my business and am pretty much self-taught on code. I understand all of the structural code, and everything is perfectly usable. My problems is with the overall boringness of the looks. Everything is stock iOS from buttons to backgrounds to pinstripes on the list view. Does anyone have any guides or tutorials they used to take a stock iOS app's look to something like the Piictu app? (I'm not looking for something that impressive but in between that and stock iOS; and I'm open to a full app re-start.)
Almost all of controls can be customized with the view properties. and also there are lots of fully customized controls published with its source code.
With iOS5 there is a lot more scope now for customisation of UIKit elements. However, where this is not custom enough for your design then you would need to write your own controls rather than only using Apple'. There are a few good ADC videos on this.