I'm currently working on migration of iPhone project to Android. And since my dev machine is Windows 7, I'm wondering if there's a tool that would allow me to view nib files on Windows?
Basically what I want is to view nib files at least as an image file (no properties, just to understand how a View should look like).
And I would also appreciate if someone could suggest a tool that understands an XCode project structure and lets browsing of Objective-C files easy on Windows.
So, I'm looking into an convinient way of migrating an iPhone app to Android on Windows platform.
Thanks!
Not really. Nib files basically consist of a bunch of serialized ObjC objects; without reimplementing a significant portion of Cocoa / AppKit, it'd be difficult to make much sense of them. You might be able to extract the view hierarchy and bounds with some work, but it's probably much easier overall to just copy the file over to a Mac and open it up.
Related
I have found plenty of articles and how-tos online about making plugins for Photoshop on a Mac. Trouble is, many are old, apply only to CS1/2/3/4, or refer to tools or APIs that (it appears) are obsolete. Some articles say you must use CodeWarrior, but it seems this no longer even exists in the Mac programming realm.
Today, in 2011, making plugins only for CS5 and only on a Mac running Snow Leopard, what is the proper toolchain and what libraries/APIs/frameworks should I be using?
I've gotten the impression that Carbon (whatever exactly that is) is old and to be avoided, but it's not clear if that's true for plugins. I am not clear as to whether I should use Cocoa (whatever that is) or not. I do think I will need Core Foundation (whatever...) Is there a choice about 64 vs. 32 bit or is CS5 purely 64 bit and that's that? (I prefer 64 bit, of course.) I do have the Photoshop CS5 SDK, and Photoshop CS5 itself installed.
Can XCode can be used as an IDE? I'll hand-code a makefile and compile at the command line, if that's easier or the only way possible. If XCode can be used, which project template to use? What is this "Mach-O" I read about, and how does that apply to PS plugins?
It's especially confusing since I'm a total noob at Mac programming of any kind, though many years experienced on Linux and other platforms.
Mission accomplished! (Months ago.. I just realized I had this question sitting here.)
Cocoa is useful for GUI settings windows and other things - it's a huge gob of stuff - but I ended up using it only for the "About" popup window for my plugin.
Completely forget about Carbon for the combination of CS5 or later, OSX 10.6 or later, and 64 bit. Apparently parts of Carbon had been made 64 bit in the past, but should be ignored now.
XCode is a fine editor. Start with a "dylib" project using C. C++ and Obj-C source files can be added without any fuss. There's no way getting around just needing to use XCode for some simple toy projects to gain familiarity with how it organizes things and builds apps and libraries. This is the only real "tool" needed; the rest is APIs - header files and libraries (or "frameworks" in the Apple world). While toying with XCode, get to know what a "bundle" is - a folder containing the executable and other files needed by the app.
Paths need to be set up to the Photoshop CS5 API, there being two or three specific directories to be listed. You may need to copy certain common source files out of the Photoshop example plugins directory, and there was a bit of trouble with a file named MachOMacrezXcode.h about which see What is the meaning of exit code 3 from Rez?
Unfortunately there were no truly useful examples of well-written plugins for CS5 on 64-bit. A combination of the Dissolve example, the SimpleFormat file read/write plugin, browsing source for plugins at http://www.telegraphics.com.au/sw/product/FilterFoundry and asking questions on the Adobe Photoshop SDK forum.
Pay no attention to the clumsy process of using some "Plugin Suite" for obtaining memory. It's like Microsoft's old 16-bit Windows API where you needed "memory handles" and thick malarky that is now several times obsolete. These days, good ol' malloc/free or new/delete are fine.
With all the arrowhead wounds I now have in my back, maybe I should write a book or something...
I want to update my developing knowledge from iOS to Mac for distributing my apps to Mac App Store.
What are the differences? What are the limitations?
For example, if I want to port my iPhone app that syncs contacts with social network the various NSRequest or ABAddressBook are the same? It changes only views and corresponding view controllers?
Does exists some sort of "adapters" from iOS to Mac to easily convert iOS apps to Mac?
In general, what challenges Mac apps arise respect to iOS apps?
Thanks
If you've gathered some experience you will get along with mac development in no time. Mac and iOS have many things in common, however there are some gotchas, not all of which are visible at first glance.
The most obvious difference may be the use of viewcontrollers - cocoa for mac knows viewcontrollers, however they play a different (and less important) role.
I think the best approach for you would be to take a quick look at the Cocoa Application Tutorial and the Cocoa Fundamentals Guide. Most of it will appear familiar to you. Other than that I'd suggest to not port that project over, but use it as a opportunity to learn mac dev and recreate it from scratch (if it is not too complex). Of course you can copy paste many of the logic stuff, no need to reinvent the wheel.
By the way, I started out developing for iOS too and I found it to be very easy to get used to cocoa mac.
As to your question regarding NSURLRequest (I think that's what you meant, theres no NSRequest in either platform), they are almost the same. Just look it up in the reference library. I found it very helpful to have the iOS and mac os reference library available at the same in my browser, so I could look up differences quickly.
I'm quite new to the Mac but reasonably expirienced with windows.
What I need is a window owned opened and closed by the library (dylib).
This is very easy to do in MS Windows but seems not be hard under Cocoa.
I used the code from apple's 'CocoaInCarbon' example with C++ Wrappers.
But the NSApplicationLoad() followed by [NSBundle LoadNibNamed:#"MyWindow" owner:self] fails. Is this caused by the dylib not being a bundle.
Are there alternative ways to open and control a window within a dylib?
Yes, the problem is that it's not a bundle; your nib can't possibly be inside a bundle that doesn't exist, so how would the code find it to open it?
You need to either use a framework (which is a bundle), and ship the nib in that framework, or you need to create the entire window programmatically in your dylib.
It's not a standard practice to just ship dylib on Mac, when the shared library is not very low level and involves GUI in particular. You package it into a framework, so that it can not only have codes in it, but associated resources (nibs, images, sounds) in one place.
Read this Apple document to understand what's going on and how to prepare it. Or, take a look at /System/Library/Frameworks/ to see how the OS X itself provides libraries.
I'm trying to find an all-in-one IDE for flash, one that can deal with various flash related files.
I just read this answer and it recommends fdt, but seems fdt can only deal with scripts but not .fla ones.
Which IDE should I use so that I can use it to develop various files involved in flash developing?
I am fairly certain it can not. Is there any particular reason you need this? Most developers code in external .as files. This way code is in one location and not buried in the timeline. Also the code can be placed in source control.
For an all in one solution, Adobe Flash CS5 is probably your best bet. They have somewhat improved the IDE and added things like autocomplete.
Flash Builder 4 and Adobe Flash CS5 have finally solved this problem - you can now create an FLA in Flash and then use the wizard to easily create a Flash Builder project around the .fla. All of your classes have access to library exports etc, and you can set it up so that when you click to edit a Class file in Flash it automatically opens the file in Flash Builder.
I really like it.
I developed a command line application, whose binary runs in Linux, Windows and Mac OSX. It reads some text input files, but I realize that some special users can not handle this. I would then like to build some kind of graphical interface, where the user only finds buttons and scroll bars for selecting the input parameters, a big "run" button, and then it reads the output of the program and makes some figures.
I also need that everything gets finally packed in a single file, which uses only static libraries, so the user just needs to copy the file to his/her machine and run it.
I would like to know what is the best open source and multi-platform approach to do this. 10 years ago I played a bit with something similar on DEC machines, so I guess that nowadays the situation has probably improved a bit.
P.S. For designing the graphical interface, I am looking for a graphical approach, where you add buttons, scroll bars with the mouse
P.S. 2: the interface is really simple, just need less than 10 buttons, 5 text fields and 2 scrolla bars
Thanks
For advanced UIs, I would generally recommend writing a different UI for each platform (since each platform has its human inteface guidelines). However, is this going to be a simple UI, then one of the cross-platform UIs.
You also didn't mention what language you want to use.
Lastly your "1 exe file" is a bit of a myth - it applies only to Windows. On MacOSX, we use the magic app folders, so it doesn't matter how many files comprise your app, you still get drag-n-drop installs.
Look into GTK+ which originated on Linux, or wxWidgets.
Tcl/Tk is a perfect choice. No other language provides as good of a deployment solution. You can create a virtual filesystem that has your application along with icons, sound files, etc into a single file for each platform (called a 'starpack'). You can even include binary executables and libraries, though those have to be copied to the actual filesystem at runtime to be used.
You also have the option of a two-file deployment -- a platform-specific runtime called 'tclkit', and a platform-independent application file called a 'starkit'. The one starkit will work on all platforms without recompiling, rebundling, etc. It can even have platform-specific parts built-inside and chosen at runtime.
A professional Tcl/Tk developer could do a front end to a command line program in a day without a graphical GUI design tool, easily. If you're new to tcl it will obviously take longer, but that is true of any language. The point being, Tk is remarkably easy to use and doesn't require a graphical GUI designer.
For a cross platform UI, you can use GTK (if using C) or QT (if using C++).
If you can live with a rather huge application package to deliver be sure to look at https://electronjs.org/ You can keep your functionality in your commandline apps and build a modern look and feel UI using HTML5 CSS JS and before thinking "this is ridiculous" consider that Microsoft's Visual Studio code is built on this and compared to GTK / wxWidgets you can do wonders with this. It isn't even hard to do but you either love it or hate it. I'm still undecided...