How to use UIKeyboardAppearanceDark with SLComposeViewController?
The SLComposeViewController class presents a view to the user to compose a post for supported social networking services.
SLComposeViewController *controller = [SLComposeViewController composeViewControllerForServiceType:SLServiceTypeTwitter];
[self presentViewController:controller
animated:YES
completion:nil];
SLComposeViewController Class Reference
Ugly!
This is how the light keyboard looks with a dark background:
Mockup!
This is how the dark keyboard looks with a dark background:
I have tried a few methods. The only way that I found working is to customize the entire ComposeViewController. I also believe it is the only possible way.
I found an open source project calls REComposeViewController and I customized it to have UIKeyboardAppearanceDark by default. I have uploaded to Github you can download and play with it.
Project: https://github.com/voyage11/SLComposeViewControllerWithBlackKeyboard
Attached Screen shot:-
After carefully understanding the problem you are facing and doing some R&D, I'm suggest you to go for Custom ComposeViewController, because you can't change the keyboardAppearance of ComposeViewController's keyboard.
For implementing Customize ComposeViewController follow the below steps:
1) Made some custom view like SLComposeViewController's View.
2) On the post button you need to implement the logic in SLComposeViewControllerResultDone
[_shareComposerSheet setCompletionHandler:^(SLComposeViewControllerResult result)
{
switch (result)
{
case SLComposeViewControllerResultCancelled:
break;
case SLComposeViewControllerResultDone:
{
}
break;
default:
break;
}
}];
3) And when you wants to show your custom view, make sure that the textView you are using in the custom view must be assign keyboardAppearance's property to UIKeyboardAppearanceDark
self.yourTextField.keyboardAppearance = UIKeyboardAppearanceDark;
Below is the picture of customize view, that I implemented in a my recent project.
Hopefully it will helps you.
This is a private class, thus your only chance is to traverse view hierarchy after SLComposeViewController has loaded its view, find corresponding UITextField and set keyboardAppearance to UIKeyboardAppearanceDark
Update scratch that, even traversing view hierarchy would be tricky (impossible) since it uses XPC and remote views.
You can use this code
self.yourTextField.keyboardAppearance = UIKeyboardAppearanceDark;
Related
I am sure the answer to this is "no" as the documentation is very clear. But I am a little confused. A standard UIAlertView is pretty dull and I want to improve the look and it seems that other apps do it (see the example below).
Another possibility is that they are not subclassed UIAlertViews. In which case, how is this achieved?
The page UIAlertViews states
Appearance of Alert Views
You cannot customize the appearance of alert views.
So how do we get the something like the example shown here?
No, do not subclass it. From the docs:
Subclassing Notes
The UIAlertView class is intended to be used as-is
and does not support subclassing. The view hierarchy for this class is
private and must not be modified.
What you can do though is create a UIView and have it act similar to a UIAlertView. It's isn't very difficult and seems to be what they are doing in your op.
Apple's docs say that you should not subclass it. That means that there are probably internal reasons that would make it difficult to make it work right.
You might or might not be able to make a subclass of UIAlertView work, but you do so at your own risk, and future iOS releases might break you without warning. If you tried to complain Apple would laugh and tell you "I told you so".
Better to create a view that looks and acts like an alert but is your own custom view/view controller. Beware that even this is dangerous, because Apple has been making sweeping changes to the look and feel of it's UI elements recently. If you implement a view controller that looks and acts like a variant of the current alert view, Apple could change that look and/or behavior in the future and your UI app would end up looking odd and outdated. We've been bitten by this sort of thing before.
Rethink your strategy. Why do you need to use an Alert View? Besides having a modal view displayed top-most on your view stack, there's not much else that it does. Instead, subclass UIView or UIViewController to define your own interface, using images and ui elements to give it the style and input functionality as needed.
I usually subclass UIView, and attach it to the app's window's view so that I'm certain that it will be displayed on top of anything else. And you can use blocks to provide hooks into the various input elements of your new view (did user press OK, or did user enter text?)
For example:
// Instantiate your custom alert
UIView *myCustomAlert = [[UIMyCustomUIViewAlert alloc] initWithFrame:CGRectMake(...)];
// Suppose the new custom alert has a completion block for when user clicks on some button
// Or performs some action...
myCustomAlert.someEventHandler = ^{
// This block should be invoked internally by the custom alert view
// in response to some given user action.
};
// Display your custom alert view
UIWindow *window = [[UIApplication sharedApplication] keyWindow];
[window addSubview: myCustomAlert];
// Make sure that your custom alert view is top-most
[window bringSubviewToFront: myCustomAlert];
Using this method, however, will not pause the thread's execution like UIAlertView does. Using this method, everything will continue running as usual. So if you need to pause execution while your custom alert is showing, then it gets much trickier.
But otherwise, creating your own custom alerts is quite straightforward, just as you would customize any other view. You could even use Interface Builder.
Hope this helps.
No. You absolutely should not subclass a UIAlertView for any reason. Apple explicitly states this in their documentation (see "Subclassing Notes"). They even tell you that it relies on private methods - and we all know that meddling in private methods in an AppStore app is immediate grounds for rejection.
HOWEVER, there isn't a need to subclass UIAlertView on iOS 7. Apple introduced a new Custom ViewController Transitions feature in iOS 7.0 that lets you present completely custom ViewControllers with completely custom transitions. In other words, you could very easily make your own UIAlertView or even something better. There's a nice tutorial on the new feature here:
In fact, there are lots of good tutorials on this - a quick Google search on the topic turns up a huge wealth of information.
Today's trend in apps includes flat designs, and now I am doing an app that follows with this trend. My problem now is how to create a UIAcionSheet that match with my App Screen's flat UI Design. In relation with this, I saw Instagram's action sheet and I found it interesting. I wish to have that design in my app. Anyone knows how to implement this in ios apps? I have provided a screen shot from instagram app.
You can use RDActionSheet from git
https://github.com/reddavis/RDActionSheet
I hope it will help you..!!
yes,
you can use https://github.com/reddavis/RDActionSheet and also u can change image and color of text and background image of action sheet
You can use FlatUIKIT from Git
https://github.com/Grouper/FlatUIKit
Go through the documentation & you will know how to use it. Awesome collection of Flat UI classes.
You can create a subclass CustomActionSheet derived UIActionSheet,
and create a method called CustomUI in it. Design your code here.
use CustomActionSheet like UIActionSheet, except must call method CustomUI of subclass in willPresentActionSheet delegate:
- (void)willPresentActionSheet:(UIActionSheet *)actionSheet {
if ([actionSheet isKindOfClass:[CustomActionSheet class]]) {
CustomActionSheet *sheet = (CustomActionSheet*)actionSheet;
[sheet CustomUI];
}
}
I'm trying to add a Modal ViewController to the existing application. To init and open it I use the following code
AddedViewController *addedOne = [[AddedViewController alloc] init];
[self.parent presentModalViewController:addedOne animated:YES];
If AddedViewController.xib with a View inside of course is just empty it opens nicely,
but
This throws SIGTRAP signal ((lldb) in log) at loading if AddedViewController.xib is not empty (i.e.) even if I add just a UILabel with static text there.
How can I handle this to have fully-operational ViewController (with labels, buttons, textfields, etc.. open properly?
========
UPD.
Problem easily resolved, see my answer below. =)
Assuming you are trying to present this inside the current view, you should not use self.parent and just use self.
The answer was in Use Autolayout checkbox for the ViewController settings, now everything works fine TWIMC. =))
What ways are there to change views other than using a navigation-based app? I want my first view to be basically just a simple form and when the user hits a "submit" button I want to send him over to the main view, without being able to return. And I don't want the bar on the top of the view either.
How can I achieve this, and if possible without losing the animations that come with a navigation-based app.
If you wanted your app to be entirely navigation controller free, you can use one of the signatures of presentModalViewController:animated: from whichever UIViewController you deem best fit to be the parent. Call [self dismissModalViewControllerAnimated:YES] on the child view (form you want submitted) after you've handled state change on submit. One thing to watch out with this, is as of iOS 5, Apple now prefers that you use presentViewController: instead, and presentModalViewController: is marked for deprecation at a future date.
In terms of "how you would know the user submitted the form, so they may now proceed in your application" - one way you could do that is to use delegation / notifications to maintain awareness of the state of the form. When the child form is submitted, you can call the parentViewController's delegate callback to set flags - or return authentication data, for example - in your AppDelegate or some high-level class. Delegation and Notifications are useful tools when using the iOS SDK.
Option two could be using a completion handler in with your call to present the child, such as:
ChildForm *childFormWithSubmit = [[ChildForm alloc] init];
[self presentModalViewController:childFormWithSubmit animated:YES
completion:^(/*inlineFunctionParams*/)
{ /*inlineFunctionBodyToRunOnCompletion*/ }];
Lots of possibilities ~
Did you look at 'presentViewController:animated:completion:' in the UIViewController class description? There are lots of options for how you animate in another viewController.
Sled, you can simply just hide the UINavigationBar for your UINavigationController.
That way you won't see the UINavigationBar and the user will not be able to return back to that page.
You'll need to set a permanent flag in your app either writing to text file or using NSUserDefaults.
It seems like I am not able to change the title on the navigation bar, which gets set to the Subject of the email (in this case "My Subject"). In this case I'd like to get rid of the title, either using an empty string as title or rendering the title invisible.
MFMailComposeViewController *mfViewController = [[MFMailComposeViewController alloc] init];
mfViewController.mailComposeDelegate = self;
[mfViewController setSubject:[NSString stringWithFormat:#"My Subject"]];
[mfViewController setMessageBody:[self emailBody] isHTML:NO];
[mfViewController setTitle:#""];
where u have presented ModalViewController
[self presentModalViewController:controller animated:YES]; // Existing line
add
[[[[controller viewControllers] lastObject] navigationItem] setTitle:#"Set the title"];
I believe this is some kind of protection came with iOS4.
It is clearly stated here that you MUST NOT change the interface provided by Apple.
http://developer.apple.com/library/ios/#documentation/MessageUI/Reference/MFMailComposeViewController_class/Reference/Reference.html
Important: The mail composition interface itself is not customizable and must not be modified by your application. In addition, after presenting the interface, your application is not allowed to make further changes to the email content. The user may still edit the content using the interface, but programmatic changes are ignored. Thus, you must set the values of content fields before presenting the interface.
i have searched the forums and some have got their app rejected, so i guess u should refrain urself from doing this.
hope it helps. happy coding :)