GPX Reader
Bekijk je al eens een GPX- of TCX-bestand op een Mac? Dan laten wij je graag kennismaken met GPX Reader!
Bekijk je tracks, routes en routepunten, en schakel in het menu uit wat je niet wil zien. GPX Reader toont je tracks op het Google Maps-type van je keuze: kaart, satelliet of hybride.
Je herkent je GPX- en TCX-bestanden meteen aan het fancy icoontje dat ze krijgen dankzij GPX Reader. Ook Quick Look is voorzien: je ziet meteen het aantal tracks, routes en routepunten in de bestanden zonder ze te hoeven openen.
Spotlight indexeert de naam, de link-tekst en de beschrijving van je GPX- TCX-bestanden zodat je ze onmiddellijk kan terugvinden via het zoekvak.
Download GPX Reader in de App Store.
Cocoapods
Cocoapods
In all of our apps, whether they are web-apps or iOS apps, we make extensive use of different frameworks. These help us to save time by abstracting out stuff that’s needed in a lot of different projects.
We also maintain some of our own frameworks:
- Tin Makes consuming webservices in iOS a lot easier.
- Coby Adds some functionality we know and love from Ruby into several default Obj-C classes.
But these frameworks grow together with our projects, so copying these into several projects can become tedious and managing different versions would make things too complicated.
Ruby has Bundler to solve this problem. Just create a gemfile that lists every “gem” you use, Bundler will install these gems and keep track of the versions in the “Gemfile.lock”.
Now there is a similar system for Cocoa, called Cocoapods.
Installing cocoapods
Cocoapods runs on macruby, so installing it using RVM is a breeze:
$ rvm install macruby
Then simply setup cocoapods like this:
$ rvm use macruby
$ macgem install cocoapods
$ pod setup
And now we’re ready to start using Cocoapods.
Adding Cocoapods to a project
Using Cocoapods in a new project is quite similar to using Bundler in a rails project. We start by adding a Podfile which could look like this:
platform :ios
dependency "AFnetworking",
:git => "git://github.com/AFNetworking/AFNetworking.git"
dependency 'Tin',
:git => "git://github.com/Reprazent/Tin.git",
:commit => "baf1c407f74dd6ca6c6c8c46bc0a3a565e79d3b6"
dependency 'coby',
:git => "git://github.com/pjaspers/coby.git"
dependency "MagicalRecord"
The platform can either be :ios or :osx.
Note that, just like with Bundler, you can specify a git repository, and even a commit or tag to reference your dependency. This makes it a lot easier to fix versions and avoid breaking the project when updating the dependencies.
The dependencies referencing a git repository must contain a “.podspec” file. When no repository is specified, Cocoapods looks for the podspec in it’s own spec-repository. There’s already a bunch of frameworks that are available, and more are sure to follow.
Now we can enable Cocoapods for our project by running pod install for the first time.
$ pod install demoproject.xcodeproj
This will clone the git repositories of the pods specified in a new “Pods” directory in your project root. Just like Bundler it will create a “Podfile.lock” which holds the references to the current version of the pods and its dependecies. Together with a new workspace we can use to open our project in XCode. There we will see that there are actually two projects added to the workspace.

One containing your regular project, and one containing the pods, this makes it easier to view the source code of these pods while working.
When building your project your pods will be built into “libPods.a” before building the project itself.

Now you’re good to go. When adding new pods or updating existing ones in your podfile just run pod install again to update your “Podfile.lock” and adding or updating the Pods.
When multiple build configurations are needed, we also need to add these in the “Pods.xcodeproj”.

You should also set “Skip Install” to yes in your build target in order to create archives for different build types.

