I am hoping that someone could help answer my question.
Problem
I am looking at developing an iOS application that compromises of smaller portions/functionalities (lets call it mini apps just for understanding better). I am looking for guidance on how I should approach this problem to ensure that there are no potential errors in the future. Just to give you a background of my problem, I will run through some of my approach.
First Approach
My initial approach was to develop and release a bunch of apps that can talk to one another. But since iOS apps can only inter-communicate with URLScheme, and which is not sufficient enough for me, I decided to revisit later and look for better solutions.
Second Approach
I also looked at making the apps have a common local database, but since iOS apps are restricted only to their sandbox, this again won't work.
Third Approach
The third approach was to have an app talk to a webService and back again to the other app.
Current Approach
So instead of having a bunch of apps installed on a device that can talk to one another, I am now looking at going with the approach of having only one master app that has different portions/functionalities.
My problem is figuring out how to properly manage my files that are specific to the different portions/functionalities/mini Apps, so that I could independently push a portion updated files to the app and not have it corrupt the other portions.
Would it be a good idea to create a subfolder in the app Document directory for the different portions of the app? Are the other approaches feasible?
I am looking for your help, approach and feedback in tackling the problem.
Thanks
I am working on an App which uses UITableView and Animations extensively. It is becoming really difficult to write effect unit tests.
The view-controller concept in iOS is making the isolation of logic tough. This calls for lot of mocking/stubbing and I feel the Bacon framework(stripped down version of RSpec) for testing is not well advanced for this.
Basically, I could not find any iOS apps which are test driven for reference.
I am really wondering how to separate view and controller logic and effectively test drive it.
Any suggestions?
Have a look to this article and this one. Maybe you can get some ideas from them.
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.
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
I've been implementing areas, but have found that it instantiates a development server for each area when it launches Cassini.
Is this really necessary? MSDN is having me setup these areas as separate web apps, Why can't I put them into class libraries?
Yes, you can get them down to class libraries. You may want to look into what the guys at MVCContrib are doing. They are calling it portable areas which gives you the libraries that you were asking for. They use their own Embedded view engine to get the views back out of the dll. Here is the link that walks you through the process.
After much research the answer appears to be "not yet". We're still in a preview release of ASP.NET MVC v2 so I've decided I should back off until they feel really good about it.
I thought I'd jot down my experiences for those of you interested in modularizing your ASP.NET MVC projects.
Currently, whenever you do a build it basically copies all of your child projects (created for the areas) into the parent. Which works after a build HOWEVER, once you make a change to your views in an area, the change doesn't show up until you rebuild. This one hurts agility and I know the team is looking at it now.
Because of this "disconnected" project structure, you do get some flagged issues (lost intellisense) in the view which we just typically ignore (like script references etc). Just remember it's one application in the long run.
Also, the issue with that posted above. You will have seperate dev instances when debugging but it deploys as one application.
Overall, there are options to "home grow" your own modularized solution (much like CWAB did) but I'd urge you to wait for the next "supported" preview. I feel really good about this team and their abilities. Perfecting areas will really make us satisfied.
In case anyone stumbles on this because they are still building Areas using multiple projects, you can definitely do this within a single project in MVC 2. With the single-project method, you get only one running instance when you start it up locally. There is an MSDN tutorial that can walk you through single-project Areas, but watch out for their area registration bug when you start unit testing it.