Ios8 on A+ programming moments

How to properly share / export GPX files on iOS

Mon, 29 Dec 2014 00:00:00 +0000

In upcoming version 4.1 of my Run 5k app, I’m adding support for exporting data out of the app. I strongly believe that data liberation should exist in all applications and services despite the fact it can require significant amount of time to do properly. In 4.1, you will be able to export complete GPX file for each run you did with Run 5k.

What is GPX

GPX is de-facto standard for exchanging GPS tracks, waypoints, and similar GPS related data between applications and services. It stands for GPS Exchange Format and was created by Topografix. Current version of the specification is 1.1.

Over time, companies like Garmin have added Extensions to the original specification – thus you can include things like heart rate to it. Which all later lead them to create an expanded format called TCX which allows you to transfer many fitness-related bits of information.

How to do it on iOS

The hardest part of the work is already done by Watanabe Toshinori, who created and open-soured GPX framework for creating and parsing GPX formats, plus also a separate Logger and Viewer. If you look at the GitHub profile, you’ll find the same for Google’s KML as well. Truly an amazing contribution to the iOS community and people like Watanabe inspire me to share my knowledge and code.

Sadly, the last Watanabe’s update was 3 years ago and many other developers have taken the mantle and continued to improve the library. Simply pick the one you want, even the original still works just fine on iOS 8.

Once you include the framework in your own app, it’s pretty straightforward to instantiate the whole hierarchy and convert your CLLocation stuff into GPX objects.

How to add GPX support to iOS, system-wide

With that out of the way, the troubling part is how to actually share the file on iOS.
Why troubling?
All file exchanging in iOS is dependent on the OS knowing about the file format in the first place. This is done through Uniform Type Identifier system, or UTI. Read Apple docs or this old Cocoanetics blog post to learn more.

For now, it’s enough to know that in order to attach a particular file to — say Mail message, iOS must have its UTI record. Ideally, you would already have another app that acts as GPX viewer and or editor. Thus the UTI declaration for GPX would already be available to iOS runtime.

By default, iOS installation does not have GPX record and thus you can’t depend on it being there. Hence to successfully export GPX file, you need to add Imported UTI Declaration to your app’s Info.plist file; “imported” means that you are declaring someone else’s file format, in this case Topografix’s GPX. (If your app defines your own custom file format, you would use Exported UTI Declaration.)

This is what you need to add to the end of the Info.plist file:

<key>UTImportedTypeDeclarations</key>
<array>
	<dict>
		<key>UTTypeIdentifier</key>
		<string>com.topografix.gpx</string>
		<key>UTTypeReferenceURL</key>
		<string>http://www.topografix.com/GPX/1/1</string>
		<key>UTTypeDescription</key>
		<string>GPS Exchange Format (GPX)</string>
		<key>UTTypeConformsTo</key>
		<array>
			<string>public.xml</string>
		</array>
		<key>UTTypeTagSpecification</key>
		<dict>
			<key>public.filename-extension</key>
			<array>
				<string>gpx</string>
			</array>
			<key>public.mime-type</key>
			<string>application/gpx+xml</string>
		</dict>
	</dict>	
</array>

This above is the minimum required. I got to this through trial and error, adding one key at the time to see what’s enough. Note that some apps are stricter than others and I found that out of all the system apps Mail is the most strict. For example, you could share – using standard share system in iOS 8 – .gpx file without the public.mime-type key present through iMessage but Mail would simply ignore it. Add that one and sharing to Mail will work (your file will appear as attachment).

I like the sharing mechanism that Apple is building with iOS 8 through UIActivity* APIs and I’m adding support for it in all my apps, as appropriate for each one.

GPX file is perfect candidate for lazy-creation share mechanism, since it can take a while to be created. If you do it before the share sheet is even shown, you could potentially stall your UI for seconds.

Thus you need to subclass UIActivityItemProvider and implement just these two methods as minimum:

 - (id)item {

	NSString *filePath = [self.activity saveToFileGPXString:[self.activity getGPXString]];
	if ([filePath length] == 0) return nil;
	NSError *error = nil;
	NSData *fileData = [NSData dataWithContentsOfFile:filePath options:NSDataReadingMapped error:&error];
	if (error) {
		NSLog(@"Error reading GPX file:\n%@", error);
	}
	return fileData;
}

 - (NSString *)activityViewController:(UIActivityViewController *)activityViewController dataTypeIdentifierForActivityType:(NSString *)activityType {
	
	return @"com.topografix.gpx";
}