thanks Verbeeckx for figuring these last two out
Creating your own Cocoapods
To be able to add our own frameworks into our own projects easily, we had to add a “.podspec” to the repos. These podspecs look very similar to the gemspecs in Ruby.
Pod::Spec.new do |s|
s.name = 'Tin'
s.version = '0.0.1'
s.license = 'MIT'
s.summary = 'Tin makes the internet easier in Cocoa.'
s.homepage = 'https://github.com/pjaspers/Tin'
s.author = { 'pjaspers' => 'piet@jaspe.rs' }
s.description = 'An optional longer description of Tin.'
s.source = { :git => 'https://github.com/pjaspers/Tin.git' }
s.source_files = 'Classes',
'Classes/**/*.{h,m}',
"Tin",
"*.{h,m}"
s.dependency 'JSONKit'
s.dependency "AFNetworking", "~> 0.8.0"
end
In this podspec we set the source, where Cocoapods can find the repository to clone. We specify where the required classes can be found within the repository. We can also set several dependencies, specifying the tags that should be used.
Note that adding a dependency like this, it needs to be present in the spec repository of Cocoapods. When the correct tag or framework isn’t present in the repo yet, we can add it ourselves in the Podfile of the project we are using the framework in. In the case of Tin, we had to add “AFNetworking” separately in the Podfile because the highest available version from Cocoapods was 0.7.0.
I suspect Cocoapods will gain a lot in popularity in the future, because it makes adding dependencies to projects much easier. As it gains in popularity, more frameworks will become available.
I suggest you get over to the Cocoapods github and give it a try.
Creating a Quick Look plugin
I’ve been searching for some decent documentation on how to create a Quick Look plugin. It took me several months before I finally found a way to develop the plugin. With many thanks to a soon to be released book by The Big Nerd Ranch.
For those wondering on what Quick Look does, here is Apple’s explanation.
In this blog post I’ll show you how to…
-
create a simple Quick Look plugin
-
support a custom file type
-
debug your plugin with Xcode
Setup your Xcode project
Now let’s start developing!
-
Create a new Quick Look project

-
Change the extension for both
GenerateThumbnailForURL.c&GeneratePreviewForURL.cto .m. (This allows you to use Objective-C code and frameworks in these files)
Support an extension
In this example I want to support the .10to1 extension so that I can preview this file as a text file.
Below is an example on what you have to add to the Info.plist to support the .10to1 extension.
<key>UTImportedTypeDeclarations</key>
<array>
<dict>
<key>UTTypeIdentifier</key>
<string>be.10to1.quicklook</string>
<key>UTTypeDescription</key>
<string>10to1 document</string>
<key>UTTypeConformsTo</key>
<array>
<string>public.data</string>
</array>
<key>UTTypeTagSpecification</key>
<dict>
<key>public.filename-extension</key>
<array>
<string>10to1</string>
</array>
</dict>
</dict>
</array>
<key>CFBundleDocumentTypes</key>
<array>
<dict>
<key>CFBundleTypeRole</key>
<string>QLGenerator</string>
<key>LSItemContentTypes</key>
<array>
<string>be.10to1.quicklook</string>
</array>
</dict>
</array>
Be aware, the default project template for a Quick Look plugin already has the following line of code included in the plist.
<key>CFBundleDocumentTypes</key>
<array>
<dict>
<key>CFBundleTypeRole</key>
<string>QLGenerator</string>
<key>LSItemContentTypes</key>
<array>
<string>SUPPORTED_UTI_TYPE</string>
</array>
</dict>
</array>
If you want to create a plugin for an existing UTI type, you just have to change SUPPORTED_UTI_TYPE string with for example public.png for a PNG image.
But if your plugin supports a non existing UTI type you have to define it in the plist under the UTImportedTypeDeclarations key. If you want to find out to what UTI type your file conforms to, just use the mdsl executable and you’ll find the UTI type(s) in key kMDItemContentTypeTree.
mdls FILENAME
More information can be found here.
Render the preview
This is the view shown after the space button is pressed. This will display the content of the .10to1 file.
-
Add the Cococa framework
-
Import
<Cocoa/Cocoa.h>in theGeneratePreviewForURL.mfile -
Add some generation code inside the
GeneratePreviewForURLfunction as done in this file
Render the thumbnail
This is the icon with a generated content that is shown in your Finder window.
-
Add the WebKit framework
-
Import
<Cocoa/Cocoa.h>&<WebKit/WebKit>in theGenerateThumbnailForURL.mfile -
Add some generation code inside the
GenerateThumbnailForURLfunction as done in this file
Debugging
But how do we debug a Quick Look plugin? You can’t just run it as an executable. Therefore we use qlmanage provided by Apple.
We first have to copy the plugin to ~/Library/QuickLook after a successfull build, otherwise your plugin will not run correctly with Xcode.
-
Add a New Copy Files build phase to your target
-
Select Absolute Path and enter ~/Library/QuickLook as the Subpath
-
Add the generated file to the files list

