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 started developing for ios in a new company.
Here they taught me to never use iterface-builder, saying it's hard to maintenance the code and it have a few limitations.
Using interface build for java application in netbeans i see a lot of "bad code" but i don't see it using IB, besides i see a lot of IB codes on the internet and only a few codes without it.
So for a large where no one is a beginner on ios development is a bad pratice use IB?
(Let me mention in advance that I have strong objection against using Interface Builder, for a number of reasons I will explain)
Here they taught me to never use Interface Builder, saying it's hard to maintain the code and it has a few limitations.
This is only partially true. The principal reason I don't like Interface Builder and Xcode in general is that a lot of beginner programmers think that it is the only way for developing iOS/OS X apps. They have never heard of gcc and clang, they don't know what the compiler and linker error messages mean, they can't use make, and they have no idea about what the difference between the Objective-C language, the Cocoa (Touch) APIs, the IDE and the compiler is.
After all, they start using Interface Builder and Xcode with all of its quirky and sometimes strange/illogical features (and bugs as well), but when they're in the need of developing something non-obvious, they don't even realize there is a method for, for example, creating views and view controllers programmatically (yes, I've seen this very question on StackOverflow).
So, when abused (or rather, used too early), Interface Builder and all of the "convenient" features lead to programmers learning bad concepts and missing some important pieces of practice and experience.
However, if you're a senior developer, who has all the necessary skills, and you feel you could write an entire application from scratch, using just a simple text editor and a Makefile, then you are by all means permitted to use IB, and even encouraged to do so if you feel that's more comfortable than hammering out code.
So, to sum up:
Using interface builder is really a bad practice?
No. Rather abusing it and not making the effort to learn the programmatic approach to UI stuff is bad practice.
Post scriptum: I have quite a lot of experience with iOS development, but I still find Interface Builder rather inconvenient and inconsistent. I generally use code for everything. But that seems to be my personal preference. One advantage is, however, that if one creates everything by code, then another programmer without access to these Apple-specific tools will be able to contribute to the project as well. This is a point where the "it's hard to maintain" part comes true...
For example, until I didn't have enough money for a Mac, I used Linux for developing iOS apps (yes, that is actually possible). I couldn't use IB and Xcode, yet I have done loads of applications and tweaks (for jailbroken iOS, of course), and that was just fine.
Post scriptum #2: another reason for avoiding the use of IB could be the need for dynamic UIs. If you heavily rely on animations, custom UI elements, etc., it's hard to do everything in Interface Builder. Last summer, I had to rewrite a login screen of an application, and honestly, I don't know how I could have realize our designer's ideas if I had had to use Interface Builder. The UI/UX was so dynamic and it had so many ways to change that it was absolutely necessary to have fine control over each and every pixel. And that's something that code is better at than IB.
I strongly disagree with the idea that IB is a bad practice. Interface Builder has the following advantages over code:
when working with complex (and even simple) graphical interfaces, IB cuts the code down to a mere fraction - for example, simply creating a button in IB takes a few seconds, whereas in code, that translates to dozens of lines, especially if the button is to be styled
using autoresizing masks for supporting multiple resolutions and devices is a breeze - this is important as Apple is now pushing towards resolution-independent apps
changing/tweaking properties of views is a matter of a few clicks rather than lines of code, especially if working with images
However, there is one disadvantage (that comes to my mind):
it can hard to pinpoint what might be causing a graphical problem, since it will be hidden away in in the IB file than in the code
Absolutely not. Interface Builder is a really powerful way of creating UI really quickly. Especially with Storyboards it allows you to make functional apps with very little code.
The issue of it "creating bad code" is rubbish as the IB doesn't create any code. The files it creates are essentially XML files that complement the code that you write.
Most of the apps I've developed have been mostly started on IB.
Obviously, you can't do the FUNCTIONAL stuff of your app. I.e. you can't tell a button exactly what to do. But you can point it to a function that you have written and get a working button with almost no code.
Most of the UI in iPhoto on iPad and iPhone is written in Interface Builder.
Much has been said, but I am still going to give my 2 cents for this discussion...
Until some point I agree with H2CO3, it's better to understand what's going under the hood, than keep using shortcuts to achieve something. That works most of the time, the thing, and that's where I strongly disagree with H2CO3, is the following:
Most of the people that use a technology (C#, Java, HTML, iOS, etc), they use it because their Company needs them to use it, because someone else is actually going to pay you to work with that. And not because you actually woke up in the middle of the night and suddenly had the urge to learn C.
If someone asks you tomorrow to create an iOS App and you never developed for iOS before, I truly doubt you are going to create an App from scratch without using XIB's or Storyboards (Which I hate btw).
What H2CO3 proposes is a utopia... Where you really understand what is going on beneath, but because you are such a "leet", you are able to use shortcuts, like XIBs. Well, things don't work that way, and sooner or later you will have to do some shitty thing to deliver something on the next morning.
I prefer, and that's personal perspective, to use a XIB, than to use the first 3rd party library that comes in front of me. And I think that's more reasonable than doing an interface by hand. I prefer to understand the code, and do it by myself, than using for instance a library to help me download/upload stuff.
For wrapping this up, my advise to the person that asked this is:
Try to understand why things are done the way they are. Above all, try to be a better programmer in each new project that you face. If something new comes up (new iOS version) spend a day or two to see what's new, and what could you use. XIB's are perfectly fine to be used, but spend some time creating UIView's by hand, so you can see all the flexibility they give you. And above all, run away from Storyboards (^^)
P.S: A senior developer it's not just a guy that has a "better Kung fu than you".. It's more than that.
Related
I’ve started with the App Development with Swift a few weeks ago. I liked it because it was a mix of Swift and Xcode and UIKit.
I studied C and C++ in uni and I also had an intercourse with C# that gave me some kind of an idea of an interface builder. In no ways I dived deep into it but it was C code, and it was quite clear how to edit and do stuff in code.
The problem is, the book mentioned above does not explain anything about UIKit or Storyboards in depth. But more like at all. You are editing classes, you are writing functions that magically get called at certain events, but most of this is invisible. It just works (but it’s not a positive thing here unfortunately). I have no idea how to do these things programatically.
UIKit is complex and I find it a quite confusing. It seems to go against the basic coding that I did before in C (terminal stuff). My minimal C# experience gives me a few ideas but that’s just not enough.
Is there any good place where I can start off? Swift is fine, so I’m not really interested in that.
First and foremost, if you're serious with iOS development, I strongly suggest you get a hold of this book, it's really worth the money.
http://shop.oreilly.com/product/0636920055211.do
And to your questions:
UIKit is a built-in framework in iOS, in which important UI elements (Views and Controls) are implemented.
XCode is an IDE just like Eclipse and Visual Studio.
A storyboard itself is where you implement the the UI of your app (which can also be done via coding). Storyboards offer many powerful tools for you to conveniently design your UI visually, and see how the screens in your app looks like.
I know a lot of questions have been asked about VB6 migration (and I've read most of them), but I'm still not entirely certain on what the best way to go about this is.
We have a client that we built an order tracking application for about a decade back and they came to us this week saying they were having some issues with it. The app was written entirely in VB6, which has been something of a hassle as tracking down the necessary tools to work with a project so old took some considerable effort. In an effort to make any future maintenance less of a headache, my boss wants to pitch the idea to them of updating the app to .net and wants to know what exactly that would entail. I've never done anything like this before, but what I've read (both here and elsewhere) suggests that Microsoft's "auto-update" from VB6 to .net simply doesn't work very well and I'd pretty much have to rebuild the app from the ground up.
To get to the crux of my question: is this the case? Would I pretty much just need to rewrite it, or is there another means of going about this that could/would save me a lot of time/effort?
Any insight would be greatly appreciated.
VB6 and VB.NET are radically different. The syntax has changed, and so has the underlying structures, forms, custom controls, and almost every single aspect you can possibly think about.
A complete redesign and reassessment of needs and functionality is imperative. With .NET the plethora of new libraries and features supersede the antiquated VB6 libraries, OCXs, etc. Also if you feel bold, you can migrate your code to C# and other CIL languages aside from VB.
Out of hand, the Microsoft migration tool will not do much. Moreover, it also depends on whether you have your business logic well separated from your GUI. Otherwise, it will make it even harder. Depending on the size of your application, it might make it quite expensive. Another possible solution you might consider is to run your app in a virtual environment or on a remote app http://technet.microsoft.com/en-us/library/cc730673(v=ws.10).aspx that will ease the deployment pain.
I have also researched this topic.
Try the smart rewrite solution that converts 95% of the code automatically.
first, run your app through the assessment wizard to determine estimated costs and resources needed.
http://visualwebgui.com/Gizmox/Solutions/InstantbCloudmoveb/tabid/744/Default.aspx
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We want to develop an application for iOS and Android smartphones. We are mainly using Microsoft technologies for developing our applications. We thought that if we would use MonoTouch and Mono for Android we would only have to maintain one code base with only a different UI layer for each device.
Because currently nobody in our small team ever developed a smartphone application and we need it quickly we want to outsource it. We asked other companies whether they perfer MonoTouch or Objective C for iPhone development. Most of them said, that the would choose Objective C. They said that Objective C offers more functionality and possibilities, it's faster and for MonoTouch there is a chance that Apple will not support it anymore in the future. Is all of that true or are there other reasons to prefer Objective C? I know there are other threads like this around, but they did not answer my questions, especially the one regarding Apple's support for MonoTouch.
applications. We thought that if we would use MonoTouch and Mono for
Android we would only have to maintain one code base with only a
different UI layer for each device.
this is a possibility IF you structure your app right. If not: no.
If you use Java+ObjC+C# (for WP7 / Win8 metro etc) then this is not an option AT ALL
Because currently nobody in our
small team ever developed a smartphone application and we need it
quickly we want to outsource it. We asked other companies whether they
perfer MonoTouch or Objective C for iPhone development. Most of them
said, that the would choose Objective C.
If you are outsourcing it, you should dictate what you want it written in, surely? If you need to support it in-house, and you only have C# skills, then MonoTouch etc makes more sense for you, the people paying the bills!
They said that Objective C
offers more functionality and possibilities,
FUD, and also incorrect. Monotouch has the full API available. If it's not there, as Xamarin to bind it (which they have done often before)
it's faster
I'd love to see the benchmark. Yes, technically, it can be faster in some circumstances, but in general use, MonoTouch the same or quicker.
Programmer error is a more common cause of iOS app performance problems. eg not getting things off the UI thread (which is easier to do in MonoTouch than in ObjC, tho blocks have helped that a lot), or taking too long to get out of FinishedLaunching (the "main" method, if you will, tho it's not really...)
Garbage collection and things like linq, xml/json parsing, generics and collections are also hugely valuable, and very quick.
and for
MonoTouch there is a chance that Apple will not support it anymore in
the future.
yes, there is a chance. There is also a chance that Tim Cook will run off with Apple's billions and buy all of Hawaii (rather than Larry Ellison's "I'll just have this island" purchase). But the chances are now rather slim.
Is all of that true or are there other reasons to prefer
Objective C? I know there are other threads like this around, but they
did not answer my questions, especially the one regarding Apple's
support for MonoTouch.
Apple doesn't support MonoTouch. Xamarin does, and they do it exceptionally well. Apple doesn't support anything except XCode, which is their product.
Apple DOES allow MonoTouch apps (there are lots). Another way to look at it: usually, 95% of the top 100 games are written using Unity3D, which is based on the same techniques (ahead-of-time compilation of C# code and embedding a cutdown version of the Mono/.NET framework).
There ARE reasons to prefer ObjC which would be:
You already know ObjC and CocoaTouch and like it.
Your team already knows ObjC and CocoaTouch or you can easily hire people who do (note: currently, as far as I know, iOS developers are CRAZY expensive to hire, if you can get them)
You need to use the beta's the day they come out. Keep in mind that you can use the current MonoTouch and deploy to your iOS[REDACTED] device with the beta on it. You just can't use the new stuff in iOS6 YET (Xamarin said "around 2 weeks" which should be about now...). Also keep in mind that you can not deploy an app to the store which is built with the beta SDK, even if you don't use any of the stuff in it. You can't even mention iOS[REDACTED] in your product description (I've tried)
you love [squareBrackets andTheOccasional:#"strange syntax things"];
Now, will building a cross platform, shared code app be an easy undertaking? HELL NO. It's a very complex piece of development for a non-trivial application. But thats the fun part of software development: if it was easy, it'd be boring! Grab Greg Shackles book ( http://www.amazon.com/dp/1449320236 ) to get an idea of whats needed for iOS+WinPhone+Android style development.
My hunch is that the companies you talked to simply are used to using Objective-C. That's where their skills lie, and that's the biggest reason why they would prefer not to deviate from their path. The other reasons can be argued both ways.
It's true that no one can predict what Apple will do, but there's a very small likelihood that Apple will ban third-party toolkits & APIs like they did in the summer of 2010. That was only a short period of time, and they completely reversed that decision. Their current focus is on making app development easier, which means keeping the field open to alternative development methods. I think MonoTouch is safe.
As for speed, C# generally produces very fast executables. They may not be quite as fast as Objective-C, but I doubt you'd notice a difference. I remember seeing a website somewhere that showed C# outperforming C/C++ in some tests, but that was in the .NET environment, not Mono... and unfortunately I can't find the reference anymore. I'll keep looking. But the bottom line on speed is that C# speeds are very good. It's not like BASIC vs C. More like Java/JIT vs C.
C# gives you many, many(!) advantages over Objective-C, and they have been enumerated in other Stack Overflow answers, so I won't repeat them here. You can find them easily enough.
I'm an obvious fan of MonoTouch, but I do have to say one thing: I think it's a mistake for companies to think that because they are fluent in C#/.NET that they will easily be able to develop and/or maintain iOS apps using MonoTouch. It's just not true, because MonoTouch is basically a C# layer over the CocoaTouch API, meaning that you have to learn the Apple way of doing things. You have app delegates and view controllers and all the UIKit stuff. There's a real learning curve there. But if you're fluent in C#, MonoTouch will be a huge help.
UPDATE:
I found the article on C# speed: Head-to-head benchmark: C++ vs .NET
I have actually used MonoTouch for every app I've ever developed. Performance has never been an issue, and I can't imagine how bad for me it would have been using Objective-C. I've had 2 top 10 apps in the US app store: "Draw A Stickman" and "Draw A Stickman: Episode 2" (don't worry we are working on more).
If you know C# and .Net your gains in productivity are going to be massive compared to what would happen trying to learn Objective-C. I was a C# .Net developer (Windows only) prior to iOS development and the transition to MonoTouch is great.
If you like Linq, parsing XML in fewer than 100 lines, garbage collection, generics, simple multi-threading, and no weird square brackets, MonoTouch is for you.
I use both Objective-C and c# (MonoTouch & Droid), and I really like both. When I'm coding in c#, there are plenty of features such as Linq which I'd love in Obj-C, & when I'm coding in Obj-C there are plenty of things I'd love to have in c#, but I adapt to whatever I'm coding in quickly enough. Re performance, I've detected no difference at all, even for fairly graphic-intensive stuff, so I wouldn't use that as a reason not to use c#.
I think it's ultimately down to what you're comfortable coding in, though of course with a well designed cross-platform project, you CAN have fully cross-platform core code if you use Mono, and you'll only have to do the UI stuff in a platform-specific way - when it comes to this obviously you'll need to know the native stuff to get your UIs working in a way which is appropriate to the platform and familiar to its users.
We have a line of business app that uses MS SQL as a data store, and has WinForms and web UI's. It integrates with our windows mobile 6.5 and tablet apps with web services. All c#.
We've fully committed to MonoTouch after some experiments in Objective-C and HTML-5 (we had working prototypes): we get to re-use our business logic, and we're comfortable developing new code in c#.
Our business logic is constantly being enhanced, and these enhancements are immediately visible to the mobile app - without having to replicate the logic in Objective-C or C++.
Our main issue is finding a c# programmer who's comfortable with the iPhone and iPad UI's.
MonoTouch is stable and we've encountered no limitations (we're binding to the same iOS API that Objective-C binds to). During our learning curve, we've had question, bumped into bugs and have had some misunderstandings - but the support from Xamarin is superb.
Performance has been a non-issue - our app is snappy even though it's doing a lot behind the scenes.
No body can tell you for sure what will apple support and what it will not support in the future, however apple had some issues with mono in the past, and since history tends to repeat itself, then it may be a possibility of that to happen again
Having said that, always go with the native application development SDKS and environments, it will be more flexible, and it will be updated real time, and performance will always be better in the native
I am a total beginner in iOS development. However, I've done Java, PHP and Javascript at work for severals years, so I am pretty experienced with OOP and design patterns.
Xcode 4.2 adds the new storyboarding capability for laying out interfaces in iOS 5.0. Is storyboarding simply a wizard for beginner developers or does it have advantages for more experienced developers as well?
My coworkers and I (both beginners in iOS development) are debating whether one should learn and program iOS using traditional NIBs vs storyboards. What are the advantages that storyboarding provides over previous ways of laying out iOS interfaces? Are there disadvantages to this approach?
Learn the old way in case you have to do both (or read some legacy code). This goes for Arc too; I shudder to think of new Cocoa/Cocoa Touch developers not understanding the old managed memory model.
I think the automated and convenience methods will always cover the "common" cases, and that story-boarding is an example of that. A convenience which greatly simplifies and accelerates the development process. However, there will always be cases where these methods do not provide you with all you need in a given, unusual situation. Just like using the UI elements does not stop developers from going under the hood with core graphics, core audio and so on when they need to. It is definitely, I think, a part of the future of iOS development, but only being aware of that part would be a handicap. So would not being aware of it.
I, personally, dislike automated tools. I have no idea what happens below, what sort of surplus code is inserted, the style of code is not mine and hence I need to work on another person's code. I'm the one that needs to support it for rest of time, not whatever automated tool I may have used.
It is all the tedious abstractions that will help you understand what is going on, especially when you are new to a field.
I'm personally like the traditional nib file approach, where I have more control over its behavior programatically and not having to hack the stroyboard backward to get things done. And of cause, if you have few developer working in a project, it's always good that you don't have to spend time merging changes (since you have several nib file compare to storyboard file)
storyboard files seem to be more readable than xibs.
both are xml files but the xibs seem to have unnecessary baggage and complexity.
I have compiled a list of about 15 reasons against using Storyboards: When to use Storyboard and when to use XIBs
Also, here's a tool that takes some of the pain away: http://github.com/jfahrenkrug/StoryboardLint
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.
As I'm riding the wave of resurgence of Smalltalk (especially because many Ruby-on-Rails people are rediscovering Smalltalk and seeing Seaside as their next upgraded web framework), I get questions like "yeah, but how do I use my favorite editor to edit Smalltalk code?" or "Does Smalltalk still insist on living in a world of its own?".
Now, having first experienced Smalltalk back in 1981, I don't understand these questions very well. It seems rather natural that I'd want the editor and debugger to be savvy of my current code state, and integrate with the change control system that is Smalltalk-aware. Using an external editor or debugger or change control manager would seem very awkward.
So what is it that scares you the most about not being able to edit the five-line methods in Smalltalk with your favorite editor, or use your favorite non-Smalltalk-aware change control system?
Everything's different. Want to go to the end of the line? It's not Ctrl-E. Want to jump a few words over, by word? It's not Meta-F....
Text editing is a fundamental programming activity. Messing with those inputs is messing with something deep in my mind.
Edit: and here is someone asking for emacs key bindings on comp.lang.smalltalk in 1987.
The only Smalltalk I've spent any time with is Squeak, so my views may not apply to other Smalltalk environments.
What concerns me about the image-based approach is that, while you have wonderful things in the Smalltalk environment, it is a walled garden that makes it difficult to interoperate with anything outside that environment. For example, what if I want to use external tools like Yacc and Lex? What if I want to use some C or Python programs to generate Smalltalk code? What if I want to mix Smalltalk in with a bunch of code written in other languages, editing code in all those languages in one editor and keeping it all stored in the same source-code tree?
I'm sure it's possible to deal with all these issues by having your Smalltalk environment invoke system functions to control external tools. But how easy is it to let external tools control your Smalltalk environment? In other words, what if I want Smalltalk to be just another component, rather than the master of everything?
Nothing scares me in particular, but I found working out the API's in VW a bit of a chore, even when I had used other smalltalks. The effect of the browsers is that you tend to see the API's a little bit at a time and quite often it's not immediately obvious where you should look for particular functionality.
Smalltalk also suffers a bit from the paradigm shift to understand how it works. When I was doing my bachelor's degree at university (some time after I had first encountered Smalltalk) I got to enjoy a bit of Schadenfraude watching everyone else in the class getting over the initial paradigm hump as they learned the system (Squeak) for the first time.
I think the combination of the paradigm shift and functionality being somewhat buried in the class libraries makes for a bit of a steep learning curve. ST had a reputation for a fairly steep learning curve to really come up to speed - most of this is due to the large class libraries and the fact that most of the language functionality is buried somewhere in the libraries.
Also (and sadly), Java came along in the mid 1990s and grabbed all of the mindshare. The major Smalltalks have either died completely or been sold off to niche players. It's quite Ironic (in a happy way) that Ruby has served to re-awaken interest in Smalltalk but the lingering perception of 'also-ran' obsolescence doesn't help.
See This post of mine for some pontification about the merits (as I see them) of getting heavily involved in Smalltalk in this day and age.
I would be quite happy to go back into Smalltalk if the opportunity were to arise.
The one big show-stopper for me is that code I write one Smalltalk VM is STILL, after all these years, not compatible with other Smalltalk VMs.
I understand why that is: the core of Smalltalk is an extremely small set of axioms and keywords. This means that after 30 minutes of learning Smalltalk, you're already learning the API library rather than the language itself. I like that approach to language design.
What it all boils down to however, in the Smalltalk world, is that unless a consensus is reached between all VM vendors to have a common base Standard API, my Smalltalk code written for one VM is almost certain not to run on other VMs when I decide to switch.
This also has the corollary of obsoleting part of my knowledge of the space when I switch VMs.
Note that I have barely tried Smalltalk in my life. I'm far from being an expert. This understanding comes from speaking with James Robertson about a month ago.
Another point I'd like to make is that Seaside does in fact run on most popular Smalltalk VMs. I wonder how much of (what should have been) a Standard API they had to build for themselves to achieve that feat.
With all that said, I always have an ear out to hear more about the state of Smalltalk. I do want to try out Smalltalk's very powerful development environment (and its other goodies).
I know it's late but the biggest annoyance for me is that there is not really good editor in none of the smalltalks. It's a thing I can not understand. Working with text is so essential and that less "supported"....
It's always this just staring at one method and then you need to have some method finder or another browser around just to check another method. This is what I really dislike....
While the restricted Smalltalk environment made things like relying on a database driven source control system possible at times where other languages still struggled with having a proper editor, it makes integration very hard in todays times.
With tools like Eclipse or Team Foundation Server you get so used to having all tools integrate with each other. E.g. if a requirement is created, it is automatically linked to the change sets that the programmer commits to implement that requirement. This "boundary breaking" between formerly different tools is nearly impossible in the Smalltalk world, but with bigger projects, bigger teams, higher levels of abstraction and so on you need tools which are more than a fancy editor and help you throughout a full software development life cycle.
No useful support for navigating with the keyboard, or supporting platform UI behavior.
While it's true you don't really need an incredible text editor for (well-written) Smalltalk, being able to move around the environment while keeping your hands on the keyboard is quite useful (and in my case, essential to reducing RSI). I just was trying VisualWorks' inspector and the arrow keys didn't even work properly to move up and down a list. When I hit the space bar, I got a walkback. Sigh.
For the Windows world, there is nothing like Dolphin Smalltalk. The IDE is fantastic. Another quality product if you want to try is Visualworks, it works well, has a very fast VM and the documentation is pretty good.
I've used both in the past, there is nothing to fear.