Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
Thanks a lot , I want to know the difference between 'Form Created automatically' and 'Existed Form'
in Delphi XE3. (Tools->Options->Forms)
An "auto-created" Form is created automatically for you at program startup. The IDE inserts a call to TApplication.CreateForm() into your project's main source file to accomplish that. The first auto-created Form becomes the TApplication.MainForm.
An "available" Form has to be created manually in your own code, which allows you to choose when/how it is created.
The biggest difference is the forms, all get created whether needed or not, and all stay in memory until the application is closed (or they are explicitly destroyed).
My delphi experience suggests that using auto create nearly always leads to poor lifetime management and encourages monolithic code, and in general should be avoided at all costs.
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 3 years ago.
The community reviewed whether to reopen this question 9 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am writing some interfaces for my design in SystemVerilog, I have many of them. I was wondering if there are some specific guidelines regarding how to organize them.
right now I have all of my interfaces in one file. I was wondering if I should place each one of them in a separate file or all in one file. And if there are some specific guidelines on how to name the file(s).
Thanks.
Although the answer might seem opinionated, tools are designed with one file per design unit in mind, and the name of the file should match name of the unit. So if the name of the interfacer is foo, the name of the file should be foo.sv This way the tool can search a directory for files without having to specify them individually. The *.sv extension lets the tool know the file is writing in the SystemVerilog language.
Having one file per unit makes debugging easier and simplifies code coverage analysis. There might be other reasons with respect to project management for adhering to one file per unit, but those do get more opinionated.
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
I want to go with Xamarin.Forms project. Now, I am bit confuse for consuming Rest API for this project. Performance matters.
There are many available but can any body please suggest me which should be best for Xamarin.Forms(.Net Standard)?
Microsoft Http Libraries or third party libraries like Refit, RESTSharp, PortableRest, etc.
Please suggest
All of these options are viable. I think the performance differences between these libraries will be marginal. So, it mostly comes down to what you feel comfortable with.
I like to use Refit because it will take a lot of redundant code out of your hands and you just have to focus on the contract. All the code for the actual calls is generated at compile-time (and thus won't impact your performance at runtime).
Also have a look at how well the library is maintained and if it's active. If you choose one that is already inactive for a while, chances are that you will start relying on older software versions which might not be what you want.
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
I know in python it is good practice to have a models.py and put all of an application's model classes in there. Does the same apply to swift or is it better to have a separate file for each model class?
Thanks!
Apple recommends to have separate files for each model class however it's possible to use the "Python style"
Assuming that your project is average..I would put each of your models in a separate file. Sometimes you end up with some small files, but I would rather go through that then some massive file where I can't find anything.
There is no single correct answer to this question, but Swift's system of controlling access suggests that it is not the best practice.
Properties and methods marked private are only visible within the same source file. If you put all of your model classes into a single file, they will all have access to each others' private methods and properties, which defeats the whole purpose of marking something private.
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 5 years ago.
Improve this question
I've seen plenty of posts on the pros and cons of the EF but finding quite hard to find anything on the relationship between EF and project management methodologies such as Waterfall SDLC and Agile?
Would anyone have any links or information on the above? Thanks.
Frameworks and methodologies are typically orthogonal.
The only (indirect) relationship is that Agile methods would have you build your application to be decoupled from the persistence mechanism altogether. In fact, you would delay even using a database until you have a user story that requires that you have one. This would force you to keep the two decoupled, leaving your options open.
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 8 years ago.
Improve this question
Is there a way or a model by which I could create a "Choose your own adventure" type app using UIAlertViews?
While this is not a direct answer to the question, what you're going for here is going to provide a less than ideal user experience. Alerts are jarring and not really meant to be a constant UI element but more of an occasional interruption.
That said, if you do want to do something like this, using a block handler pattern rather than a delegate pattern will make the logic of your app much simpler and easier to follow.
For Xcode5/iOS7, I would recommend taking a look at BlocksKit which includes a category on UIAlertView to use completion blocks instead of a delegate.
New in iOS8 is the UIAlertController class which handles this very similarly without a need for an external component. It does require iOS 8 to use though.