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.
Took about a two week break from development and came back this week to hit it hard again. xCode is CRAWLING. When it opens it takes FOREVER - 5+ minutes - and then every time I click on anything in the GUI the "cursor colorwheel" spins for 2+ minutes. I tried deleting my .xcodeproj file with no effect. Been reading various posts and the net but can't find anything that improves my situation. Anyone have any ideas? Thanks.
While Justin provided a really good list to start with, I'd like to add something that I think can instantly improve your Xcode and Mac OS X performance (after some re-installation effort, though):
get an upgrade to a good, fast SSD drive!
From my friends' experience it should give better results than upgrade to 8GB of RAM. However a combo of 8GB and fast SSD is be the best option to go.
Just to check I would use Time Machine and go back in time a while, then check Xcode again. If this happens with all projects - even with a new one - then certainly there is sth wrong in general. Check your HD and other progs, also check with activity meter if Xcode is really doing sth.
Anyway, I am currently working on an app with about 200k line and about 15 MB target size. I can use Xcode 4.2 without any delay.
ps once before with XCode 4.0 I experienced sth similar, however, even with a much smaller app. After even trying with Apple support it turned out that for some reason my installation was corrupt and could not be cleaned up. I had to install another Version of Xcode than everything was OK again.
some things to help you get started:
keep with the official releases (read: no betas).
make sure you have enough RAM (8GB w/ Xc4 is a good minimum for me) and a fast drive.
revert to 10.6
revert to Xcode 3
reduce project interdependencies
reduce header dependencies (faster indexing and compile times)
disable live issues (Xc4)
clear your live search fields (this alone can block UI and builds for minutes).
file bugs
try running it in 32-bit (garbage collection consumes a lot of time, and it will reduce the total amount of memory required).
provide more details of what Xcode is doing that it requires so much time (sample)
That's not normal. Sample it and find out where it's spending all that time.
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.
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 10 years ago.
I have been using MAC OSX and since beginning I have had problems with memory consumption of JAVA ides.. I have tried Netbeans, Eclipse and Intellij, tried to configure jvm settings especially for eclipse but memory problem remains...
basically, although i am not doing any compiling or building, keeping one single project open makes my ide to consume more than 750 mb of ram.. this is same for all the ides i wrote above and customizations of ini files makes a little impact...
are there any low memory consuming ides around? or something written for mac only so probably it will handle ram issues in a better way?
Smart IDE needs to index all your project and SDK files to provide code completion and other intelligent features. The index needs to be stored somewhere, so there would be always a tradeoff between intelligence, performance and memory consumption.
If IDE chooses to minimize the memory usage, it will have to store cache on disk and load it when you invoke some feature that requires some data from the cache, you'll get a delay when using a feature, which is unacceptable and will slow down editing.
Of course you want your IDE to be fast. To achieve this, it needs to always have most of the caches and indexes already loaded in memory, but you'll see higher memory usage.
Whether you like it or not, but most modern applications prefer to be faster and consume more RAM, rather than to be slow and consume less RAM. Chrome browser with 5 open tabs will consume more memory than your IDE.
Memory is a cheap resource (unless you have old hardware that you can't upgrade by installing more RAM, like a laptop). Normally developers do not save on hardware. In order to be productive when using IDEs they have systems with at least 8GB of RAM. Developers working with Java and application servers can have even more. The price of 24GB is ~$100-150 now.
Would you save on RAM and then look for a slow or feature limited IDE that can work on your system? Or would you buy better hardware and forget about this resource for several years while enjoying the IDE providing more features and speed?
You may be better off with a text editor like http://www.sublimetext.com/
Or if you want to be old school, vi or emacs.
You can reduce Eclipse's memory usage if you tweak settings and remove things you don't need. In particular, don't run the EE version, disable spell checking, and keep your project workspace tidy (1 project).
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.
I recently came into some blogs saying that Linq to Sql is dead. and a few days ago I saw a discussion with some people saying that Silverlight maybe will take ASP.net place! ...I don't want to ask if they are true or not but it is so annoying when you wake up and found your languages and informations in the casket! (I think that Microsoft languages have the big part of this words). So what should I do in this case ? drop every thing back and start again with the new techniques or keep using the old stuff or what ?
A platform isn't dead because someone says it's dead. It's dead when it's no longer used, and in that case, it's obvious you shouldn't be using it either. Unless, of course, you're employed by a big company that has a big legacy system that needs further development using that "dead" technology.
Nothing ever really dies. Especially Microsoft stuff. I thought I had wasted 10 years as a FoxPro dev (not even VFP!), but this helped me get jobs, even in related technologies like dBASE and Clipper, since those skills are harder to find.
Having said that, by all means keep up with the mainstream. Continuous learning is expected in this field.
In any case, neither of those claims (re Linq to Sql and Silverlight) is true.
First off, dont immediately jump to the assumption that what you read in a blog or in a tech magazine is true. If the 'old stuff' still works, whats the compelling reason to change? Basically its just keeping up with fashion. Use what you want to use. If you understand the basics of programming, you can adapt as needed when presented with new technologies.
Neither ASP.NET or Linq-to-SQL appear to be vanishing any time soon; however, this advice always applies:
Put pressure on Microsoft (or any other vendor, for that matter) to support products your business depends on.
If your business regularly purchases upgrades to its Microsoft stack, MS will want to make you happy. Get involved at Microsoft Connect, contact your MS representative, and be involved. The safest path to maintaining support from MS is by participating in their process. (It's why Windows XP remained supported long after MS announced support would end.)
Simple answer: Be sufficiently broad in your technical abilities.
As a hiring manager, I'm more concerned that you know how to write good programs and that you know how to get answers to your questions, than I am that you spent 10 years focusing on a specific technology.
For example: If I'm hiring for an MVC2 position, I would gladly take a seasoned Microsoft web developer with webforms experience and some MVC2 exposure over an unseasoned and unskilled programmer that's been working in MVC2 since it came out.
Many programmers are keen to try out new things. The statement "Technique X is dead", means just that someone tries to convince himself or a group, that investing more time into something else seems worthwhile.
To really kill a technology you would need to remove all related downloads and available knowledge or relicense the software in some form that makes usage impossible.
When a group of people shout that X is dead, they are just moving to Y. If you can still hire X programmers, you are not in big trouble.
Don Box once said "If your this kind of people that start working with a technology when it's dead, it time for you to start using COM". He said that to introduced .net an confirm that way that COM won't be further improved. See ? "Dead" means it won't evolve as much as other anymore but definitely not that we should't use anymore.
Don't jump to conclusions based on (non-authoritative) blogs. People have opinions, and that's all they are. Until the vendors of the technologies you're using come out and say it, proceed with caution.
I'm not a .Net expert by any means but I think there's a reason for not using Linq for SQL queries since a dedicated ORM approach will most likely be faster and more configurable. As far as Silverlight, it's just a subset of WPF which is a GUI framework. They possibly wish that silverlight would take over some processing from the server side but I doubt they'll get that sort of market penetration.
That's life on the cutting edge... You got into this business because you liked the latest technology, right? Well, don't look back, look forward. Before your favorite technology even has the sniffles, you should be looking at what's going up. If you study up on the latest technology, you won't even notice when the old stuff go away.
Software development is all about learning things so that you can build things that will be thrown away and replaced with newer things some day! If you don't want to commit to continuous change, you're in the wrong field! :-)