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 :)
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.
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.
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.
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.
Can someone give me some insight on a scenario like this.
Say a company has en existing Joomla site, not complete but just has all the modules, plug-ins, and components installed that they believe they will need.
If someone new where to come in and given the general idea of what the site needs to do, and by accomplishing this they need to make sure all plug-ins share data between each other update information between each other when ever one module is updated. As well as fixing and modifying the template to take shape and form of how they envision the site to be interacted with.
Would jumping into this project be more trouble than its worth? Would creating something from the ground up using custom developed pages rather than using Joomla as a back-end/front-end be too much of a hassle.
Also given that the existing installation has 301 tables to sot through.
Joomla is more than just a CMS, it is also a pretty solid "Development Framework". Modifying existing software will be faster rather than developing from scratch, especially if it is that big.
Read more about Software Development Process, it will help you with your evaluation. As far as I remember development cost is 2x less $ than maintenance in first 5 years.
Starting from the ground up can be not such a good idea for a large project. Working with another framework will result in "reinventing the wheel" and introduce new problems and will require more time for user acceptance.
I know too little to point you in the right direction... 1st of all Joomla is terrific choice, object oriented, it is extensive and very powerful. MVC architecture is huge plus. Plug-in system is easy and extensive. Modules are easy and customizable.
I suggest using Zend Framework if you want to "reinvent the wheel". ZF is exceptional choice but your cost will be MUCH higher. You will have all similar functionality and features like in Joomla: OO, MVC, singletons, layouts, placeholders, modules (components), plug-ins, etc... Comparing ZF to Joomla's "Development Framework" is like comparing Ferrari to Honda Civic.
Long story short: I would try to stick with Joomla and create my library extending Joomla's classes... this will help automating a lot of things (reduce code, etc...). If I was to give a quote to the client I would try to see what they want/their experiences with existing project (check with their IT department, etc). If experience was horrible from day 1 and it was because of software and not hosting/db/hardware/network/etc then I would give 2 quotes: 1st for recreating in Joomla, 2nd for recreating in Zend... and explain strength/weaknesses of both. If software behaved 'OK', with minor to medium problems/bugs/errors I would reuse existing project.
Hope this helps...
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.
As an artist and musician, I often want to sit down and just let the code roll like a piece of free-form poetry, but I've found that doesn't work as well as when I have a set goal in mind. I've been experimenting lately with setting up tiny, fun goals for myself, not unlike how an artist would sketch a quick still-life, but I wonder...
What do others do when they want to code for fun, without the bondage of an already-committed project?
Design work, I find, flows much easier than just coding. I find that coding is often more of just implementation of a good design; I really like to just sit down with a pad of paper and a pen (and likely a bottle of wine) and work out an interesting design.
Project Euler is where I'm having fun at now. I can go at my own pace and work on the problems that interest me. Also, work in any language I choose.
Write documentation when coding doesn't come easy - coding will quickly seem much more appealing!
Going for a walk outside.
I tend to map my idea or build a structure in a MindMapping tool like MindMeister. And it's great for a team because it can be edited in real time by multiple persons!
I like to pick up a new language and learn how to express ideas in it. This usually has the benefit of showing me what I like and don't like about the languages I currently use. I usually pick some little tool project I've been wanting to do. Using the new language angle get's me motivated
My most recent 'new language' is Scala, in this case it will likely become a langue I use.
I like writing on whiteboards. Great for db diagrams, task lists, feature lists, (other lists,) random ideas, notes, etc. (db diagrams being the biggie for me)
Python is great for just getting things going on an idea and having the language (usually) behave like you would expect.
While it may have its drawbacks, it sounds like a great fit for what you are describing.
So to answer your question, the Python Challenge is entertaining and often gets me thinking about little things that would be fun to code, probably because it exposes you to different types of problems.
I like to code.
I like to find something interesting, code it and then see it works.
It does not have to be a project per see, it's good enough if it does something, like use Google api to get picasa albums, change song in iTunes or get details of current iTunes song, automate downloading of document from web site that is behind login and requires cookies and all that stuff, data parser in python, simple app on Mac, core data application, google codejam problems, topcoder.com problems ...
I like to learn new features of some language or some new language/technology/patterns/tool :-)
Usually I will work in Photoshop for a while. Get creative and try to come up with a new design that's not constrained by any code. Maybe even find something inspiring on the web for some new design ideas... then try to implement the design in code. That's the fun and challenging bit.
Use the REPL.
You figure out broadly the sort of thing you need to do - what APIs you need to use, what data structures you need to handle - and then prod them interactively until they start making sense. A ton of languages I use now have REPLs: Ruby, Python, Scala, Java (BeanShell, or JRuby/Jython etc.), C# ('csharp'), PHP (Facebook have made a REPL for it), Smalltalk (GNU gst) and, obviously, LISP/Scheme.