As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I have seen some people who refuse to use Interface Builder and prefer to make everything using code. Isn't this a bit tedious and doesn't it take longer? Why would people do that?
This is usually a holdover from working in other environments with other UI builders. A lot of UI builder programs are viewed as newbie hand-holding at best and outright harmful at worst. Interface Builder is unusual in that it's actually the preferred way to create interfaces for the platform.
Some people don't like mixing code functionality in interface designs. Another example is when flash devs would include lots of code snippets directly in the stage (fla files), rather than in separate .as files. With xib it's not as big of a problem, since they are xml and can be merged quite easily when using source control. I personally like using xib's because we have a team of devs and designers -- splitting up the work load is nice. The designers can easily port their photoshop/fireworks designs into xibs and we can focus on the functionality.
Sometimes you want to do something that the UI builder can't quite handle (these situations aren't common, but they do come up now and then). Sometimes you may feel you have better control over what's happening when you write the code yourself. Me, I prefer to let the UI builders do it as much as possible, but sometimes it doesn't always work that nicely, and I sometimes have had to write the code myself.
Possibly because the Interface Builder is another tool to understand. Also, it's useful to know how to do things programmatically in case nibs don't give you enough functionality.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am going to develop an application for OS X and I need some scripting engine for it.
The purpose of the scripts is to receive a text on their input (HTML file in most cases), parse it in some way and return the data to my app. These scripts should be easily editable by the users, therefore they should have some common used syntax like C or pascal.
Can you suggest some lightweight solution for this?
Thanks!
PS. I am new to OS X development, trying to switch from Windows...
Two suggestions:
Javascript, try the V8 engine. http://code.google.com/p/v8/ Very popular, likely familiar syntax to many.
Lua. http://www.lua.org Extremely lightweight and simple to connect. If your script editors write scripts for World of Warcraft, for example, they will know Lua.
In general AppleScript/Automator actions are easy for the end user to work with since the technology includes a GUI for building scripts without much programming knowledge. For experienced developers used to other languages, they can be a bit too friendly/loose and have a somewhat different syntax (more like plain English). The good thing is that they can also call other languages as needed, so a developer familiar with Perl or whatever could incorporate that into an AppleScript or Automator action.
Since you're talking about parsing text, Perl itself would be a good solution - again there's some difference in syntax, but the scripts can be rather compact and the basics of parsing aren't too difficult to learn. I haven't personally incorporated Perl into an OS X app, I've just used it on the command line, so I don't know if there are any pitfalls to that approach.
One additional advantage to AppleScript is that you can make your application itself scriptable so that users could automate the functions of your application into a larger workflow.
I would suggest downloading the free TextWrangler application by Bare Bones Software, or a similar developer's text editor, to see how they incorporate scripting into the application. This may give you additional insight into your approach.
LUA seems to be a good choice.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Recently I have been thinking maybe I should try out Storyboard in XCode.
I have always programmatically done my views in XCode since I didn't quite like the Interface Builder in the past. I wanted to know exactly what was happening in my apps, so I never really used any interface builders.
So I want to hear experiences of people who have used both, advantages and disadvantages.
I like managing all my UIViewControllers programmatically. But when I set up the UIViews, I kinda have to run my simulator multiple times to check if I have placed my view on the right pixel.
So I like the Interface Builders for the fact that I can see where my views will be positioned.
What do you think?
In the apps I have I actually use a combination of both.
If you're used to doing everything programatically then you will probably find it easier to start off with doing separate xibs.
Doing it that way means that any flow of the VCs is still done programatically like you are already doing.
The main advantage that you get from using a Storyboard is that you can create the flow of the app using IB as well as the UI of each VC. Oh, you can also create custom UITableViewCells within the table it is related to also.
Once you have got used to doing everything with XIBs you should find it easy to move on to Storyboard stuff.
Having said that, there isn't a chain of... Code < XIBs < Storyboard.
They should be sued to complement each other.
I've made a few apps using Storyboards and they worked brilliantly. Just before Christmas I started another app and the requirements of the app lead me down a path of explicitly using XIBs and no storyboard at all.
I've also made apps where the majority of the app uses storyboard but then there are certain common places that all use the same VC or all use the same UIView subclass and for those I have created my own separate XIB files.
It really depends what you are doing but either way, if you can do it in code then most of the time it is actually a lot easier and just as powerful in IB.
(with the exclusion of View drawing etc...)
The new StoryBoard interface is quite nice and intuitive. It still gives you fine-grained control however, without you needing to do everything programmatically. I think it is definitely much more efficient, and it might take about an hour to get used to it is definitely worth the time, from my perspective.
For apps that see repeated interface tweaks Interface Builder has been such a time saver for me - especially for projects with picky clients. The learning curve isn't really that steep if you already know how to code the same things manually which it sounds like you do. I'd say go for it and you won't regret it. I haven't.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I just read a comment saying something like
Yet another reason never to use nibs
Is it such bad practice to use nibs to construct your views in iOS? I think it's a fine system, enables you to construct views quickly without writing a lot of code. I've been working with nibs for a while now and never saw much downsides to their use.
So my question is: should I use nibs or code my views, and why?
I think the statement "never to use nibs" is ridiculous. You just have to know when to use them and when to avoid them. They're great for complex but static views, where you would waste a lot of time getting the coordinates and sizes right. For dynamic GUIs of course you should use code instead.
However, some people might fear that the GUI is out of their control, if they don't create it themselves by code and see every detail. But that's a subjective point.
One sure downside is, that xibs are hard to merge if you use source control. Xib files are actually XML files and when you change something in the GUI, a lot of references are added, removed or changed in the background. This will then result in conflicts that are very difficult to resolve.
Another one might be performance reasons. Loading your GUI from a nib file is slightly slower (in some cases) then creating it directly in code. Some people suggest not to use any nibs for the GUI that has to be loaded at application launch to shorten the launch time. But I'm not sure if there is a significant difference or not.
I prefer using NIBs wherever possible!
My reasons are:
Easy to maintain and in need of a change I can view the result right away.
Now that IPhone5 has a new resolution - things were really easy to do in the NIB
Easy to use
Less code to write
I even make SMALL popup views there and set the container view to hidden.
then I show/hide these popup views with containerView.hidden = YES/NO;
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've read a blog post called Blogging with Noir, and I was honestly surprised that the author uses java.jdbc instead of libraries like Korma which I found surprising. What are the advantages of writing SQL queries in your code instead of letting tools do it for you?
I guess it is for the usual reasons that you might choose to use an API directly in Clojure rather than use a wrapper:
Existing knowledge: you already know the JDBC well and know that it will get the job done, why spend time learning a new abstraction unless there is a clear advantage?
Uncertainty - does the library have all the features you need? Will it continue to be maintained and implement new features in the future?
Stability - the wrapper may not yet be mature, so you run the risk of your code having to change if breaking changes occur / bugs are discovered.
Completeness - the wrapper may not (yet) encapsulate all of the functionality of the original API that you need
Overhead - sometimes extra layers of abstraction add a performance overhead that you don't need/want
Extra dependency - adds complexity to your build, and conceptual overhead in terms of the number of abstractions you need to keep in your head.
Ultimately it's a trade-off - the above are reasons that you might want to use the underlying API, but there are equally good reasons that you may choose to use the wrapper:
More idiomatic - a wrapper library is likely to give you much cleaner, more elegant code than a Java-based API (particularly if the Java API is imperative/stateful). You have to admit that Korma is pretty elegant!
More composable - Clojure wrappers tend to adopt a functional style, which leads to easy composability with other clojure code / libraries.
New features - often Clojure wrappers add extra functionality that the original API does not posess (for example, look at the data binding functionality added on top of Swing by Seesaw)
Korma IMO isn't nearly ready to be used as a full replacement for SQL. It's definitely handy, but right now a lot of my queries have (raw "...") snippets in them, and for more complicated stuff all the main querying is done inside SQL views which are then selected on via korma.
The main alternative, ClojureQL, doesn't even work with Clojure 1.3+
In short, it's hard to abstract SQL, and Korma - even though it tries to be minimal, meaning you still have to understand SQL pretty well to use it - isn't finished.
I can think about two reasons:
Almost everybody knows SQL, almost nobody knows Korma
This is a guess, because I do not know Korma myself, but raw SQL is sometimes suitable or even necessary if you want to do something specific like features that are only present in a particular database
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I wrote a simple genetic algorithm to evolve the string "helloworld". I wrote it twice. The first time was written using classes. And the second time was written using just functions where the entire state of the genetic world is passed from one function to the next...to mimic the data flow paradigm. Surprisingly, the code worked well for both the implementations. However, I managed to get it working only after painstakingly removing each and every bug, which was quite a laborious process.
And I asked myself.. there has got to be a better way. Write the code using classes was comparatively difficult than writing the same code using simple functions and I believe writing the same code visually, using something like labview for example would be a lot more easier than writing it only using simple functions.
To that extent, I read about data flow programming and visual programming and quite frankly it seems like it is more natural and intuitive to program in a visual, data oriented manner than in a statement-wise manner, which is what most programming languages enable us to do today. My question is.. if this is the case, why hasn't data flow, visual programming like "labview" become the standard?
I do not believe that data-flow / "Visual Programming" has nearly the performance of well-designed code.
Text-based code can express far more complex and subtle data structures and flows than anything graphical. It gives programmers detailed control over what gets copied, what gets accessed, and precise control over sequences of steps. I have a hard time seeing how data-flow could be that expressive.
Ultimately, data-flow /visual programming can only describe things that are already known. Text-programming (for lack of a better term) actually lets you express more. Programmers can create entirely new data structures and algorithms that simply haven't been represented visually yet.
It is dangerous to use a single problem as the basis for how programming languages should be designed. I'm not sure how the data-flow paradigm would improve GUI framework design, for instance.