First method generates GPX file and saves it to some folder and then streams it using dataWithContentsOfFile:options:error. (You can also send NSData from the memory, bypassing the file system.)

Second method is key: you must tell the sharing mechanism what kind of file is it, using UTI you declared in your Info.plist file. If you don’t, Mail will again ignore the file (while Messages will still attach it).

The only part I could not figure out is how to name the file - both Mail and Messages ignore the file name and display Attachment-1.gpx. (blah)

So, there you have it. Nice thing to do is to also include (NSString *)activityViewController:(UIActivityViewController *)activityViewController subjectForActivityType:(NSString *)activityType and return nice, informative subject, which Mail app will read out and save your customers some typing.

Real-time inter-app communication

Mon, 20 Oct 2014 00:00:00 +0000

Or more like “real-time”, (near)real-time or whatever modifier you prefer.

App Extensions are the new shiny in iOS 8 and one that interest me the most, especially in the fitness area. Here’s why: I use my iPhone as the core device of my entire business hence I have lots of sensitive personal and business data on it. Thus it’s natural that I have all possible security features turned on. Passcode is set, TouchID is on, instant lock with no grace period etc.

This presents an issue when I go out to run with my iPhone. I don’t usually run with an armband (only in races) thus the iPhone is usually in my pocket. From time to time tough, I would like to check the parameters - heart rate, distance, pace etc. In reality, this means that I should:

dug it out from the pocket
unlock – Touch ID is not always reliable with sweaty fingers (at least on 5s), so it means type out the passcode
back into the pocket

Step no. 2 is what bugs me and where extensions come into play. If I have to slide to the left for the passcode screen, then I might as well slide from the top and get the info I need from the Today widget.

That’s the thought process that ended with: iOS 8 version of Run 5k will have Today widget that’s (more or less) a replica of its running view.

The only problem to solve is - how to communicate app status between the main app and the widget, in real time?

Idea 1

NSExtensionContext seems like a proper place to give us means to shuttle data and state back and forth, but it’s a non-starter. It’s simple and very limited class and there’s nothing in it to allow real-time communication.

Maybe in iOS 9.

Idea 2

File-based, on disk. Main app would write data into it, widget would read from it. However, widget might also need to write some data, for example to alter running state: I may want to temporarily pause the run.

Thus you need to carefully coordinate reads/writes and to resolve the potential lock-ups. Given this and also the fact that it’s a file I/O, the real-time may become far less real then I would prefer and it could actually lead to widget lagging behind actual app state.

I may be wrong and it could turn out to be performant enough. Would love to hear about it, if you have experiences.

Idea 3

App-specific UIPasteboard. It’s all in memory, so no slow I/O to speak of. Idea is that I would write my items into the pasteboard from the app, widget will read them. There is no limit what you can place in the pasteboard, but just be careful it’s not a lot of data - memory warnings are not far off in the 1GB RAM devices we still work with.

This is what I chose to go with.

My first approach was whenever the app writes into the pasteboard, UIPasteboardChangedNotification is fired and I’m using that to trigger widget layout/display. However, even with this:

[[NSNotificationCenter defaultCenter] addObserver:self
										 selector:@selector(handleNotification:)
											 name:UIPasteboardChangedNotification
										   object:nil];

Widget’s handler is never called. And that’s really annoying, as I had to resort to polling the UIPasteboard repeatedly. Still testing it out, but I don’t like it, it seems wasteful.

Maybe I’m doing something wrong, still working on it.

Idea 4

Local socket communication..? I have almost non-existent experience with these, so can’t properly investigate. No idea what’s possible to do, will iOS even allow direct communication between two apps of which one is in background. There are a lot of *ix words and terms here that I’m out to become familiar with at some point.

Idea 5

Local web server and client. This is basically a specific implementation of the previous idea, but something that’s known to work in practice, people have these done in their apps.

If the pasteboard becomes non-usable for my use case, I’ll probably try this next.

Call for action

I believe that as iOS matures, direct inter-app communication will become a real need. Apple is making baby steps in that direction, with NSExtensionContext and App Groups.

The need is here and now it’s the time to formulate the requirements and hit bugreport.apple.com in order to have anything added to the SDK in reasonable time-frame. Just remember the open-source-born Audiobus which even Apple used in their own apps - it’s possible :).

For my use case, a simple key-value storage (NSMutableDictionary) in NSExtensionContext would suffice. Thus my first Radar will be to add at least userInfo property to it, the way NSNotification has one.

Update, (winning) Idea 6

