Posts Tagged ‘ios’

Domain-Specific Languages (Mobile Edition)

21. April 2014 Leave a comment

Last year, I gave a talk about domain-specific languages at Macoun, the biggest German-speaking conference for iOS and Mac OS developers.

Many software developers wish they could create their own programming language. A language that would exactly meet their taste and needs. However, language development is considered to be complex and laborious. Fortunately, there are frameworks for domain-specific and programming language development that make this a simple task. Domain-specific languages are widely used today. Just think of CSS, SQL, the visual format language of iOS and OS X Auto Layout constraints or the Objective-C predicate format. So let’s see, how we can easily create our own language, use an iOS device as an editor for it and generate source code or even a whole native app for multiple platforms from it.

In my talk, I gave a definition of problem domain and domain-specific language (DSL) and showed some examples of different domains. I also compared different kinds of domain-specific languages and pointed out the benefits of their use. My language implementation examples made use of the parser generator framework ParseKit and the IDE for language development Xtext. And finally, I demonstrated the Applause DSL and its usage for creating apps for different mobile platforms.

The video of my talk is in German. If you are interested in listening to this topic in English don’t hesitate to contact me. I’ll be happy to speak at your event.

CocoaPods, locally speaking

2. February 2013 3 comments

CocoaPods is a simple-to-use but efficient framework for managing dependencies in Xcode. You might have already used it to manage library dependencies hosted on GitHub. Otherwise, take a look at the CocoaPods website first. But do you also know that you can use CocoaPods to manage dependencies that are not stored in a GitHub repository or any other remote repository at all? Let’s see how to do that.

Let’s say, you have an Xcode project named Provider which you want to include into another Xcode project named Consumer. First, you need to write a pod specification for your Provider project. The crucial part of specifying a local dependency is how you define the source attribute. In this case, source should contain a path to the Provider repository, relative to the Podspec file. So, if you placed the Podspec into the root of the Provider project, the path will be '.'. The second option of the source attribute needs to be a tag or a commit number. If you want to test your changes while developing, you will probably use a commit number, for example: 'abcd123'. Putting both things together, we get:

s.source = { :git => '.', :commit => 'abcd123' }

The remaining part of the Podspec won’t differ from the one you would write to use with a remote repository. So, your Podspec will look something like this: do |s| = 'Provider'
    s.version = "0.0.1"
    s.summary = 'Provider is a framework for consuming RESTful web resources on iOS.'
    s.homepage = '<some-username>/provider'
    s.license = 'Apache License, Version 2.0' = { 'Natalia Ossipova' => 'natalia.ossipova@<some-domain-name>.com' }
    s.source = { :git => '.', :commit => 'abcd123' }
    s.platform = :ios, '5.0'
    s.requires_arc = true
    s.source_files = 'Provider'
    s.resources = 'Provider/Default.png', 'Provider/Default@2x.png', 'Provider/Default-568h@2x.png', 'Provider/en.lproj/InfoPlist.strings'

To find out what other attributes you might need to fill in refer to the CocoaPods wiki.

Here are some tips to make you Podspec work:

    • If your Xcode project contains subfolders, list all of them containing source files in the attribute source_files:
  • s.source_files = 'Provider', 'Provider/Globals', 'Provider/Model', 'Provider/View', 'Provider/Services'</code>
    • If you defined imports globally in a *.pch file, specify it as the prefix_header_file attribute:
  • s.prefix_header_file = 'Provider/Provider-Prefix.pch'
    • List all resources, i.e. all PNG, *.strings and XIB files, in the resources attribute.
    • Give your Localizable.strings file of the Provider project a unique name, e.g. Provider-Localizable.strings, and use NSLocalizedStringFromTable in the Provider code.
  • After finishing and validating the Provider Podspec, you need to point your Consumer to Provider by using the :path option in the Podfile of Consumer. The path to the Provider project can be relative to the Podfile. If, for instance, you checked out both projects into the same folder, your Podfile will look like this:

    platform :ios, '5.0'
    pod 'Provider', :path => '../Provider'

    Now, you can install the Consumer dependency and work on both projects. Don’t forget to update the commit number in the Podspec each time you’ve committed your changes on Provider to a local repository.