I have to port an iOS application to OS X. I have a little experience with iOS (although I didn't write the applications) and I would like have some suggests.
1) The application has some nice animations -- should I use Quartz to do them on OS X?
2) How can I change the View to have the same effect as the UINAvigationController on OSX? I searched for this component in the Object Library inside Interface Builder but I didn't find it.
This is liable to be quite an involved process, as (for example) none of the UIKit classes (currently) exist on Mac OS X.
As such, it's likely that you'll only be able to meaningfully retain the model level classes and that a substantial amount of the remaining code may need to be re-written.
My suggestion would be that you thoroughly prepare checklist that contains all tasks. It is not that simple as just looking for equivalent classes in Application Kit to UIKit classes.
it also depends on how app is written. If it has followed MVC properly, then complete files of business logic can be taken without any problems. If not, you will more or less write your new mac app from the scratch.
Yes, Core Animation is always a way to go in this cases, but it may happen that you'll encounter a lot of work because of possible different dimensions.
UINavigationController is something that doesn't exist on "normal" desktop interfaces. The closest equivalents are tab menus/tab sheets and you know how different they are.
If I were you, I would focus on binging content on the Mac, forget about interface concepts from iOS and rather make new interface concepts on the Mac that are compliant with Apple guidelines.
Related
Suppose I want to design a master detail application, Xcode6 master-detail project template for universal app includes UISplitViewController and splitViewController is new in iOS8. I want to support app for iOS7 also.
In general
What is the best way to design an universal app using Xcode6
storyboard that support both iOS8 and iOS7 ?
Is it better to use separate story board for different OS version ?
What are the best practices we should follow to make app compatible with both OS?
The 'best way' to create such an app will likely depend on what exactly your app needs to be able to do. Some ways will be better than others depending on any special behavior needed.
But it is definitely possible to use a single Universal storyboard in Xcode 6 that uses Size Classes and still target iOS 7, both iPhone and iPad, using UISplitViewController. I have successfully done just that. It did take a lot of work to ensure it worked properly and looked consistent on iOS 7 and 8. You have to be a little careful when it comes to performing the various new adaptive segues, as that is a huge difference between iOS 7 and 8. For example, detecting when you have a popover is going to require some work for the two different OSes, handling unwind segues will require some special handling, etc. It will require a lot of testing. Dedicate time to testing the iPhone 6 Plus - in landscape it will show both the master and detail on screen, but you can have control over that.
After going through that experience, I would much rather implement a single storyboard as opposed to two storyboards, one for each OS, and definitely stay away from creating a storyboard for each OS and then one for each device type.
You'll want to read up on the SDK Compatibility Guide to learn how to detect API availability. If you implement an API that doesn't exist on iOS 7 the app will crash, so you need to only run that code if that function exists for the OS the app is running on. For example, you may want to utilize the new UIBlurEffect API, but that doesn't exist on iOS 7. Gain an understanding of what deprecation means, and knowing what has changed in iOS 8 will greatly help. For example, the rotation APIs are deprecated in favor of Size Class trait collections, but those aren't available on iOS 7 so you'll need to continue to use the deprecated rotation API.
Also check out some WWDC videos from this year. They have a couple videos that discuss the new adaptive segues and Universal storyboards. Note that these storyboards ARE backwards compatible with iOS 7, but there are some size classes that aren't made available on iOS 7. See this question and the answer I provided for more information. WWDC videos from previous years also discuss how one can support multiple OSes, progressive enhancement, etc.
And of course when you have questions/problems Stack Overflow is a great resource. A lot of the questions I've posted in the past few months are related to this topic exactly, how to modify UISplitViewController behavior, obtain support for both OSes, using a single storyboard and the new adaptive segues, etc. You may wish to read through those to get an idea of what you can expect to run into when developing an app in the same fashion.
I'm an experienced iOS developer but have not touched OSX development. I plan to port my iOS app to OSX. Of course, there will be certain differences based upon the obvious design paradigm and differences in SDKs, but I could easily see 80-90% of the code being identical, even including a lot of the UI. Is there any good approach for maintaining one code set that powers both apps? Of course, I could do some sort of static library, but I'm wondering if there is a complete solution, and/or advice on what pitfalls I might encounter as a new OSX developer...
Check out http://chameleonproject.org/, "a drop in replacement for UIKit that runs on Mac OS X".
Alternatively, you could have two different targets in your Xcode project, one for iOS and the other for Mac, then include the overlapping code files in both your iOS and Mac targets.
It appears the language is the same for either device ios or mac os on a mbp, but if I learn Objective-C in a tutorial, won't I also need to learn cocoa or cocoa touch to program effectively?
I'm not sure how to start on my path of learning to program an ios device. I know I need to learn objective-c and that appears to work on all apple products. Then do I move to cocoa touch for ipad and iphone? What comes after objective-c?
The type of project is akin to a web app but native objective-c app instead. Have ui, buttons, the app hits some back end location, returns data, I put it on that same ui. Only, as stated, use objective-c and whatever framework and library to do it (that's my dilemma. I dont know what to do next after objective-c).
thanks.
Cocoa and Objective-c go hand in hand. For getting started, I would suggest going over some old WWDC footage and following some of the examples there.
As far as Cocoa and Cocoa touch are concerned, they are very similar in many aspects, same name conventions, similar structure, etc. Learn one, and you can easily pick up the other.
#craig adds:
I would further this answer by also mentioning that Objective-C is a programming language, while Cocoa/Cocoa Touch are collections of frameworks that are provided by Apple, and used by developers to add functionality to their programs. (Which are written in Objective-C.) The Cocoa frameworks contain various UI components like buttons, table views, sliders, etc. in addition to various fundamental classes like NSString and other text- and graphics-based APIs
I started my learning by watching thenewboston's xcode tutorials:
you can begin with this one
Good luck :)
I prefer books for some strange reason and I found that the Apress series of IOS development is really good. The book goes through developing iPhone and iPad apps using all kinds of Cocoa libraries. There's a lot of good books out there on the subject; I would go find one that looks like it would suit your needs.
I've started programming on Mac OS X in Objective-C and decided to create a little card game. At first I create a command line version. If everything works fine I would like to implement a GUI: Nothing big, just a green window with cards which can be dragged and dropped.
Since I don't have any idea about how to do this: What can I use to implement my card game GUI?
Since Objective-C and Cocoa looks like a "bundle" on Mac OS X, is it possible to use Cocoa for this (and how)? If not, what else should I use or is there already sth. like this?
Regards,
inno
Apple has some sample code here that could point you in the right direction.
This is a fine study in MVC.
Your Model (an active game, player and non-player characters, the cards in the game, etc.) will be entirely in Foundation, at least at first. You can add AppKit-dependent properties such as images later, and use the C preprocessor to conditionalize that code if you want to continue maintaining your command-line program.
Your Controllers will also generally be in pure Foundation. I say “Controllers” because you'll have one for both programs (owning the model, responding to user actions, and running the game—that is, dealing cards, enforcing the rules, etc.), one specifically for the command-line program (holding the readline/output loop), and at least one specifically for the GUI program (owning the game window).
In the GUI app, you'll write your Views with AppKit, of course. In the command-line app, you may want to make a View class, separate from the Controllers, to make it easy to radically change the output quickly (even at runtime, if you want to allow that). Of course, that View will not descend from NSView, and will use terminal output instead of graphical drawing.
I recommend keeping the command-line version of the program alive after you make the GUI version, at least for a little while. You'll know you're doing it right when you can maintain both working versions of the program without much fuss, and even find a bug in one version of the program and fix it in both.
I would prefer to create my interfaces programatically. Seems as if all the docs on Apple Developer assume you're using Interface Builder. Is it possible to create these interfaces programatically, and if so where do I start learning about how to do this
I thought the relevant document for this, if possible would be in this section: http://developer.apple.com/referencelibrary/Cocoa/idxUserExperience-date.html
I like the question, and I'd also like to know of resources for going IB-less. Usefulness (the "why") is limited only by imagination. Off the top of my head, here are some possible reasons to program UIs explicitly:
Implementing a better Interface Builder.
Programming dynamic UIs, i.e., ones whose structure is not knowable statically (at compile/xcode time).
Implementing the Cocoa back-end of a cross-platform library or language for UIs.
There is a series of blog posts on working without a nib and a recent description by Michael Mucha on cocoa-dev.
I would prefer to create my interfaces programatically.
Why? Interface Builder is easier and faster. You can't write a typo by drag and drop, and you don't get those oh-so-handy Aqua guides when you're typing rectangles by hand.
Don't fight it. Interface Builder is your friend. Let it help you.
If you insist on wasting your own time and energy by writing your UI in code:
Not document-based (generally library-based, like Mail, iTunes, iPhoto): Create a subclass of NSObject, instantiate it, and make it the application's delegate, and in the delegate's applicationDidFinishLaunching: method, create a window, populate it with views, and order it front.
Document-based (like TextEdit, Preview, QuickTime Player): In the makeWindowControllers method in your subclass of NSDocument, create your windows (and populate them with views) and create window controllers for them, making sure to send yourself addWindowController: for each window controller.
As a completely blind developer I can say that IB is not compatible with VoiceOver (the built-in screen-reader on OS X).
This means that without access to robust documentation on using Cocoa without IB I cannot develop apps for OS X / iPhone in Cocoa, which means I (ironically) cannot easily develop apps that are accessible to the blind (and all others) on OS X / iOS.
My current solution, which I would prefer not to use, is Java + SWT, of course this works for OS X, not so much for iOS.
In fact IB becomes totally unusefull when you start to write your own UI classes. Let say that you create your own button that use an skin system based on a plist. Or you create an dinamic toolbar that load and unload items based on user selection.
IB doesn't accept custom UI elements, so more complex UI can't use him. And YES you will want to do more complex things that the UIKit gives you.
Though this is quiet a bit old...
I tried many times to do everything only with programmatically. This is hard, but possible.
Update:
I posted another question for this specific issue: View-based NSOutlineView without NIB?, and now
I believe everything can be done in programmatical way, but it's incredibly hard without consulting from Apple engineers due to lack of information or examples.
Below argument might be off-topic, but I like to note why I strongly prefer programmatically way.
I also prefer programmatic way. Because
Static layout tool cannot handle anything dynamic.
Reproducing same UI state across multiple NIBs is hard. Everything is implicit or hidden. You need to visit all the panels to find parameters. This kind of job is very easy to make mistake - mistake friendly.
Managing consistent state is hard. Because reproducing same look is hard.
Automation impossible. You cannot make auto-generated input form.
Parameter indirection - such as variable element size chosen by user - is not possible.
Aiming small point is a lot harder than hitting finger sized keys at fixed location - funny that this is serious usability issue for developers!
IB sometimes screws. Which means it's compilable, and still working, but when I open the source, it looks broken and extra editing becomes impossible. (you may not experienced this yet, but if XIB file goes complex, this must happen)
It's image based serialization. The concept is good. But the problem is image-base only. IB doesn't keep the source code for clean boot by replaying the source code. Clean boot is very important to guarantee specific running state. Also, we cannot fix the bugs in source-code. Bug s just will be stacked infinitely. This is core reason why we cannot reproduce the equal(not similar looking) UI state in IB.
Of course these stuffs can be solved by post-processing NIB UI, but if we have to configure everything again, there's no reason to use IB at first.
With text code, it's easy to reproducing the same state - just copy the code. Also easy to inspecting and fixing wrong part - because we have full control. But in IB, we have no control on hard-core details.
IB can't be ultimate solution. It's like a Photoshop, but even Photoshop offers text-based scripting facility. GUI is a moving program, and not a static image or graphic. An IB approach is completely wrong even for visual editing of GUI. If you're one of the Apple folks reading this, I beg you to remove whole dependency to IB completely ASAP.