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 going to start a new application in iOS and there are multiple architectures available in iOS i.e Viper,MVVM,MVP and MVC.
I have search google but didn't find any specific use of these architectures.
Can anyone please guide me that when and which architecture should be used and which is more beneficial?
I will try to put my answer in short:
MVC: This is the basic architecture you will find most of the people use. Without knowing this, don't go forward as it's wasting time doing so. But this architecture no one is interested in the current market as it has few drawbacks. When comes to unit testing people find it difficult. So they started moving on. One good thing about this architecture is your development is super fast.
VIPER: which became very popular these days for its separation of data, design, controller logic. For unit testing, it will be very nice. But understanding and putting efforts in this are more. If you fully understand this one, I advise you to go.
MVP: People who understand MVC, can easily go with this MVP. As there are not many changes involved in this from MVC. Presentation logic will be separated out. If you want to build good architecture, not the basic one go for this.
MVVM: It also requires good efforts from you. Don't go until you understood. Again very good separation of model, View, ViewModel.
Now it's your choice to get onboard. As all of us know, how important an architecture is for an app, don't take fast decisions here. Take your own time and conclude based on the time you have in your hands, the need for proper 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 6 years ago.
Improve this question
Is it even worth it to learn all of this Bootstrapping and stuff that just feels like I'm not really doing any work?
I feel like it's a bit cheat-y, y'know?
I showed someone a site I had built and they said it was good, but it didn't work well at all across multiple platforms.
So, I Googled for some tips on how I can make the site adjust to different screen sizes, and every link I went to just listed different Bootstrapping things and plug-ins that'll do it for me.
I want to learn this stuff for myself so I have better control over it, I suppose.
Is that really a good idea, or would it be more worth it to look into Bootstrapping and junk?
I would advocate to learn how things work first, and then use libraries/frameworks to accelerate your workflow.
The idea behind this is that if those tools have bugs, or issues, you'll have a much better capacity to dig in and debug.
Trying to build all of these tools yourself, however, is NOT recommended (unless its for exploratory reasons). These libraries and frameworks exist for a reason, they have many contributors (something you can't compete against as a solo dev) and they solve real-world problems.
That being said, learning how to properly select a given lib/framework for a given use-case is a skill really worth building. And that comes from understanding what problems the libs/frameworks solve, which is the result of having explored "the inner workings" by digging in.
In the end, these tools will greatly accelerate your development speed, which is great, especially when it's business related (your job).
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 4 years ago.
Improve this question
Is there any standard way to build developer, just making the developers understand the code easily after delivering, if you have sample it's better
If you want to know how to make your code better, you need to read about SOLID and other object-oriented design patterns.
There are no official Apple developer programming style guides.
I.e.: no official "Programming Standards" exist.
Standard only exist in terms of UI, external appearance of your application.
Normal software development criteria apply:
commenting
using software patterns appropriately, as pointed out in another answer, SOLID makes a lot of sense. Just in order to understand Apple Frameworks you need to know software patterns: delegation, visitor, proxy, etc.
document requisites and change requests, api and architecture if the app is complex
don't rely too much on bug tracking, these tend to be abused (change requests marked as bugs) and might add too much complexity of their own (JIIRA).
your organization may adopt an existing programming "quality standard" and adapt it to iOS development. ITIL is and ISO are usually overkill.
Sometimes it makes no sense to over-optimize and over-engineer everything, including your code and programming standards.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am looking forward to learning XCODE, what is an appropriate approach to mastering ios programming. I want to know precisely, in order, what I should learn to know XCODE. Since there are different aspects to XCODE, I am confused on where to start. Such as COCOA, objective-C, etc. Can anyone provide me with a solid plan that will give me a solid programming skills with XCODE? Thank You
Start with a good book that teaches you Objective-C with Xcode 5.
Stephen Kochan has a good one.
That will get you going.
But check a few to see what makes sense to you.
Just make sure it has Xcode 5 so you don't get lost.
After you get through a bit with Objective-C you should fill in what you need of C.
C is not hard but it is truly agnostic from frameworks that really do interesting things so it makes learning C first rather challenging.
(Like learning math without any real idea why or what to use it for)
In the end though, expect a long road of perpetual learning. You will feel overwhelmed at times. That's normal.
Nobody knows all if it and the masters have years of experience and knowledge.
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
You can find thousands of questions out there about how you develop software and which methodology is the best one. But mainly these are targeting medium to large teams, with people having different roles and responsibilities.
What I'm interested in is what methodology are you using for your one-man-shows? What steps are you doing, what documents are you creating to get the things you want to develop clear and document it well, to share it with the community?
Especially, I’m interested in the following questions:
_Are you using a structured approach even you’re developing on your own or no at all?
_What phases are you using?
_Which documents are you writing before and after coding?
And if you have “your” standardized approach, can you share templates which you are using?
Thanks in advance,
cheers
Gerry
Personally I think it is a matter of making decisions when it comes to the development process (solo). In my case I wouldn't recommend setting up a massive development process but I would pick elements which prevent problems that I have earlier had. My approach for small applications (in the right order):
Always write down what you are going to make and what you are not going to make (define a scope) - Think of functional requirements (Functional Design)
(OO only) Make a class diagram that displays relations between classes. (Technical Design - Sequence diagrams, while usefull, take up massive amounts of time to make)
Write your program according to what you have just written down (or part of it).
Refactor and redesign your application (once in every X hours, write this one down)
Repeat step 3 to 4 until the result is what you wrote in the Functional Design.
Walk through every corner of your application to find every single path and write this down in a testdocument. Identify possible problems in the paths and test them.
When it comes to big applications however (or assignments for someone else) I prefer using the "medium to large teams" approach. Which almost brings a guarantee that you will not be meeting most problems.
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 8 years ago.
Improve this question
I'm about to start building a Rails app that will eventually need to vary CRUD access by user (i.e. which pages do they see, which can they edit, etc).
Is there a best stage of the development cycle to incorporate this?
Part of me feels like it should be the very first thing, since almost every piece of the interface will in some way rely on checking the user's ID, and it will be an inherent part of the DB structure.
Another part feels that this would overcomplicate things to start out with, and that I should instead build the core parts of the app, then layer on the authentication/authorization later.
Are there any best practices around this sort of thing?
I would say that if your system will rely on some kind of authentication... Why wait?
Let's say that you start developing your application without the authentication layer but at the same time you know that at some point you will have to do it. That means that at some point you will develop the authentication layer, and most likely you will have to refactor what you have already built to adapt it to this new layer.
Also, to try to convince you a little bit more...When you say:
I should instead build the core parts of the app
You should consider that the authentication module might be a core part of the app too...
I prefer to do it early, but you really have roughly the same amount of work in front of you regardless of when you do it. It really a matter of opinion on when you prefer to do it.