I can’t believe I completely missed what turned out to be the winning idea: use shared NSUserDefaults through App Groups. It’s the recommended way to communicate settings between the extension and app and it’s good enough to shuttle back and forth small bits of data.

UIPasteboard-based solution actually did work, until you lock the screen; locking puts impenetrable barrier and your extension becomes empty. NSUserDefaults works great even when locked, with passcode and all.

Any comments and discussion, please contact me as @radiantav on Twitter.

How to remove UINavigationBar's bottom border / shadow in iOS 7

Fri, 29 Aug 2014 00:00:00 +0000

One of the most annoying visual things Apple introduced in iOS 7 is inability to remove the navigation bar shadow image. iOS 7 UI is perfect to create seamless transition between the content and the top of the screen.

The only issue is that darn line at the bottom. There is no property on UINavigationBar to hide it. There is shadowImage which allows you to change it, but can’t remove it – shadowImage = nil is the default which shows their default image. Even changing the shadowImage to 100% transparent image is not enough:

For a custom shadow image to be shown, a custom background image must also be set with the setBackgroundImage:forBarMetrics: method. If the default background image is used, then the default shadow image will be used regardless of the value of this property.

Brilliant. 😕 You can remove the shadow only if you also kill the blur, like this:

[self.navigationController.navigationBar setBackgroundImage:[[UIImage alloc] init] 
			forBarMetrics:UIBarMetricsDefault];
self.navigationController.navigationBar.shadowImage = [[UIImage alloc] init];

Can’t help to think this was not properly thought through, but given the hectic schedule Apple engineers had for iOS 7, something had to give. Anw, with no other avenue left, it’s subview walkthrough time.

<UINavigationBar: 0xb486860; baseClass = UINavigationBar; frame = (-160 0; 320 1); opaque = NO; autoresize = W; gestureRecognizers = <NSArray: 0xb4887e0>; layer = <CALayer: 0xb4869c0>>
| <_UINavigationBarBackground: 0xb487090; frame = (0 0; 320 1); opaque = NO; autoresize = W; userInteractionEnabled = NO; layer = <CALayer: 0xb4871c0>>
|    | <_UIBackdropView: 0xb48fb20; frame = (0 0; 320 1); opaque = NO; autoresize = W+H; userInteractionEnabled = NO; layer = <_UIBackdropViewLayer: 0xc6aec50>>
|    |    | <_UIBackdropEffectView: 0xc6af6e0; frame = (0 0; 320 1); clipsToBounds = YES; opaque = NO; autoresize = W+H; userInteractionEnabled = NO; layer = <CABackdropLayer: 0xc6af9a0>>
|    |    | <UIView: 0xc6b0150; frame = (0 0; 320 1); opaque = NO; autoresize = W+H; userInteractionEnabled = NO; layer = <CALayer: 0xc6b02b0>>
|    | <UIImageView: 0xb4873d0; frame = (0 1; 320 0.5); userInteractionEnabled = NO; layer = <CALayer: 0xb4874a0>>
| <UINavigationItemView: 0xb488da0; frame = (160 -16.5; 0 0); opaque = NO; userInteractionEnabled = NO; layer = <CALayer: 0xb48c630>>
|    | <UILabel: 0xb48c9e0; frame = (0 33; 0 0); clipsToBounds = YES; opaque = NO; userInteractionEnabled = NO; layer = <CALayer: 0xb48cae0>>

That 0.5pt tall UIImageView is the target.

[self.subviews enumerateObjectsUsingBlock:^(UIView *v, NSUInteger idx, BOOL *stop) {
	if ([NSStringFromClass([v class]) rangeOfString:@"BarBackground"].location != NSNotFound) {
		[v.subviews enumerateObjectsUsingBlock:^(UIView *v, NSUInteger idx, BOOL *stop) {
			if ([v isKindOfClass:[UIImageView class]]) {
				if (CGRectGetHeight(v.bounds) == 0.5) {
					[v removeFromSuperview];
					*stop = YES;
				}
			}
		}];
		*stop = YES;
	}
}];

I coded this as defensively as possible, to not crush in case something changes in the future. Get the RTCleanNavigationBar subclass on GitHub and use it like this:

UIViewController *vc = ...;
UINavigationController *nc = [[UINavigationController alloc] 
    initWithNavigationBarClass:[RTCleanNavigationBar class] 
    toolbarClass:nil];
[nc setViewControllers:@[vc]];

This works perfectly, does not trigger any issues with app review. Hopefully it stays like that for the foreseeable time and Apple gives us a proper way to do this.