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.
In a small team where everyone is coding away on a project for a little while I want to encourage some different thinking to keep people increasing their iOS knowledge as well as to get a bit more variety in their daily activities. I'm not looking for interview questions involving manhole covers, nor very specific questions about whether drawRect: is part of UIView or UIViewController. I'm looking for questions more along the lines of https://stackoverflow.com/questions/1282830/uiimagepickercontroller-uiimage-memory-and-more - which has a lot of questions and a lot of great information. I voted it up.
I'm thinking of sending out one of these topics about every week and then having a discussion about it towards the end of the week with some examples. Maybe assign a short presentation on a rotating basis so someone gets the job of delivering a 10-minute presentation about the topic, prizes awarded etc. - then when some task comes up involving that topic we may not have an expert but we at least have someone who knows where to start looking for answers. And maybe is keen to find out more based on that exercise.
stackoverflow, while it has "great questions", has a lot that are not so great and these scroll by in huge numbers daily. In iPhone-tagged questions sorted by votes I'm seeing very few of the kind of questions I want. I'm going to look further at some of the top-ranked questions here of course but these are the questions people had to ask, not necessarily the questions that others might get the most benefit from.
There are lots of exercises for "programmers" around but those are not what is needed. I want this to be iPhone specific. We come from a range of backgrounds and are all decent programmers already.
So - what are some things about iPhone development that YOU think are worth knowing? Can those things be phrased in the form of a question that leads an enterprising programmer to a satisfying answer? What made you stop and think, saved you days, pushed you in another direction that was fun and/or profitable, increased your knowledge or just made you feel good for having discovered the answer?
Things every iOS developer should know about:
Categories (how to extend existing classes with new
functionality)
Delegation pattern (how to implement your own delegates using either
a formal or informal protocol)
Blocks (often an improvement on delegation in case of
asynchronous calls, also useful in many other ways)
Passing NSErrors through indirection pointers.
NSInvocationOperation / NSOperationQueue for easy / clean threading code.
With the arrival of iOS 5 soon, one might want to learn about:
Storyboarding with Xcode 4.2 / iOS SDK 5.0
ARC
As a iPhone developer I will set these topics as a 10 minutes presentation.
Beginner level, may be useless if you are already developed in Obj-C but quite useful to integrate a C++ dev in your team
C++ vs Objective-C, Objective-C 2.0, Objective-C++
Memory management in Obj-C (retain, release, autorelease)
MVC design pattern
IB outlets
Design patterns in Obj-C
Use Stack Overflow before Google (not specifically iOS)
Medium/Advanced level
** Instruments ** (how to use it) (very important)
Comment code (even if selectors are expressive? a line or two is always better)
Automated tests (Who test their app anyway ? :))
Image manipulation + memory warnings
Code review of past apps (what is good, what is bad)
Code abstraction (see what module you have copied/pasted many times on yours apps and way to make it like a framework)
OpenGL ES (basics, only useful if you makes games)
Maps integration (with custom callouts, pins ...)
App Store submission (things to check before sending the app)
In-app Purchases
Push notifications
Core Data
SQLlite
Web service integration
Game Kit
Reducing loading times in the app by preloading
XMLParser (DOM and SAX)
Bonjour
Networking (checking that the iPhone can connect to the server)
Social network integration (FB, twitter, 4square ...)
Using GoogleMaps webservices
JSON
Core Animation (very long presentation)
Using UIAcceloremeter
Custom Views
Creating IB outlets
Creating Frameworks
Using Core Audio
Geolocalisation
Using C++ frameworks with iOS Projects
Things I don't know :
Calendar
Using iTunes library
CoreTelephony
Messing with Address Book
iAd
Video
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 understand that for smaller projects keeping methods in the main view controller (namely viewDidLoad) is the way forward, but for bigger projects im thinking this cant be the way apps are organised - the m file would be chuffing huge! also there would be thousands of declarations at the top! Im nowhere near building an app that big but i'm intrigued, would you put them in a separate file and call them when they're needed? or is it just a case of scroll past the declarations and use pragma marks to find what your looking for?
Basically this is not a specific question for developing iOS applications, it's more of a software architecture problem and requires more knowledge that can't be put in a single answer.
But to get hold of how things usually work, the project has to be planned by pen and paper first, since those are the developer's best tool, then when you've got the main parts of your project planned in a good manner, you start by plotting some ERD of your main components, and decide what will each part be responsible of, then start coding from there a prototype version.
when you have a simple project up and running, you start cleaning up the code, planning even further, and start testing your code, I can't describe how important testing is !
You'll also need software to manage your project (not the source code, but the project itself), something like asana maybe to keep track of tasks and who does what.
In order to keep your code safe against overwriting by other people who are working with you, and to keep things managed across versions, you'll need to setup a revision control repository of some king, Git is supported out of the box by XCode !
Now for the part of code writing, you need to learn some kind of pattern and follow it, iOS projects and most others now follow the MVC structure, which answers your question of how big the classes will get and how things will communicate together without turning into a mess !
Yes, you'll need pragmas and code trickery here and there, but you should always follow the patterns and conventions in order to keep things maintainable when projects grow !
again as I said, this is not anywhere near a good start, you need lots of experience and knowledge before you can actually work on huge projects, but it's something !
Keep up the good work, and always remember that you always have to ask questions, never be intimidated :)
Edit 1
Forgot to add a tip on reading about Agile software development that's probably my last tip :)
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.
Not sure if this is the best place to ask or not but if it gets closed down oh well. I am in computer programming and starting on my first work term. I will be doing 2D game programming for iPhone in objective C. I was just wondering if you had any tips for learning how the code works on a big project. In college I have never worked with something in terms of this scope. I am used to a project with maybe a dozen source files while what I'll be working on has hundreds. It is very overwhelming for me.
Any Tips would be appreciated. Thanks very much
This is how I do it. Opinions and methods may vary.
Generally speaking, I find the best way to learn about a system is to go through the code while the app is running.
Pick a significant place in the UI (the startup screen, some other screen).
Find the class for that view. Generally just ask a senior developer. Developers are happy to give a pointer (no pun intended) to someone who wants to learn by himself instead of having to explain everything.
Place a breakpoint in that class and run the app in Xcode until you hit your breakpoint.
Then start tracing in there to see how things happen.
Repeat the process at different spots in the app and soon you'll get a general idea of how the app works. Then it's a lot easier to catch the details.
If the system is really enormous (like an enterprise app that runs on multiple systems), then a diagram showing all the architecturally significant pieces would probably help. For an iOS app, it's probably not needed.
Good luck...
I am a 3rd year computer engineer who has done four work terms, and I can offer the following :
Some general advice:
Compartmentalizing your approach is still very useful on a big project, as in a small one. The more specific parts you focus on at a time, the easier it will be to understand them. This is not always practical due to interdependence of programs, but it is still possible to, say, work on the graphics portion alone, or the character's movement algorithm, etc. You should know that in the past that it was possible for an educated person to know the sum of human knowledge, but that is impossible today. Even senior engineers/programmers have specific areas of expertise, and other areas where they are fuzzy. Find what you most enjoy/are talented at, and devote time to that.
A basic foundation is important. Study the basic ideas of loop structures, classes, methods and the like, and know them like the back of your hand, so when applying them across languages/platforms, all you need to do is refresh yourself on the syntax. The same basic ideas apply across a range of languages.
Most of all, do not panic. It is your first work term, and you are assigned mentors/supervisors, as well as working with a team. Doing it alone would be difficult, so network well with your teammates/superiors so you can all learn from each other, divide the work, and lessen the stress on yourself!
Good luck! :)
Short Answer :
Read less, do more, then read when you get stuck. In my opinion, that's the best way to learn any new language and also someone said :
"We learn by doing, there is no other way".
Long Answer :
Rule 1: Relax.
Rule 2: You gotta understand that this is not easy stuff to master. That is why people who do get paid really well. If you had an idea you could bang this stuff out in a couple of weeks with you need to dump that. Plan to spend months working up on it.
Rule 3: Understand that the Apple API is HUGE and it is always evolving. There is enough content to learn something new Everyday.
Rule 4: The fewer programming languages you've had to learn, the harder it is to learn new ones. You will learn slower than someone else who has learned half dozen languages/APIs already.
Rule 5: Don't be afraid to use repetition and brute force. I think the thing that slows novices down is not learning the behaviors and methods of common foundation classes like NSString, NSArray, NSDictionary etc.
Rule 6: As a learning exercise, copy-pasting might not be the right thing to do. If there's an Apple example of how to do something, rather than copy-pasting I tend to rewrite it manually. I find it sticks better in my mind.
Rule 7: Use any resources you like. There are no rules on how you should learn.
Rule 8: iPhone is a memory constrained device where network and local storage access is slow. Parts of your application can be unloaded at any time, your application is responsible for maintaining it's memory footprint (not the user), and an event (phone call, memory, etc.) may require the app to respond accordingly and quickly.
Rule 9: It isn't about you. It isn't about your code. And it isn't about your code doing this or that. It's first about the user and responding to the user. It's second about your code responding to the framework. You don't usually tell the framework what to do. It asks you for things when it needs something. You sit and wait for it to talk to you. You're not in charge. You don't control the runloop; it controls you. You register to be told when things happen, and you indicate that you're the object who knows something about something (data for a table for instance). And then you let go, and let Cocoa do the rest. It's a very different world. I like it very much.
Rule 10: Relax.
When I'm coming to a new Xcode project, I open it up in OmniGraffle Pro. If the project is well organized, you'll see a nice diagram with a summary of the classes, the methods that are present and a little bit of how things relate to each other, important enums to know about, and other helpful information for getting a good overview of the project.
After that, pick a point like #mprivat said and run it in the debugger and get a feel for how things run. I like to set breakpoints with logs of the breakpoint name and hit count (and maybe the value of some variable or parameter if it seems relevant) and automatic continue after a little while to avoid pesky timing issues that can sometimes creep up when the debugger pauses execution. I use breakpoint logging so I don't have to worry about accidentally committing clutter code. (Be careful of pulling new code though because breakpoints don't move with your changing codebase. :))
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.
For the last few years I have been developing a 2D video game, which would most likely fall under the category of a singleplayer RPG with a post-release goal of adding in multiplayer. My goals have always been very realistic, attempting to achieve small chunks of progress before anything too serious.
My 2D game requires a hefty sum of assets (artwork; primarily images, some which are very large). While most of the last few years has been working on the artwork, for the last year I have been sharpening my programming skills, learning about game engineering, and building small games in various languages and frameworks/engines. After much work with different frameworks/engines, I realized I need (or at least want) to squeeze every last bit of performance that I can. My game will most likely take 1-2GB of ram maximum, with at least 4-6GB of HDD space. With content expansions I'd expect it to get quite large, at least on the HDD. This is why I, very unfortunately, do not believe HTML5 is ready for my game. Otherwise I would choose it, buy specific (highly rated) books, and start work right away.
I started my project with XNA Game Studio for primarily two reasons: a hefty bulk of tutorials at XNA GPA Tutorials to give me an easier start, and the ability to port to a secondary platform besides my primary target of Windows (port to XBOX). Soon after some development, I ran into a few issues with the framework, content pipeline and its (crappy) compression into XNA's (crappy) .xnb format, and the understanding of severe limitations for XBOX Live Arcade games and their size limit. The XNA GPA tutorials are nice, but I realized they're nothing special that I need to build my game using another framework.
SDL had amazing performance, so I started to work on developing my game. Progress was quite nice, and I did not run into any problems. However, with the way SDL is advertised (talked about) I assumed it used OPEN GL by default, not software rendering. I implemented some OPENGL, but read online that its open GL implementation was a bit rough, and that SFML is a much better engine for those who do not mind that it is higher level.
Off to SFML I went! And after a few days, it went straight into the trash. Reading about intel graphic problems with rendering, having to trash 1.6 due to the unfixable ATI glitch, and then trolling through google to find a custom nightly build of 2.0 that works with mingw 4.7.1, and learning that I am not the only person skeptical of SFML's quality as a whole, as well as some irrational changes in intuitive code from 1.6 to 2.0, I just wanted to give up in frustration.
So I am back to SDL, with very little developed. It is not that I want to use SDL, but that I cannot find a framework that is suitable for my game that is better than SDL. I fell in love with HTML5 and then was very interested in Isogenic Engine (HTML5) but I severely doubt that HTML5 is capable of handling my large (and numerous) sprite sheets and heavy asset 2D game.
Portability is important to me, but not a requirement. I figure I might as well just start programming my game for just Windows, and then once it is finished if I want to, then port it elsewhere. The best piece of advice I've ever received was, "It doesn't matter what you use. Just start, and do it. Having a completed game is more important than having a high performance piece of incomplete software."
However, I have heard by many that it would resolve a lot of headaches and some extra heavy lifting if I were to pick a library/framework/engine that handled networking at a higher level than what I'd have to implement if I were to use SDL.
I've researched game engines for years now, so I am really looking for convincing reasons to pick [your suggestions] as opposed to a simple, "I haven't used it, but..."
I want to be convinced away from SDL and onto something higher level, but I am having trouble finding reasons to choose differently. There are hundreds of game engines on wikipedia's list, and many more not listed-- but sorting through the chaff is exhausting, especially when I have already tried so many and been quite disappointed with the results.
Think of my game as a high resolution image version of Baldurs Gate 2, Sanitarium, Diablo 2, or Ultima Online. Not in gameplay, but in the fact it is entirely in 2D images which result in art style, chunks of ram usage, tons of HDD space, and a few quite large spritesheets/image sequences (Dragons, for example) amongst many very small sprite sheets (7MB total HDD space for a human character in 15 animations across 8 directions, and under 30MB memory usage for the sheets).
Also, thank you for letting me vent while I ask for detailed suggestions.
i have the same problem as you. I would really want to find right framework. I tried a lot and i think i found it. It's Polycode http://polycode.org/ http://polycode.tumblr.com/
But it's not finished(IDE, library is usable) and developer says it's going to be till the end of January. But i started developing my own just in case Polycode disappoint me.
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'm looking for an advanced iOS prototyping tool. Here are some of the requirements that would be necessary for me to use one:
Should be able to run on a device and respond like a real app does. I don't mind if the prototype runs in a container.
Should be able to rotate a UITableView horizontally (like in Pulse/BBC) and also support gestures on the table.
I've seen some prototyping tools but none of them seem to support my second requirement above. My only alternative seems to be coding, which I do not want to do at this stage because there are a lot of other details that would end up making the prototype too-much-to-handle. Any pointers?
I think you are putting too much effort into a prototype which (I'll assume) is going to be thrown away once you start implementing the real deal.
Ask yourself what you want to accomplish with a prototype.
Is it to test your navigation and design with users to see if it is intuitive and complete? In that case I would recommend that you write no code at all and make a prototype in something like Keynote. you can even use that to make a clickable PDF that you can view in full screen on the device to let users tap on buttons etc. Check out the instructional videos on Keynotopia here for an example of what I'm talking about. I've even bought their awesome templates and love prototyping this way.
Is it to see if a specific technical thing can actually be done? In that case do minimal UI and write your code for real.
If you're trying to just develop a wireframe, you can use control dragging and drag & drop interfaces within Storyboard in Xcode. If you want to do anything else, you'll need to at least add some code behind it.
Best prototyping tool I've found is here .
It's free too. But I agree 100% with #Heiberg above - don't waste your time perfecting the prototype.
Blueprint has been removed by Apple recently. App Cooker would be the best option for you with the free viewer called App Taster. A big update is coming, the price will go up. It's the right time to jump in. www.appcooker.com
I agree with #Heiberg that a long involved prototyping process isn't worth it. The iOS prototyping tool I built, Flinto takes that to heart. We focused a lot of our effort on making the process of creating the prototype very fast.
Gesture support is forthcoming. Rotation is handled by dedicated portrait and landscape versions of your prototype.
I'm happy with AppCooker for the iPad. It has also free reader, called AppTaster, so other people can try your prototypes.
It's not 100% perfect, and update cycle is rare, but I like it.
It supports gestures, but doesn't support rotation.
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.
What do you think about both?
I began reading a book about Catalyst, and found it pretty complex as compared to Dancer.
so now I'm giving Dancer a try, and it looks easier to learn and more "human friendly".
I think David's comment is very accurate and excellent. However, as someone who has done development in both but is not a developer on either perhaps I can be slightly more objective (and technical) in what the differences are.
Both frameworks provide a variation on the Web MVC paradigm.
Catalyst's main level of abstraction is the Controller. Catalyst expects you to break separate logic out into separate packages in some logical fashion (Login code goes here, Registration code goes there, Search functionality over here). This works incredibly well if you have a team of programmers since each of you can work on separate files and not step all over each other during merges. Catalyst provides a lot of tools for making the Controller logic extensible and flexible, I think the premier example of this is Chained actions which let you split up and build a complex flow for any given request. The downside is that it becomes very seductive to put your business logic into the Controllers and you end up with very fat logic in the Controllers where it (theoretically) belongs in the Model.
Dancer's main level of abstraction is the Route. My experience with Dancer is this leads to much smaller applications. Partly my experience here is tinged with the fact that I have dealt with several thousand line applications in Catalyst but I have yet to write a Dancer app that is longer than 200 lines (with a much smaller scope). I think however that this experience holds true. The push in Dancer is in keeping the Controller logic very thin because it doesn't have the same tools for managing complex behaviors there that Catalyst does.
Honestly I've enjoyed working in both of them. They both provide different opinions on what writing a web application is supposed to be. I would, given the time and inclination, recommend learning both ultimately.
This is a somewhat subjective question, but I'll try to give you an answer in an objective way. First things first, a disclaimer: I'm part of the Dancer development team, so my opinion should of course be considered somewhat biased :)
Catalyst is more widely used than Dancer, and so there's more community support behind it - if you were to look for contractors with experience working with either framework, say, you'd be more likely to find developers who've used Catalyst. So, if you're looking for commercial support, that would be a good reason to choose Catalyst.
Dancer is a younger project, and targeted more towards smaller projects, making getting up and running quick and easy, and trying to stay out of your way. That's not to say that Dancer isn't suitable for larger projects, however; the same habit of staying out of your way means you can organise your project in the way that suits you.
However, it has picked up a lot of support, and there's a growing community of helpful users and developers on IRC and the mailing list, and more and more useful plugins being released all the time. As with Catalyst, Dancer is designed so that you can pick and choose your preferred template engine, session storage backend etc, and it's easy to extend the framework by writing your own plugins if you need to.
For user testimonials to see what people say about Dancer, see the section at the bottom of the homepage on the new website: http://www.perldancer.org/
In the interests of showing other options, there's also Mojolicious, another modern Perl web framework which has been gaining in popularity lately.
Catalyst provides the same abstraction that Dancer does, Dancer's strength or rather Catalyst's weakness or rather Dancer's weakness is in how Catalyst forces the developer to adhere to Perl OO best practices and the MVC design pattern. After doing webapps for a while, this will all become apparent.