Run the plugin using qlmanage.
- Because you can’t select qlmanage in the Finder you have to copy the binary to your project root
cp /usr/bin/qlmanage PROJECT_ROOT/.
-
Edit your scheme and select the Run/Info tab
-
Select the qlmanage executable in your project root

-
In the Run/Arguments tab you can add the folling
Arguments Passed On Launchto render the preview:
-p dummy.10to1
Next up, run the application and the dummy.10to1 file will be used as the selected file.
To test the thumbnail generation you could to the same, add the same argument but with -t in the Arguments tab:
-t dummy.10to1
But this didn’t to the trick (I have no idea why…), so you can manually run this command in your Terminal in order to test the preview generation:
qlmanage -t dummy.10to1
The result
After all this we have created our Quick Look plugin.
If you want do distribute the plugin, just Archive & Save it.
Open a .10to1 file and enjoy the plugin! :)

Some utilities
- Reload the Quick Look generator list
qlmanage -r
- List the UTI types for the given file, very handy when defining your supported UTI format
mdls FILE
Reference
Wij engageren ons voor FLAME
Een bedrijf is geen eiland. We kijken dan ook graag af en toe eens op van onze toetsenborden om te zien wat er leeft in de wereld rondom ons. Een aanrader!
Soms doen we zo inspiratie op, of leren we iets bij, en een enkele keer denken we: ‘Hm, hier kunnen we helpen…’. Dat laatste gebeurde toen we FLAME vzw leerden kennen. FLAME had nood aan een nieuwe website, en we zijn blij dat we een kleine bijdrage konden leveren door het design van de site op ons te nemen.
FLAME is een ngo die brandwondenzorg verleent in Burkina Faso. Wat begon als acute noodhulp in 2003 groeide uit tot een volwaardig en helaas uniek brandwondencentrum in Bobo Dioulasso. FLAME verzamelt financiële en materiële steun en gaat 3 keer per jaar ter plekke het lokale team opleiden en concrete hulp verlenen.
Maar lees het volledige en indrukwekkende verhaal vooral zelf op de gloednieuwe site die sinds vandaag online staat: www.ngoflame.be.
VillaSquare
10to1 werkte samen met het uitstekende team van VRT-medialab aan een webapplicatie waarmee kijkers tijdens het TV-programma Villa Vanthilt konden reageren op de uitzending en op elkaar. De app is gebaseerd op Ruby on Rails, HTML5 en CSS3 en werd geoptimaliseerd voor de iPad.
VRT-medialab is de onderzoeksafdeling van de VRT en verricht onderzoek naar de creatie, het beheer en de distributie van mediacontent. Om een meerwaarde toe te voegen aan de traditionele media-ervaring wil VRT-medialab tweedeschermtoepassingen aanbieden.

Centraal staat de korte inhoud van de volgende aflevering, en een tag cloud op basis van reacties op de vorige aflevering.
Eens je geregistreerd bent, kan je aangeven dat je naar een aflevering gaat kijken of gekeken hebt, en kan je delen of je de aflevering leuk of niet leuk vond. Je kan het profiel van andere gebruikers bekijken en hen toevoegen aan je Vrienden.
De berichtenstroom aan de linkerzijde verzamelt alle reacties die via SMS, Facebook, Twitter of op de site zijn gedeeld. Je kan de berichten zo filteren dat je alleen de reacties van een bepaald netwerk of met bepaalde hashtags te zien krijgt. Of je kan enkel de reacties van je vrienden bekijken. Berichten van de officiële Villa Vanthilt-account hebben een blauwe achtergrond zodat ze duidelijk opvallen.
In het veld linksboven kan je zelf een reactie achterlaten. Als je dat wenst, wordt die meteen doorgepost naar je eigen Facebook- of Twitteraccount.
In geen tijd waren Jelle, Elise en Nick erg straf bezig. Ze hadden een no-nonsense attitude die goed aansloot bij onze manier van werken. Stap voor stap slaagden we erin de applicatie stabiel, gebruiksvriendelijk en schaalbaar te maken. Zo vormden we samen een ruw prototype om tot een afgewerkt product. En dat is voor een groot stuk te danken aan Jelle en Elise hun diepe kennis van het Rails framework en Nick zijn perfectionisme en liefde voor user interfaces.
Hendrik Dacquin, VRT-medialab
- Page 3 of 16
- Newest articles
- Newer articles
- Oldest articles
- Older articles




