I want to use this open-source component:
https://github.com/CEWendel/SWTableViewCell
On iOS 7 ++ works fine, but on iOS 6 it crashes.
I need to know if there is any built-in macro that will allow me to do something like this:
#if __CURRENT_IPHONE_OS_VERSION >= __IPHONE_7_0
#import "SWTableViewCell.h"
#interface PPTimerCell : SWTableViewCell
#else
#interface PPTimerCell : UITableViewCell
#endif
Thanks in advance!
As noted in comments, #if is a compile-time condition, not something that applies at run time. If you want to continue with your direction, you'll need a way to vary behavior at run time.
What do you mean, "If I want to continue?"
Also as noted in comments... is it really worth the extra development, maintenance, and support effort for this issue for the small number of users not on iOS 7.0 or later? Apple's latest usage statistics say that number is 4% (and most likely shrinking). You might have an easier time just cutting 6.0 support.
Note also that the swipe-for-actions functionality provided by SWTableViewCell is built-in on iOS 8. You could reduce your dependency on third-party code by just doing swipe actions on iOS 8 with the built-in API. (Not saying you should, just that it's worth considering how you spend your development/QA resources.)
Okay, so how do I change table cells at run time?
The general case of varying a superclass at run time is hard — see further down if you must. But you're doing this for table cells — a table view can easily have the class of each cell set at run time. You could refactor your code so that you instantiate a UITableViewCell subclass on one OS version and a SWTableViewCell subclass on another — and instead of duplicating the code that'd be shared by those classes, put that code in a third class, an instance of which is referenced by each of the other two.
But that's too easy. I have no fear, show me the crazy stuff!
So you're looking for a general solution to the conditional inheritance problem? Well, that gets into dark places real fast.
If you were working with a class that'd be present (i.e. linked) on one version of iOS and not on another, the compiler's #compatiblity_alias feature might help you. This declares one class name as a substitute for another — a couple of years ago it was handy for using third-party libraries like PSTCollectionView as a backward-compatible replacement for UICollectionView, but that was introduced in iOS 6 and nobody's seriously trying to go back to iOS 5 anymore. Anyhow, since #compatibility_alias depends on symbol linkage, to use it in your case you'd need to make the linker bring in your library on iOS 7+ but not on iOS 6, and I don't think that can be done.
If you really want to create a class whose parentage can be different at run time, you'll have to create that class at run time using the ObjC runtime API. Call objc_allocateClassPair to create the class. Beware that working with the ObjC runtime is not for the faint of heart, though there are some good writeups on it out there. Again, though, you probably don't want to do this.
Related
I work with an App that's 100% Objective-C and I'd like to start transitioning over to include Swift. Due to the size of the codebase, it's unrealistic that I'll have a 100% Swift app anytime soon.
As soon as a swift file is added, I noticed that the app size increases because now, the app needs to the include Swift run-time.
How else does things change? As soon as you include a Swift file, what is the process that the compiler and linker undergoes to ship a binary that is now multiple language & related frameworks?
Are there any other caveats in transitioning into a mixed language world in a somewhat large codebase?
In my experience, it works surprisingly well. It is advisable however, to wait to Xcode 7 / Swift 2.0 / Objective-C with generics support as that will eliminate a round of updates, allow you to interop from Objective-C with more elegant Swift code, and eliminate the Swift RT linking concern now that they have stabilized the runtime.
Aside from that, both compilers need to run, Swift first, Objective-C second, the swiftc compiler can be pretty fast or really really slow, depending on what innocent and otherwise legal Swift code that you write (this is also true of a Swift-only app of course).
Getting started, you need to read the interop guide, learn how the bridging header works, and are then mostly on your way. I would say that having a mixed app is actually a blessing as you are not pressed to learn and do everything at once. Opinions will vary of course, but this is mine.
We are creating an iOS app that does not look like any other app you would find in the app store.
My question is, am I allowed to create custom components such as header bars, tab bars, tables etc. for my app and not get rejected by Apple when publishing the app to the app store?
Months of thought and planning has gone into the UI and flow of the app, so the user experience would be superb, we're just concerned about how apple feels about custom apps/components like these?
Regards
There's nothing inherently wrong with creating an app that's got a completely different look and feel to everything else.
But what I would advise is that you try to use the built-in components as much as possible. In recent versions of iOS Apple have introduced a number of APIs to let you customise their look and feel significantly, and some of the most innovative UIs out there are simple table and collection views that have been hacked to pieces.
This is because Apple's built in components have logged many hundreds of thousands (if not millions) of hours of real-world testing and use, and are thus vastly more stable and field-tested than a totally custom component. Plus, they often have various built in features (such as a scroll view's bounce) that are hard to replicate on your own.
So definitely customise your interface as much as you like, but while you're doing it think about whether you can harness the built-in UIKit classes rather than totally re-inventing the wheel.
More and more custom controls appear for iOS every day. If it is so good as you say, Apple will be happy to accept it. Don't worry.
Also take a look at these cocoacontrols
As said before, Apple will not have a problem with that .. as long as you don't use any private APIs. If you are developing these components on your own, you will have to make sure that these will work in future releases (which is not necessarily a bad point) . This may be a problem with third party components, as they may not be continued (or supported in future releases).
I'm building an app for which I'd like to reuse 99% of the code in iOS and OSX. Just asking for a sanity check.
(Edit) A bit more information about my project that may affect some of the responses: My app involves a customizable presentation that's primarily intended for iOS devices. The OSX component is actually a designer for the customizable presentation - a way of specifying what is to be presented on a selected iOS device. That is, the OSX app will be a completely normal OSX app that allows the user to choose, configure, and position some elements for the iOS device - and that displays a preview of that presentation. Of course, I want the preview to resemble the iOS rendering as closely as possible (without actually invoking the iOS simulator, which I don't expect to be available on all OSX devices). So I've designed the presentation as a view that should be rendered as-nearly-identically-as-possible on both OSX and iOS.
To this end, I started in iOS with some simple view-drawing stuff, and now I'm reconfiguring the code so that I can port it to OSX. My strategy so far is to replace all references to UIView / UIWindow / UIFont / UIColor etc. with _View / _Window / _Font / _Color, etc. For the iOS version, I'll include a file called Wrapper.h like this:
#define _Device UIDevice
#define _Application UIApplication
#define _ApplicationMain UIApplicationMain
#define _ApplicationDelegate UIApplicationDelegate
#define _Responder UIResponder
#define _Window UIWindow
...with NS-based definitions for OSX (NSWindows, etc.) I know that a few details will change (like Y coordinates in views), but I can deal with that.
The only components that I don't think I can map like that are gesture recognizers, since OSX has no equivalent. I'm planning to make them a generic call that's implemented in the iOS wrapper, and stubbed out in the OSX wrapper, since I really don't need tap events in OSX.
Good idea? Bad idea? Is there a better way to tackle this? Thanks...
My strategy so far is to replace all references to UIView / UIWindow /
UIFont / UIColor etc. with _View / _Window / _Font / _Color, etc.
UIKit is not just AppKit with all the occurrences of "NS" changed to "UI". While there are strong similarities, there are also important differences both in the way the frameworks work and in the way users expect to use software written with each framework. Is it possible to write a single framework that's implemented in terms of both UIKit and AppKit? Undoubtedly, but you'll end up with something that prevents you from taking full advantage of either platform.
Good idea? Bad idea? Is there a better way to tackle this?
IMO, bad idea. If you do a good job designing your data model, you should be able to share that between the Mac and iOS implementations with no changes. Then, instead of spending a lot of time trying to figure out how to write a single user interface and coming up with something that's a compromise on both sides, put that effort into creating separate user interfaces that are compelling on both platforms.
Hello I am building forms over and over in iPhone and iPad apps:
Custom UITableViewCells for labels with input
Localization for labels, placeholder text and section headers
Validation that marks the cells red or something and does not allow "Submit" if form is incomplete
Clicking in the cell activates the editable text box
Next / previous buttons
Reliable across devices, orientations, iOS versions
I can't imagine I'm the only one doing this. Is there a mature framework or something that can drop in and use? Could you please comment on how you use this library with designs other than vanilla UITableViews with your own colors etc.?
Take a look at IBAForms - an open source project from from Itty Bitty Apps. I haven't used it yet myself, however I believe it does most of what you want, except for validation. Here is the github page: IBA Forms
It hasn't been maintained in a while, but if you're looking for a forms library - it's mature and works. At the very least, it could be the starting point for something you take further.
Update: There is also Chris Miles' EZForm library, which is very nice.
Update #2: Have also started checking out QuickDialog, which seems to be very popular.
Update #3: Nick Lockwood has created one called FXForms
Update #4: Martin Barreto has created one called XLForm
I don't know if this counts as an answer, but i use Sensible Cocoa - Sensible TableView (STV) for this purpose a lot. It's not a "forms" framework (on top of UITableView) as such, but it can be used for this purpose in a very flexible way. It still requires some coding to build a full-fledged form but the UITableView/UITableViewController boilerplate code is reduced to a minimum. Unfortunately the developers bumped the price tag quite high with version 3.0, so i'm actually looking for a STV replacement right now. (I'd stick with STV if it wasn't for the price!)
I don't know of anything that combines all those features, but I recently open-sourced my validation library PMValidation on github, which I used developing the iPhone app Imprints. PMValidation comes with many basic types suitable for validating forms, and in fact that's what I originally built it for.
Using the PMValidationManager class you can easily listen to UITextViews or UITextFields, and update whatever graphical widgets you want via notifications. It's very modular and easily extendable, should you have more unique needs. It's under the MIT license.
I have a pretty much standard UITableView, but I would like to change it to look like what would be considered a normal table outside iOS development -- make it have more columns (but just one row) and make the cells square-shaped.
I thought about making more tables (one for every cell) and then placing them next to each other, but that wouldn't be so convenient.
Is there maybe a simple way to make cells go on the right of the one before instead of going below?
Use some third-party classes that allows you to have "Grid Views".
One is my OHGridView class, another is NRGridView, and there are many more. If your app needs to be compatible with iOS4 and/or iOS5, using a third party class (or building one yourself) is the only option.
Under iOS6, there will be some other stuff that allow you to do that directly (iOS6 still under NDA so we can't talk about it publicly yet, but go read the API Diff files in the developer.apple.com website if you have access to them). So if your app is intended to be compatible only starting iOS6+ and you don't need support for iOS5, this could be the solution and you should go read about it if you have a developer account with access to the iPs6 SDK.
What you're looking for us UICollectionView.