Related
I started my career on Linux/Unix, and moved over to Windows and Visual Studio. XCode feels pretty alien to me. My feeling is that I'm not in control with XCode. It could be the case that I simply haven't understood how to use the IDE, I am new at developing for Apple OSs. One thing that kind of irks me, is that nobody seem to have found a clean way to compile for multiple platforms (iOS and Mac OS X), using the same sources. I've found two ways to "hack it", but the hacks sound fragile.
I've been pondering the idea of using simple make files instead of XCode (except for the occasional use of Interface Builder).
Is this a sane route to go? Has anyone done this? Are there any major drawbacks I need to be aware of before I take the leap, or should I just bite the bullet and wait for the enlightenment?
Use Xcode, use as many high-level tools as possible. The "loss of control" is replaced by more focus on the application, which IMHO is a great tradeoff.
It is kind of like the loss of control when I went from assembly code to "C", but it was worth it. We keep moving to higher level of abstraction and that allows us to accomplish more, focus on the big picture instead of the minor details.
You've just got to learn new ways of doing things. For example, in the situation you describe (building an OS X and iOS app with shared code), I'd put any shared code into a library/framework that is used by both projects, and create a workspace that contains all three projects.
The loss of control you speak of is offset by the fact that this can all be set up without knowing anything about compiler command-line options in around 10 minutes.
It's a different way of thinking, and it can be frustrating if you know how you would do it on a different platform, but there are advantages to both options. You may never have to think about the build process again!
I am looking into developing a commercial application using PHP. Since I have experience in CodeIgniter and it has been working well for me, I decided to use it. Now, if ever my application comes to a point that it needs to grow and have to have custom modifications in the platform, is it possible to modify the CodeIgniter source code to the point that it's far from the original?
I'd strongly recommend not modifying the source code as this is the back bone of the application will make updating to futures releases of codeigniter impossible.
Instead you should be creating your own classes/libraries that extend the core bases. This is best practice.
The codeigniter users guide has some fantastic information regarding this, http://codeigniter.com/user_guide/general/creating_libraries.html
Good luck.
Don't modify it, extend it. Ellislab is good about releasing bug fixes and patches, and the last thing you want is to have to re-engineer all the updates into your new hybrid everytime they release updated source code. Plus, different features and bug fixes are released at different paces for the core and reactor, so unless you plan to lock your framework in at the current version, extending is the way to go.
The good news is CI is built for and encourages extensions of the source. The system folder and the application folder separation are a clear indication of how you should segregate your enhancements from the base libraries.
CodeIgniter is written in PHP. You can completely rewrite the framework anyway you like. So the answer is "yes".
There are many big websites that were written in a different language or build on a framework when they started and have been rewritten many times since. I think a lot of developers (mostly freelancers) are over-thinking when starting out. When I start a project, then I try to get it done and get it out in the web asap. If a website starts taking of - and most of the times start making you money - then you can always take the time to rewrite it.
I think it is a lot more important to spend time when you plan and design your database and tables. I think it is a lot harder to redo parts of your database later on then it is to rewrite the code that uses the data.
Just my 2 cents.
If you have used CI, then you should know that being a PHP framework that all of the source-code is there in the download, furthermore opening the system and application folders and looking through there will tell you a lot. Yes all of the source is there in plain English (plain programming English) and not only is it in plain English but has been extensively documented inside and out (literally that is in the source and in the user-guide). CI gained initial fame from that simple fact, that all code is extensively and meticulously documented.
Beyond all that, the question itself raises concerns that maybe you should study CI a bit further before writing commercial applications using it. Ci is a powerful and very easy to use PHP framework, but it is not a WYSIWYG. In my opinion, a coder should know his tools inside and out in order to be able to create a solid secure and trusted application. The first measure of which is to read the user manual, you should know at the very least everything in it, and since there are 12 sections in it that cover everything from extending CI libraries to creating your own libraries, and everything in between I would say you need to spend a little more time with it.
I want to say though, I am not being rude or trying to shame you in any way I am simply saying that you should learn the framework a bit more before venturing into a commercial application using it.
In the early days of PHP people realized how amazingly easy it was to use and how fast you could write an application with it. At the time the major options where very difficult for new and hobby programmers to use or involved expensive software to run, PHP was free, easy to learn and most of all ran on a free OS. It also took hardly any setup to get going, you could download PHP and essentially be programming in minutes. All of these factors lead to the almost destruction of the language.
Entry level programmers were destroying it with bits of code taken from other applications, never knowing (or caring) what the code actually did beyond the simple fact that it did what they wanted at the time, never considering or even investigating if the code might be harmful. Because of this practice PHP applications that had grown to Goliath sized websites, taking thousands of hits an hour were:
beginning to crash
being hacked to reveal sensitive customer/client data
generally crumbling all around the web
All because since the language was so easy to use that people had taken advantage of it and failed to take time to learn it. PHP was becoming a joke to other professional programmers and wasn't even thought of as a viable application language by many who had dubbed it "the copy and paste" language.
So my advice to you, please take the time to know your tools inside and out, what makes them tick, if they have any gotchas and where they are vulnerable. I understand that in order to learn a language to a professional level you have to build with it so I suggest that you take it slow with CI stick to the core for now. Trust me when I say that even in its purest form CI is an amazing and powerful tool that in the right hands can create awesome powerful web application, but in the uneducated/inexperienced hands it can create havoc and destruction.
So (stepping off of the soap box) I simply ask that if you are serious about creating commercial applications period that you take your time and learn your tools/language become as close to an expert on them as possible. I gurentee that if you do that you will always have work when you need it and you will spend less hours beating your head against the table or worse explaining to a client why their site is down.
I truly wish you good luck, just slow down and learn your trade and you will do just fine.
Yes, Codeigniter is an open source framework. However, I would advise against modifying the core of Codeigniter, as most files can be extended and rewritten safely without modifying the core files which will cause you headaches if you ever decide to update.
To extend a core class by default you would do this in Codeigniter. We'll extended the parser class for this example, but this applies to all classes pretty much. This link in the comprehensive user guide will give you all the information you need to extended and overload methods inside of a Codeigniter core class: http://codeigniter.com/user_guide/general/core_classes.html
i'm facing a challenge of rebrushing and updating an almost 10-years old Screenweaver project, and looking for a decent modern swf-exe convertor. Don't have much time to evaluate all the options, therefore i'd like to hear responses with actual working experience with such a tool.
Since WinAPI interaction is a must, the default projector is not an option.
Similar questions (no concrete answers there)
Package SWF into an EXE or APP
Create an EXE from a SWF using Flex 3 without requiring AIR?
Many thanks
UPD: 300 bounty for anyone who can help me with a practical answer.
I've been experimenting with different SWF projectors for a long time now, and so far I think I've tried most if not all of them. I've explained in more detail the best projectors I have used below.
MDM Zinc
http://www.multidmedia.com/software/zinc/
I remember back in when I had Vista that MDM had quite a few bugs running under that OS. It took a while for them to fix those bugs - the bugs didn't stop it from running, but really interfered with the functioning of some methods in the program. For this reason, I decided not to continue testing Zinc and moved on to another projector. Saying that though, I'm certain they have fixed those bugs now.
The program itself has a nice intuitive interface, and allows you create screensaver as well as EXEs (which is obviously good for you).
The product is pricey - currently at $349.99, so this put me off.
You can also generate Mac and Linux projectors which is very attractive, but requires an additional license for each which does cost a lot of money.
SWF Studio
http://www.northcode.com/
This was one of the projectors I really enjoyed working with. It's fully featured, has great community support and the developers are always on hand to help. The projectors it generates are compatible with all Windows operating systems, and I've never had any problems with bugs on this one.
Northcode also offer a student license for SWF Studio for $49. I nearly purchased a license with these guys but the only reason why I didn't was because I found another projector which was better for my scenario which I will come onto in a moment.
I can tell you that one of the reasons why I didn't use this projector (it does sound trivial) is because it had a large file size. SWF Studio allows you to select what size projector you want in terms of filesize - with options like tiny and compact I think but the smaller file types might have dependencies with other files in the directory. This means that you would have to bundle your application with some folders and additional files as well as the EXE itself.
SWF Studio also has the option to create screensavers.
mProjector
http://www.screentime.com/software/flash-projector
mProjector has gone up a version (from 3 to 4) since I last used it, so it may incorporate a lot more features in this version. I remember that the product is very good with transparency, and showcases some 'screen buddies' which use transparency to virtually walk about your screen. The reason why I didn't use this projector is because it didn't have as many Actionscript functions as I would have liked, but I believe it has a lot more nowadays. In your project this wouldn't be so much of a problem because you want a screensaver.
It is reasonably priced at $399 for both Windows and Mac compatibility, but you can buy just Windows or Mac if you wish for a cheaper price.
Janus Flash
I was going to explain this product in more detail but I have now realised that the website no longer exists! Janus is the projector I liked the most and ended up using because of the sheer amount of features available for use in your code.
Like all the projectors I have mentioned above, each one adds functionality to flash which you don't usually get with an SWF. Each product includes pre-built actionscript methods which can interface with the operating system itself to do things you can't do in the Flash sandbox. For example, each one of these projectors allows you to manipulate files (add, edit, delete e.t.c.) on the computer. Janus had the most methods available out of all the projectors I tried. This is partially because Janus used the .NET framework (which meant that .NET 2.0 was required on the system you were executing the projector on).
Also like MDM Zinc, this product allowed you to create applications for the Mac too. I managed to get a cheaper price too when I contacted them directly explaining that I was a student. I recently contacted Janus-Flash to ask about the future of the product, and they said that they may re-release Janus in the future, but for now it's off the market.
Some other products I have used which are worth a mention but I haven't explained in detail: SWFKit, Jugglor, F-IN-BOX (more developer releated as it required cutting code).
A quick search brings up these which might be worth a look: Flash2Me, Flash EXE Builder and SWF to Screensaver.
For your project I think the best option would be SWF Studio. It has lots of nice scripting features you can use to interface with the OS, and is nicely priced too at $299 for a full license.
I hope this helps in your decision for what projector to use, and will save you from trying out many different projectors like I did over several months!
We support a lot of Win32 functionality directly in our core API so chances are you may not even have to make a direct API call, but if you do...
SWF Studio has an advanced Plugin API that allows you to write custom plugins in C++, C# or VB.NET so you can call win32 or .NET functions. We created our own ummanaged to managed code shim so you can write a native .NET plugin and call it from SWF Studio just as easily as you can write a Win32 plugin.
There's no difference between how you call a SWF Studio function in AS2 or AS3. We have maintained 100% backward compatibility in our API. Whether you're using AS2 or AS3, your calls will just work. And they'll continue to work.
However, the place we really shine is support. I created SWF Studio and I'm still in the forums EVERY day answering questions and fixing bugs.
My experience here is from a year ago.
Having worked with mProjector I can tell you that the AS3 API is quite robust and easy to use. I was able to wrap a large swf-based project using external assets up into an EXE without a lot of problems. The UI for mProjector's project gui leaves something to be desired, but the actual hooks to the file system were easy to use.
The difficulty is that not all of it is documented. In fact there were as of a year ago a lot of undocumented packages.
My only real problem with mprojector was that in AS3 there wasn't any support for SharedObjects. Someone in their community worked around this and made their solution available. It does of course make use of storing a file on the local system.
This overall compared favorably against Zinc which was extraordinarily complex, slow to compile, and worse than having no documentation all the docs I needed were flat-out wrong.
I ruled out Jugglor almost immediately. It never successfuly compiled anything.
Since this is an old project you're talking about, and written in AS2, I can't speak to that side of it. I can say however that programs like Zinc and mProjector have been around a lot longer than AS3 has, and that the same hooks that are available in AS3 seemed to be available in AS2 also. The possibility exists that there may be more such hooks in AS2 since it's been supported for longer, but I cannot vouch for this at all.
I have used all of these applications, but most of all I liked theFlajector - a program that converts flash movies (swf) to exe files. You can include a flash player in generated applications and they will use it. In other words, the applications will work even if no flash player is installed. Also, Flajector can create windowless applications from flash movies. You can extend your applications using plugins. Using standard classes you can work with files and more.
I'm fairly new to Cocoa. I was talking to my brother, who's put together a few iPhone apps, and I said something about Interface Builder. He said that he doesn't use it - he builds his UIs programmatically. He said that this way, he doesn't have to worry about loading the NIB. I understand that using Interface Builder actually creates instances of view/window/button/etc objects that are serialized and have to be deserialized when you load the application, but is the deserialization that expensive? Granted, he's talking about iPhone and I'm developing on a MacBook Pro, but still.
I have yet to see an argument against using IB due to performance reasons, and having used both methods I havent seen any difference either way. For the more ui intense applications I usually end up not using IB only because it is difficult to build complex customized views with it. So really I tend to use IB for the more simple apps and go with the progammatic approach for the more complex apps. This approach obviously is performance optimizing as well.
Absolutely learn IB! It's worth it and will save you countless time over the long haul. Then use it when you can. When you cannot (high complexity) you always have the programatic approach but you'll find it FAR easier to maintain your nibs (IB) as your app grows and ages.
If both methods can be useful, I'd recommend going the Apple's way; i.e. using Interface Builder (IB). You'll get less code to write (and less code equals less bugs, less maintenance, less work ;) !), a better abstracted project, you'll be much more ready to inherit future goodies coming from Apple (remember Cocoa Bindings…), and soon you'll also be more productive.
Understanding what IB's doing for you (by going through your brother's method) is a very valuable knowledge too; so if you can do both on some li'l projects, do that. (As others said, for complex UIs, this will allow you to bypass it at times.) But still, in the end, I'd recommend using IB.
Although Interface Builder is an old piece of software, with its roots in NeXTSTEP development, it is still (IMO) an elegant way of creating the visual aspects of software.
In this interview with Aaron Hillegass, he says that "Experienced Cocoa programmers put a lot of the smarts of their application in the NIB file. As a result, their project has a lot less code."
And as we all know: "Less source code is better"
It depends a lot on the kind of application. ERP systems with a few hundred/thousand pages are not build with Interface Builder, as far as I'm aware.
Is it worth to try to keep your GUI within the system looks ?
Every major program have their own anyways...
(visual studio, iexplorer, firefox, symantec utilities, adobe ...)
Or just the frame and dialogs should be left in the system look 'n feel range ?
update:
One easy exemple, if you want to add a close button to your tab, usually you make it against your current desktop theme. But if the user has a different theme, your close button is out of place, it doesn't fit the system look anymore.
I played with the uxtheme api, but there is nothing much you can do, and some themes i've seen are incomplete sets.
So to address this issue, the best way i see, is to do like visual studio/firefox/chrome roolup your own tab control with your theme...
I think, that unless your program becomes a very major part of the users life, you should strive to minimize "surprises" and maximimze recognizability (is that even a word?).
So, if you are making something that is used by 1.000 people for 10 minutes a day, go with system looks, and mechanisms.
If, on the other hand, you are making something that 100 people are using for 6 hours a day, I would start exploring what UI improvements and shortcuts I could cram in to make those 6 hours easier to deal with.
Notice however, that UI fixes must not come at the expense of performance. This is almost always the case in the beginning when someone thinks that simply overriding the OnPaint event in .Net will be sufficient.
Before you know it you are once again intercepting NC_PAINT and NC_BACKGROUNDERASE and all those little tricks to make it go as fast as the built-in controls.
I tend to agree with others here- especially Soraz and Smaci.
One thing I'll add, though. If you do feel that the OS L&F is too constraining, and you have good grounds for going beyond it, I'd strive to follow the priciple of "Pacing and leading" (which I'm borrowing here from an NLP context).
The idea is that you still want to capitalise as much as possible on your intended audidences familiarity with the host OS (there will be rare exceptions to this, as Smaci has already covered). So you use as much as possible of the "standard" controls and behaviours (this is the "pacing") - but extend it where necessary in ways that still "fit in" as much as possible (leading).
You've already mentioned some good examples of this principle at work - Visual Studio, even Office to some extend (Office is "special" as new UI styles that cut their teeth here often find their way back into future OS versions - or de-facto standards).
I'm bringing this up to contrast the type of apps that just "do it their way" - usually because they've been ported from another platform, or have been written to be cross-platform in GUI as well as core. Java apps often fall into this category, but they're not the only ones. It's not as bad as it used to be, but even today most pro audio apps have mongrel UIs, showing their lineage as they have been ported from one platform to another through the years. While there might be good business reasons for these examples, it remains that their UIs tend to suck and going this route should be avoided if in any way possible!
The overriding principle is still to follow the path of least surprise, and take account of your user's familiarity with the OS, and ratio of their time using your app to others on the OS.
Yes, if only because it enables the OS to use any accessability features that are built in like text-to-speech. There is nothing more annoying for someone who needs accessability features to have yet another UI that breaks all the tools they are used to.
I'd say it depends on the users, the application and the platform. The interface should be intuitive to the users, which is only the same as following system UI standards if they are appropriate for those users. For example, in the past I have been involved in developing hand held systems for dairy and bread delivery on Windows CE hand helds. The users in this case typically were not computer literate, and had a weak educational backround. The user interface focussed on ease of use through simple language and was modelled on a pre-existing paper form system. It made no attempt to follow the Windows look and feel as this would not have been appropriate.
Currently, I develop very graphical software for a user group that is typically 3rd level educated and very computer literate. The expectation here is that the software will adhere to and extend the Windows look and feel.
Software should be easy and intuitive where possible, and how to achieve this is entirely context dependent.
I'd like to reply with another question (Not really Stackoverflow protocol, but I think that, in this case, it's justified)
The question is 'Is it worth breaking the OS look and feel?'
In other words,
Do you have justification for doing so? (In order to present data in some way that's not possible within normal L&F)
What do you gain from doing so? (Improvinging usability?)
What do you lose from doing so? (Intuitiveness & familiarity?)
Don't simply do it 'To be different'
It depends on how wide you would define system look'n feel... But in general, you should keep it.
Do not surprise the user with differentiating from what he is used to. That's one of the reasons why we call him user ;-)
Firefox and Adobe products usually don't because they are targeting several plattforms which all have their own L&F. But Visual Studio keeps the typical Windows L&F. And, as long as you are developing only for Windows, so should you.
Apart from the fact that there is no well-defined look-n-feel on Windows, you should always try to follow the host platform native L&F. Note however that look-n-feel is just as much about how a program behaves as how it looks. Programs which behave in a counter-intuitive way is just as annoying as programs sporting their own ugly widgets.
Fraps is a good example (IMHO) of a program which is actually very useful, but breaks several user interface guidelines and looks really ugly.
If you're developing for Apple's Mac OS X or Microsoft Windows, the vendors supply interface guidelines which should be followed for any application to be "native".
See Are there any standards to follow in determining where to place menu items? for more information.
If you are on (or develop for) a Mac, then definitely YES!
And this should be true for Windows also.
In general, yes. But there's the occassional program that does well despite being not formatted for all the OSes it runs on. For example, emacs runs pretty much contrary to every interface guideline on OS X or Windows (and probably even gnome/KDE) and it's not going away any time soon.
I strongly recommend making your application look native.
A common mistake that developers who are porting an application to a new platform seem to make is that the new application should look-and-feel like it does on the old platform.
No, the new application should look-and-feel like all the other application that the user is used to on the new platform.
Otherwise, you get abominations like iTunes on Windows. The same UI design may be exactly right on one platform and very wrong on the next.
You will find that your users may not be able to pin-point why they dislike your application, but they just feel it hard to use.
Yes, there are valid exceptions, but they are rare (and sure enough, they tend to be the major applications like Office and Firefox, rather than the little ones). If you are unsure enough to have to ask on StackOverflow, your application isn't one of them.