MKMapView in iOS 7 - ios

I have a problem with MKMapView in iOS7, I have been using it with iOS5 and worked flawless (at least what Im trying to do).
Well my problem is that .userTrackingMode won't work in iOS7. Been searching for an answer but haven't found any.
I want to show user location, it work fine with .showsUserLocation. But when I want to track it its like it just ignores it. Anyone have a fix?
This is how I wrote it in iOS 5:
mMapView.showsUserLocation = YES;
mMapView.userTrackingMode = YES;
mMapView.userInteractionEnabled = NO;
And what I know there wasn't any changes with the code in the upgrade.
EDIT:
Don't know why but I used
[self.mapView setUserTrackingMode:MKUserTrackingModeFollow animated:YES];
inside a method that change a label every time that the location change. Then its working.
Don't know why it's not working when I declare it in viewDidLoad... ?

Welp, in Apple's documentation for MKMapView, ".userTrackingMode" is not a BOOL but instead it's an "enum" (Integer) property:
typedef enum : NSInteger {
MKUserTrackingModeNone = 0,
MKUserTrackingModeFollow,
MKUserTrackingModeFollowWithHeading,
} MKUserTrackingMode;
Maybe you're setting it wrongly could be part of the problem?
Also, the best way to set it is via this API:
- (void)setUserTrackingMode:(MKUserTrackingMode)mode animated:(BOOL)animated (I've linked the Apple documentation for you). There's a useful "animated" argument there.

Related

MapBox iOS SDK - First steps

I'm having problems taking the first few steps with MapBox iOS SDK (1.4.1).
I've started with the suggested code over here: https://www.mapbox.com/mapbox-ios-sdk/examples/
- (void)viewDidLoad {
[super viewDidLoad];
self.mapBoxView.tileSource = [[RMMapboxSource alloc] initWithMapID:#"my_map_id" enablingDataOnMapView:_mapBoxView];
self.mapBoxView.userTrackingMode = RMUserTrackingModeNone;
CLLocationCoordinate2D centerLocation;
centerLocation.latitude = NRMapStartLatitude;
centerLocation.longitude = NRMapStartLongitude;
[self.mapBoxView setCenterCoordinate:centerLocation];
[self.mapBoxView setZoom:7 animated:YES];
}
No matter what I do the map starts at a location in Washington D.C. but I've set the center coordinate to be somewhere in Europe.
The same with the zoom. No matter what value I try it has no effect on the map.
There's something with the NSLog output that confuses me. At startup it says:
Using watermarked example map ID examples.map-z2effxa8. Please go to
https://mapbox.com and create your own map style.
I was assuming that this is something that I already did by registering for a free account there and starting with my first project.
Added the tilesource 'My First Map' to the container
Origin is calculated at: 120.786199, -85.000000 Map initialised. tileSource:RMMapboxSource:
Mapbox iOS Example, zooms 0-19, no interactivity, minZoom:2.000000, maxZoom:18.000000,
zoom:18.000000 at {-77.032458,38.913175}
Apparently the sample project in the iOS SDK is loaded and ignoring everything else I try to configure.
So, how do I configure the map so I can interact with the API. What am I missing?
Any kind of help is highly appreciated. Thank you!
OK, whoever is struggling with that. The trick is to set the zoom BEFORE you set the center coordinate..
..for whatever reason.

Disabling user interaction not working in SVProgressHUD on iOS app

I've just downloaded SVProgressHUD and incorporated it into my project as explained in the github documentation page, but even if I wrote out [SVProgressHUD showWithMaskType:SVProgressHUDMaskTypeGradient];, it's not different from the default mask type, and when I tapped the screen while the cursor was revolving I got my app crashed - meaning I wasn't able to disable the user interaction feature since my app crashes before showing all of the table view cells there.
And note that clear or black mask type didn't work, either.
So how can I successfully disable the user interaction? And which file of the AppDelegate.m's applicationDidFinishWithLaunchingOptions: and FirstViewController.'s viewDidLoad: should I write the above code?
I use the latest version of the SVProgressHUD and use Xcode 5.1 and iOS 7.1. I also use ARC. Am I missing something?
[Update]
This was a bug issue and it has been resolved in the current version. Check it out on the Github page for the further info.
This is very late to answer but just in case it can help someone because I was stuck with this issue for a while today. If you are using latest classes from github you won't face any issue but if you are using old classes then Replace below method from SVProgressHUD.m as below
+ (void)showWithStatus:(NSString *)status
{
[self setDefaultMaskType:SVProgressHUDMaskTypeGradient];
[self showProgress:SVProgressHUDUndefinedProgress status:status];
}
I am using SVProgressHUD with swift and iOS 10.2 . Just setting mask type
In AppDelegate
SVProgressHUD.setDefaultMaskType(.black) works.
and every time you write
SVProgressHUD.show()
it will show the mask and userInteraction is managed by it.
You're not missing anything. iOS 7 doesn't seem to respect the mask type, so user interaction is never disabled. I think it's a bug with SVProgressHUD rather than anything else. Bit frustrating really.
It can be done easily by doing some changes in SVProgressHUD class:
just put
[self.window setUserInteractionEnabled:NO]; in the last of showprogress with status and put [self.window setUserInteractionEnabled:YES]; in dismiss method.
Objective C (AppDelegate.m)
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
//add this line
[SVProgressHUD setDefaultMaskType: SVProgressHUDMaskTypeBlack];
}

compatibility with automaticallyAdjustsScrollViewInsets

I've been working a little with the new UI options in iOS 7, and the automaticallyAdjustsScrollViewInsets property in UIViewController is really freaking me out. the thing is, either you don't set it, but then you will have to position your scroll views differently in iOS 7 and other iOS versions. the alternative is to set it to NO only for iOS 7 and use the same positioning. I don't understand why apple implemented this property at all, in my opinion, good practice would be always having it to NO (not having such a property at all), just like it was before. I understand that it is easier to use if you are lazy, but this seems like a really bad programming practice in my opinion. am I missing out on something or do you agree?
I don't see any problem. iOS 6 SDK does not contain this property. You just should use following code:
if([self respondsToSelector:#selector(setAutomaticallyAdjustsScrollViewInsets:)])
{
self.automaticallyAdjustsScrollViewInsets = NO;
}

Custom UISwitch bouncing when state changes from on/off - IOS-7 Bug?

I really need some help, since iOS 7 I have had nothing but trouble with UISwitch.
The Problem
After moving the view up when the keyboard is displayed and restoring it to original position, I then turn any UISwitch on/off it will work OK, however it will "Bounce Down" during the animation. this only seems to happen to UISwitch's that have the .thumbTintColor attribute. by that I mean self.borders.thumbTintColor = [UIColor redColor]; when the switch is off and self.borders.thumbTintColor = [UIColor greenColor]; when switch is on.
For clarity everything works well until the moving of the view (I can't not do this as you are not able to see the text field).
I have searched everywhere (including the class reference) and I haven't found anything helpful, or anyone else with this problem.
UPDATE
I have tried setting the UISwitch thumTintColor various ways, everything works fine until I move the view up to compensate for the Keyboard. if I drag the switch either on my iPad or via simulator on and off slowly the "bounce down" occurs halfway and when the color changes from green to red or red to green depending on state, I think this is an actual IOS7 UISwitch Bug. I really do not want to use a third part switch plug in on my app, so not sure what to do now, one would of thought that changing the tint color on the thumb would not have been such a huge problem.
I have tried turning off the animation from on to off - off to on makes no difference.
I have created a new UISwitch via code not IB and the same problem exists.
created a new test app with only a switch and text box to test and the same thing occurs.
Questions
1) My thoughts are this is a genuine bug. How do i log it with apple (never done it before) so if someone can point me to the correct place i would be grateful.
2) I am now thinking of using Buttons as switches, but feel that is not the way to go, are there any practical reasons not to do so i.e problems submitting the app to the App store etc?
I had the similar issue and found a solution. It's a bit hacky but it does the job.
Just need to add a small delay between setting isOn property to On/Off and changing the color of the thumb.
switch.isOn = true
DispatchQueue.main.asyncAfter(deadline: .now() + 0.1) {
self.switch.thumbTintColor = .white
}
Answer 1: Logging a bug with apple can be done via the iOS Dev center (There's a link on the bottom of the page). You can also ask for technical support. Click on the "Developer Support Center" button, then go to "Technical Support (TSI)" (Please note you only have a limited amount that you're allowed to use per year, before you have to buy more).
Answer 2: I think that having two buttons would be a very bad User Interface decision. Apple may reject it because of that (but you never know). I would get the bug report in, and go from there.
Good Luck!
I found interesting solution may be it helps.
NSArray *array = [self.mySwitch subviewsWithClass:[UIImageView class]];
for (UIImageView *imageView in array) {
imageView.image = [UIImage imageNamed:#"Untitled-1.png"];
}
Hear I used method from UIView category
- (NSArray*)subviewsWithClass:(Class)class
{
NSMutableArray *array = [NSMutableArray array];
if ([self isKindOfClass:class]) {
[array addObject:self];
}
for (UIView *subview in self.subviews) {
[array addObjectsFromArray:[subview subviewsWithClass:class]];
}
return array;
}
Image size is {57, 43.5}. Circle radius is 15(with shadow)
I understand that it is not very good way to solve. But if you really need it helps.
Play with images little bit =)

Possible UISwitch bug in iOS7?

I am using a UISwitch to call a subview to screen in my app. However, the switch only works about 60% of the time. To test my code I hooked the switch to another IBAction to write the state of the switch to the console. Both functions are not responding to the state of the switch at certain times, i.e., both functions are ignoring the state of the switch simultaneously some of the time. Has anybody else experienced this behaviour with UISwitches in iOS7?
- (IBAction)showHideSomeSubView:(UISwitch *)sender {
if (_mySwitch.on) {
[self.view addSubview:someSubView];
}
else {
[someSubVew removeFromSuperview];
}}
Edit:
The same switch is connected to the following action:
- (IBAction)switchToggled:(UISwitch *)sender {
sender = _mySwitch;
if ([sender isOn]) {
NSLog(#"On");
} else {
NSLog(#"Off");
}}
Both actions respond in the same way to the switch.
I confirm that weird behaviour with you!!!!
Just drag the little circle of the switch around and around, you will see the action called multiple times (in my case up to 403 :D )
I am really not sure that is what Apple engineers intended to do, because I have not found any documentation about this new behaviour, BTW, if you find one, please let me know too.
Thank you very much
I'm using several UISwitches in an iOS 7 app, I have had no problem at all responding to the Value Changed action. The switch consistently reports its value correctly. You should unhook the switch from its action in IB and then reconnect, making sure you are connecting the Value Changed action.
Yes, with a UISwitch in the iOS 7 iPad simulator, I am seeing 1-12 callbacks to my equivalent of your switchToggled: method. On the last callback, the value has in fact changed. On the previous callbacks, it hasn't. What I am doing is caching whether or not the switch is on. Then in the switchToggled: method, I check whether or not the value has in fact changed. If it hasn't, I ignore the callback. This seems to make things behave correctly for the user.
The problem does also happen on the device, though apparently less often. The same work-around seems to work there.

Resources