When subclassing PFLogInViewController for customization. How do I change the size of the view?
I have looked at this tutorial: https://parse.com/tutorials/login-and-signup-views
but it does not seem to have the answer.
My app is based on a UITabBarController and one of the tabs needs log in.
Nevertheless if the user cannot log in, he should still be able to use the other tabs.
In the present situation, when the user taps on the tab asking for login; he has to log in or kill the app to get out. Because the PFLogInViewController takes up all the screen and there is no way out by hitting a different tab (all covered).
This is obviously not very nice.
How can I keep the tabs at the bottom visible?
I tried to change the self.view.frame or the self.logInView.frame in the viewDidLoad method of my PFLogInViewController subclass, but it seems to have no effect at all.
Then you should make your app so that it doesn't start with the login viewcontroller, but rather opens to the parts that are available to all. Include some button or other mechanic to take the user to the login page.
You could include a button on the login page that says "Use the app anonymously" or similar, which triggers a segue to a main view. On subsequent app launches, the user is taken to this main view immediately. You would still need a way for the user to login later on.
Related
Okay, so I'm building an universal iOS app with an initial login view (view controller named LoginVC), just a plain simple UIViewController. If the login is successful the app segues to an navigation controller (MainNavigationVC). I created this segue through the storyboard gui of XCode, so no programmatic creation of the nav controller is done. The nav controller is presented modally in fullscreen, so the rest of the app is run atop the login view, with this nav controller as the centerpiece of everything.
The navigation controller contains a view (with a view controller named UserStartPageVC), and in its navigation bar is a logout button. This button sends an target action to UserStartPageVC, with the goal of dismissing the nav controller thus bringing the user back to the login view.
So far everything works fine. I can login and use the app as intended. But! When I log out and then re-login XCode tells me this:
Warning! Attempt to present <MainNavigationVC: 0x753110> on
<LoginVC: 0x756fcf0> while a presentation is in progress!
I suppose this means that the login view is trying to modally display a MainNavigationVC navigation controller, but another one is already displayed, right? But how? Can a view be presented without showing?
And how can I get rid of the old nav controller when logging out? I've tried several ways of dismissing the modal view, for instance:
from within UserStartpageVC running
[x dismissViewControllerAnimated:YES completion:NULL]
[x dismissModalViewControllerAnimated:YES]
where x is either self, self.parentViewController or self.presentingViewController.
setting the LoginVC as a property in UserStartpageVC and running
[self.loginVC dismissViewControllerAnimated:YES completion:NULL]
and so on.
All of the tested calls actually brings me back to the login screen, so it's kind of working.
Any ideas? Relevant code samples can be provided if necessary, I just couldn't figure out which pieces that were of interest. The seguing to the navigation controller has no code (except for a performSegueWithIdentifier:sender:), and the code for dismissing it is the part I cannot seem to get straight.
As a sidenote. So far this isn't a REAL problem; the app runs, and it IS possible to logout and re-login without any other side-effects than an error message in XCode. But I suppose this will be a memory leak if users logout and login multiple times, and I'm not in the mood of an unnecessary rejection from Apple.
I discovered another way to get the exact same error message. Lucky me!
If you created a segue at one point and had it tied to a button (click button -> new view) and then later give that segue a name and invoke it directly using
[self performSegueWithIdentifier:#"identifierName" sender:self];
then you can get this error because you can effectively trigger the segue twice. I thought making the button invoke an IBAction would turn off the segue I had set up in the first place, but apparently not. Hitting the button triggered the segue twice, but after I deleted the segue and re-created it as a manual segue on the view with the same identifier then I was able to invoke it via the above code and not get the warning message.
Hoopla! My bad.
Seemed I had set up the notification observing from the login API call in a stupid way. For every time the user triggered a login (or re-login), it added itself as an observer for the notification; the result was that it performed one more segue for every time a login was done.
And doing multiple segues at the same time, is... well, obviously bad.
This is a two part question.
I have created a user agreement that the user must agree to when first launching the app (it is an alert with some information and agree/ do not agree button)
I call upon the method that creates this alert inside myAppDelegate.m and within the method
- (BOOL)application:(UIApplication *)application
didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
The problem is the alert pops up when the splash screen has finished loading and my first view comes up. I want this to happen during the splash screen. How would I do this?
The second question is When the users presses the "Do not agree button", I want them to exit the app so I have programmed it with
exit(0);
Is there a better way and will apple reject my app because of this?
Thanks in advance
1) You can't -- during the splash screen (your default.png) the app is loading into memory, and it cannot therefore execute any code, including presentation of a UIAlertView. That's why you don't see the alert until the splash disappears -- removal of the splash screen is the last thing that the app does before calling applicationDidFinishLoading:withOptions:.
What you can do is create a view controller that mimics your splash screen. This is easy -- you can even reuse default.png as a background if you want, though a better idea is just to present in this first view controller your agreement text and agree/disagree buttons.
As to your question re: use of exit(), it's best to avoid doing that. If the user refuses, you can simply do nothing. Of course, if you go the view controller route as I suggest, you can leave presented another opportunity for the user to agree.
Another thought is that Apple allows you to customize the EULA of your app when you upload a binary -- you could put it there and be covered.
Why not load our default.png as the background of you initial view and just handle the Alert in it's controller. you can always add another view or segue based on the answer.
The problem is the UIAlert blocks the Main thread, so it could stop your app from launching in time, and the process could be terminated.
iPhone/iPad dev newb here...
I am using MonoTouch to create a universal iPad/iPhone storyboard app. In the primary view controller (RootViewController) the default auto-generated behavior is a table with a single cell "Detail" in it, which hardwires you to the next destination (DetailViewController).
I'd like to change this RootViewController to instead show a login control I've made extending UIViewController (LoginView). I have had some success putting the LoginView inside the RootViewController, but can't figure out how to make it 'segue' to DetailViewController. And upon watching how the iPad app works, where there is no segue (that I can see) between the two, am I going about this wrong?
To summarize: How do I enhance this storyboard app with a preceding login screen, reusing its contents/xib between the iPad and iPhone variant?
Apologies if this is a bit unclear and muddled.......
I have not tried a storyboard app in Monotouch yet, but I did spend a lot of time working out the best approach for a login screen for my application. What I ended up doing, which could work in your situation as well, is presenting the login screen as a Modal view. Once the user has successfully logged in, we then push the next appropriate view.
So if you are automatically pushed into the detail view by the storyboard viewcontroller, you could display the login dialog as a modal dialog from the detail view's DidLoad or DidAppear methods.
My iPhone app has a login page (shocker i know) but when the user successfully logs in, I want a view with a tab bar at the bottom to load and populate the buttons with data from the specific user. I can not find any tutorials on the tab bar, just the tab bar controller and from what i've read and seen, you can only have a tab bar controller on the MainWindow.xib. If thats not true, please show me how to have a tab bar controller on a view other that the main window. This is driving me nuts. Beer on me for a solution. Thanks
I have the same exact thing going on in my app and I can sympathize with you. There really isn't much to go on out there.
For me, it starts in your AppDelegate. I would validate the login info there, if it was good, push out the tabbarcontroller. If not, just present the logincontroller instead. It can be a tad tricky, but if you start there, you should be able to use everything else to get what you need.
Use the AppDelegate to determine which controller to push. When you push the login and it is good, call back to your appdelegate to push the tab bar controller and kill off the login.
Hope this helps. Good Luck.
You certainly can have a tab bar controller in other places besides MainWindow.xib. An example of one being created programattically, is in View Controller Programming Guide for iOS. See the section on Creating a Tab Bar Interface Programmatically.
Now, you've probably seen this already, but the point is even though Apple's example is in applicationDidFinishLaunching, you could do it anywhere you launch a view controller, like in response to a button click.
A few things to consider though:
Tab bar view controllers aren't meant to be embedded inside a navigation controller (i believe it would give you errors). it's the other way around is recommended. It might make more sense to present a tab bar view controller modally.
In your specific case, it sounds like the best thing would be to keep it simple by letting the tab bar be the root view controller in the main window after all, and having your login screen be automatically popped up after launch (i.e present it modally) then after proper login, dismiss the log in screen to reveal the tab bar controller that was there all along.
Im looking for some help regarding to put a save like confirmation if some changes where made to a UITextField and UISegmentedControl.
Can I prevent the UINavigationController from pop the view? And then pop based on buttons in a AlertView?
I use the UITextField and UISegmented control to POST data to a webservice.
I perhaps need to use a modalView for this? but wanted first to see if someone have another idea, because I would like to keep navigation clicks down if possible.
Any suggestions for this?
Thanks,
Why not just using a UIAlertView?
EDIT: On second thought, and re-reading your question + comment, I would recommend to use a Modal View with classics OK/Cancel buttons + a UIAlertView(s) for confirmation(s). (UIAlertView "poping" on OK/Cancel is easy to do via UIAlertViewDelegate)
That's what Modal views are for, block UI until some user action has been completed. Like a form. This is how I do all my forms, and how Apple does (just look at the create mail screen for an example, or any form of iOS apps)
Adding a "Magical" action requiring user interaction on the back button of a navigation controller is bad in terms of user experience, if you hit back, you expect the view to pop, nothing else. I would then be surprised if Apple SDK even allows to cancel that event...
You can do what you would like without the need of a modal view.
First, you can use your text field's UITextFieldDelegate to set a flag in your controller when the field content is modified. You can reset this flag when the data is sent out.
Then you could override your UIViewContorller's viewWillDisappear to show an alert to the user in case new data have not been posted at the moment the view is going to disappear and give him the possibility of sending it to the server. This method will be called when you move to a different controller in your navigation UI, and you will not have a chance to "reject" the operation.