On a recent project I was fed up with having to deal with a SQLite database “by hand”. So I wrote a wrapper for it that allows you to interact with the database in convenient Objective-C, as well as perform queries on a background queue.

The second new project is what the general public has come to call a “Hamburger Menu”. This is the kind of side panel menu that you can see in many popular apps.

And Yes, YES, I am aware that there are “finished” open source components out there that provide similar functionality. I like to tinker with these things because I am learning a hell of a lot about how to make great components. In short: for the fun of it.

Version 1.4 Change Log

• ADDED: [DTSidePanel] Container Controller
• ADDED: [DTSQLite] Wrapper class for SQLite3 Databases
• ADDED: [DTAlertView] Method to create a cancel button and/or set a cancelBlock.
• CHANGED: Moved experimental striped layer into Experimental folder

DTSQLiteDatabase

The idea is that I want to have an NSObject represent the database and then have a simple method to query it.

// get the path in a way that also works in unit tests
NSString *path = [[NSBundle bundleForClass:[self class]] pathForResource:@"database" ofType:@"sqlite"];
 
// abort if the path does not exist
NSAssert(path, @"No db file found in app bundle");
 
// store in IVAR
_database = [[DTSQLiteDatabase alloc] initWithFileAtPath:path];

The to perform a query you can simple call the following:

NSString *sql = @"SELECT * from mytable;";
 
NSError *error = nil;
NSArray *results = [_database fetchRowsForQuery:sql error:&error];
 
if (!results)
{
   // deal with error
}

The results are automatically repackaged for you into an NSDictionary for each row. Note that in SQLite all column names turn to lowercase. At this moment this supports the SQLite types TEXT, INTEGER and FLOAT. If you need more let me know, those are easy to add.

If you are the only person making calls to fetchRowsForQuery:error: and you don’t care that this is executed on the current (main) thread, then that’s all it takes.

You get thread safety and the ability to synchronize fetches onto a private background queue via performBlock: and performBlockAndWait: just like you are used to from Core Data managed object contexts that have the private queue concurrency type:

[_database performBlock:^{
   // this code occurs in background
   NSError *error = nil;
   NSArray *results = [_database fetchRowsForQuery:sql error:&error];
 
   // do something with the results
}];

DTSQLiteDatabase has a features that famous FMDB does not have, but which I needed. Imagine you starting a query that might take a while in the background, but while it is underway the user decides that he doesn’t want to wait. You can interrupt long-running queries via the cancelAllQueries method.

I only implemented the absolutely necessary parts, but this works very nicely so far for my use case. The documentation can be found on our docs server.

The “Hamburger Menu”

There is a long list of apps that use said UI paradigm. The idea is that you are not waisting screen real estate by having tabs at the bottom of your screen like you would with a UITabBarController. Or a big viewController tree under a UINavigationController.

Instead you have side panels. Often on the left side, sometimes also on the right. And you would reveal these side panels either by swiping sideways or by the famous “Hamburger Button”. I long wondered why it is called that … Look at this screen shot, with a little imagination you can see two parts of the hamburger bun with a piece of meat in between. (Thank you René Pirringer for drawing the button for my demo app)

For a short while I considered calling this DTHamburgerMenuController, for the fun of it. But eventually I decided on DTSidePanelController instead, sounds more professional.

It has these features:

• Support fixed or variable sized side panels. A fixed panel always keeps its width on rotation. A variable-width panel resizes such that you always have sufficient place to tap the center panel for closing.
• Supports embedding UINavigationControllers
• Swiping needs to be a minimum distance to be registered to avoid problems with other horizontal gestures
• Tap-to-close an open side panel
• Rotation support, panel view controllers are queried for supported orientations, compatibly with iOS 5 and above.
• Beautiful code and nice documentation
• Appearance notifications for the view controllers and views fully implemented. viewWillAppear fires as soon as the panel becomes visible.
• Support for accessing the side panel controller via property, self.sidePanelController from anywhere inside the view controller hierarchy
• Fast shadow with shadow path
• Ability to prevent closing/moving the center panel via delegate method. For example if you have something modal going on that you want the user to finish first

There are a few things that I decided against doing for the first version. For instance some implementations have a rubberbanding effect following the animation. The problem with this approach is that to support that you would have to under-lap the panels under the center panel so that you don’t see the background when it overshoots the limit. It is probably for this reason that most professionally made apps don’t have that. YouTube does rubberband, Facebook doesn’t.

The demo also shows how to lock a panel. If you go to the right panel you get a switch to prevent closing of the panel.

Conclusion

You are welcome to give my components a try, even if they are not as popular as FMDB or the various other implementations of the “hamburger menu”. I am interested to receive your comments or feedback.

Your vendor identifier is an 8-digit number beginning with an 8. Usually you have only one, but if you – for example – move from an Individual to a Company Apple developer account, then your old ID is retired and you get a new one. There might be also other scenarios for people having multiple, now AutoIngest for Mac supports that.

Changes

• ADDED: Support for multiple vendor identifiers

For the validation I implemented an NSTokenField, the learnings from that I summarized in a separate article.

I hope you are enjoying this new version AutoIngest for Mac! It is available via auto-update, direct download as well as full source on GitHub. The binary builds have Sparkle for OTA updating and are signed with Developer ID.

Changes in 1.5.1

• FIXED: Attributes “bleeding” into next paragraph

Changes in 1.5.2

• FIXED: Crash on parsing HTML with additional tags following HTML end tag
• FIXED: DTAttributedLabel problems being instantiated from NIB, ignoring edge insets
• FIXED: Crash on using font-family “inherit” together with font-variant “small-caps”.
• FIXED: Endless loop when using a text block that would not fully fit in a height-constrained layout frame
• FIXED: Image Attachment ignoring maximum display size if width/height are set via tag attributes
• FIXED: Invalid font-size would cause Core Text font size of 12px to be used.
• [Sponsored] CHANGED: Lists now correctly use padding and margin. If you specify too small a margin for the list prefix to fit, then the list prefix is omitted.

Contrary to how HTML browsers are displaying list prefixes (e.g. bullets) Core Text cannot draw outside of the laid out lines. This limitation became apparent if you specified a too large list indent margin to fit the prefix. Then the text would spill over the too closely set tab stops and be indented to the next standard tab stop. To prevent this from happening I implemented a check that tests to see if the margin is sufficiently wide to fit the prefix excluding white space.

The new version is tagged and available on the GitHub master branch. A new spec has been added to the CocoaPods public repository.

This release has one sponsor, as highlighted. Austrian company Antiloop is doing Ruby on Rails, iPhone and iPad development. They are big fans of DTCoreText and are using it in several apps, including:

• Ecoline for iPad
• Journal

Both apps make great use of rich text and are free downloads on the Apple App Store.

I want to specifically highlight the new option to have your downloaded reports be automatically organized into folders for you, thanks to Felipe Cypriano.

Jan Weiß and Christian Pfandler collaborated on the new golden Apple Icon. The idea behind this – besides the reference to Apple, Inc. – is that apps are your golden Apples and this app is good for you because it lets you take a bite of this value.

Changes

• ADDED: Option to automatically organize reports in folders by vendor id, type, sub type and date type
• ADDED: App Icon
• ADDED: Options for downloading Opt-in and Newsstand reports
• ADDED: Notification Center message now shows number of downloaded reports by type
• FIXED: Sync Now menu option wasn’t disabled if sync was impossible to do missing or wrong account info

We now also enabled (theoretically) downloading of the other report types offered by Apple’s API: Opt-In and Newsstand.

This gives you a great overview over what kinds of reports are possible. These combinations are mentioned in the iTunes Connect Reporting Guide as well as have been verified to exist by 2 people who have apps that produce these kinds of reports.

Please Help if You have Newsstand or Opt-In Reports

I have no ability to test these I have to rely on users who are willing to try this out. And preferably also fix it via pull request or by joining the team of developers.

There is a known issue with Opt-In reports. Those are zipped with a password and for the time being we have no ability to unzip these. Again this would require help of a developer who has Opt-In reports to test on. One feature that I would like to also add is support for adding multiple accounts/vendors and there you would also have a box to enter the Opt-In unzip password.

I hope you are enjoying this new version AutoIngest for Mac! It is available via auto-update, direct download as well as full source on GitHub. The binary builds have Sparkle for OTA updating and are signed with Developer ID.

For the most part these improvements and enhancements were funded from exceptional sales of DTRichTextEditor as well as several sponsors who stepped forward to allow me to finally get support for lists implemented.

From what I can tell the clients who licensed the editor are way more willing to contribute funds to something they have already paid for, than for enhancing the – otherwise free with attribution – DTCoreText.

Here are the collected release notes:

DTRichTextEditor 1.5

• ADDED: Implemented Support for Ordered and Unordered Lists, editable 1 level
• CHANGED: Improved handling of nested lists
• ADDED: Method to set text color for range
• ADDED: Method to set strikethrough style for range
• ADDED: HTMLStringWithOptions methods
• ADDED: Ability to animate between input views (custom keyboards)
• FIXED: style information would not obey custom CSS stylesheet in textDefaults
• CHANGED: editing delegate now uses editorView:shouldChangeTextInRange:replacementText: for image pasting
• ADDED: [DEMO] Formatting View Controller, shown as popover on iPad and input view on iPhone

Online Documentation

DTCoreText 1.5

• ADDED: Methods for getting glyph path for glyph runs and lines
• CHANGED: DTTextAttachment is now a class cluster
• ADDED: Custom text attachments can now opt to participate in inline drawing and/or HTML output
• FIXED: Loading of font table made asynchronously
• FIXED: Fonts that have a synthetic slant matrix cause text to disappear
• FIXED: Shadow:none causes text to disappear
• FIXED: CSS Attributes were not case-sensitive
• FIXED: Issue with setting color of HR
• FIXED: Problems with nested list parsing and DTHTMLWriter output
• FIXED: HTTPS URLS in web video view where treated as external URLs
• FIXED: Bug where text attributes would “bleed” into the paragraph break

Online Documentation

DTLoupe 1.5

• ADDED: sanity check to avoid rare NAN crash

Online Documentation

There is also now a Programming Guide for DTRichTextEditor where I’m collecting guides how to implement frequently asked about things.

I especially would like to thank Lee Hericks for his work on the backend and help with polishing, as well as Daniel Phillips who helped implement the format picker in the Editor demo. Here’s a screenshot.

Of course work has already begun on the next version. If you need something specific implemented please get in touch.

Changes

• Replaced Status Bar Icon with vector-based version
• Improved Menu Handling Code
• Improved handling of Mac Standby
• Reduced Min OS Version to 10.7
• Added Validation for Vendor ID
• Added Automatic Updates via Sparkle

The Developer-ID signed version with Sparkle can be downloaded here, and of course you can build a version yourself from the 0.3.0 tag on GitHub.

Changes

• FIXED: When Copy to new Message in Log was chosen the custom fields were not used in some cases.

The update has been submitted to Apple for review.

Update May 7th: Approved after 4 days.

At present in the Daily, Monthly, Weekly and Yearly flavors. You can also activate the auto-download where it will do the downloading every 24 hours. You can put this on each of your Macs if you download the reports to a shared Dropbox folder because each instance will automatically skip report files that are already present locally.

Version 0.2 is the first version that we are distributing as a Developer ID-signed app. This is convenient for people who don’t want to build it from source code but still want to have a version they know they can trust, with a Developer ID signature.

I am excited that already several people have stepped forward to add a bit of their own brains to the matter.

• Rico Becker helped with some initial cleanup and he implemented a placeholder animated icon
• Jan further tuned some things Mac-specific things
• Christian Pfandler painstakingly put together a 87-frame long status icon animation

Here’s a large version of the icon animation that runs in the status bar while report synching is going on.

The idea behind the icon is that Apple is a fruit and to ingest something in this regard you have to take bites out of it. Cute, isn’t it?

Download the App (zip)

So here are the changes for 1.4.1 and 1.4.2:

Changes in 1.4.1

• FIXED: Parser ignoring align HTML attribute
• FIXED: Helvetica appearing thinner than normal
• FIXED: DTAttributedLabel truncation
• CHANGED: Method of determining paragraph ranges
• ADDED: Option to disable Apple-converted-space

Changes in 1.4.2

• FIXED: DTWebVideoView for Daily Motion
• FIXED: textAttachmentsWithPredicate: not returning all attachments for nil predicate
• FIXED: further fixes for DTAttributedLabel truncation
• FIXED: Issue with list attribute not including to final \n of empty LI.
• FIXED: Disable cell reuse in Demo because of variable height you need to do your own cell caching
• ADDED: Feature to scroll a range to visible
• CHANGED: Disabled forcing of Times New Roman as font for bullets
• CHANGED: Replaced synchronization in DTCoreTextLayoutLine with @synchronized

Both versions as tagged on the GitHub repo as well as available through CocoaPods.

The upcoming 1.5 release will replace the contentType property of DTTextAttachment with a class cluster. Because of this it might require a few code changes if you are interacting with text attachments.

Update: Updated Resource Bundle generation use the new syntax of CocoaPods 0.18.

CocoaPods has a number of repositories that it derives its specs from, for a default install this number is 1. But it doesn’t have to be, any other git repository can also serve spec files, as long as it obeys the standard layout. You have a folder by component and inside this you have one folder per version which contains a lonely podspec file.

Resource Bundles and Pods

Before I could get started in manufacturing spec files for my components I needed first to solve a problem. If a component requires some resources I always put them in a resource bundle target. I hate it when Open Source components have a static bundle as a workaround for CocoaPods approach of copying files. Those don’t get the proper processing they deserve, images get processed, strings files get converted into binary plists and more.

Fortunately other people are thinking the same and so I quickly got an answer on the CocoaPods Google Group, Fabio Pelosin came to my rescue and pointed me towards the spec of CoconutKit 2.0.2 which also builds a resource bundle, written by none other than famous Cédric Luthi aka @0xced. In the company of Giants…

Cedric has a bit weird structure in my opinion having a separate xcodeproj just for the resources, so my approach is a variation and simplification of his.

First you need to tell CocoaPods to preserve the xcodeproj and the resource folders because without that it deletes these and only keeps the source code files.

Then you need to build the resource bundle into the common Resources folder and add the file to the resource install script. Here is the complete spec for DTLoupe:

Pod::Spec.new do |spec|
  spec.name         = 'DTLoupe'
  spec.version      = '1.3.0'
  spec.platform     = :ios, '4.3'
  spec.license      = 'COMMERCIAL'
  spec.source       = { :git => 'git@git.cocoanetics.com:parts/dtloupe.git', :tag => spec.version.to_s }
  spec.source_files = 'Core/Source/*.{h,m}'
  spec.frameworks   = 'QuartzCore'
  spec.requires_arc = true
  spec.homepage     = 'http://www.cocoanetics.com/parts/dtloupeview/'
  spec.summary      = 'A Loupe as used for text selection.'
  spec.author       = { 'Oliver Drobnik' => 'oliver@cocoanetics.com' }
  spec.preserve_paths = 'DTLoupe.xcodeproj', 'Core/Resources'
 
def spec.post_install(target_installer)
    puts "\nGenerating DTLoupe resources bundle\n".yellow if config.verbose?
    Dir.chdir File.join(config.project_pods_root, 'DTLoupe') do
      command = "xcodebuild -project DTLoupe.xcodeproj -target 'Resource Bundle' CONFIGURATION_BUILD_DIR=../Resources"
      command << " 2>&1 > /dev/null" unless config.verbose?
      unless system(command)
        raise ::Pod::Informative, "Failed to generate DTLoupe resources bundle"
      end
    end
    if Version.new(Pod::VERSION) >= Version.new('0.16.999')
      script_path = target_installer.target_definition.copy_resources_script_name
    else
      script_path = File.join(config.project_pods_root, target_installer.target_definition.copy_resources_script_name)
    end
    File.open(script_path, 'a') do |file|
      file.puts "install_resource 'Resources/DTLoupe.bundle'"
    end
  end
end

Note the single quotes which are necessary for the target since I have a space in there.

I later found that I had version 0.16 of CocoaPods on the machine where I put together the spec. People using the latest version (presently 0.18.1) would get quite a few warnings on pod install and update. 3 problems to be exact.

The first problem was that I thought I was smart by removing the preserved folders after the install. Turns out that these are still needed even for an update.

The second problem came from target_installer.target_definition.copy_resources_script_name being deprecated, instead some people (e.g. HockeyKit) switched to target_installer.copy_resources_script_path instead.

However – problem number three – was that access to the global config singleton was deprecated as well. So each access to it causes a nasty yellow warning to appear. Eloy Durán explained to me that it was a “chicken and egg thing”. He also – wisely – suggested that I should totally drop support for older CocoaPods versions.

Bonus problem number four is that as of 0.18 there is a built in post_install hook and so there’s an occasional warning the the def of it.

People get a warning if they have an old CocoaPods version if they do anything and updating is simple with a sudo gem update cocoapods. I am a Ruby NOOB so I am thankful for Eloy helping to rewrite the spec as follows. I proceeded to removed all references to the config singleton.

Pod::Spec.new do |spec|
  spec.name         = 'DTLoupe'
  spec.version      = '1.3.0'
  spec.platform     = :ios, '4.3'
  spec.license      = 'COMMERCIAL'
  spec.source       = { :git => 'git@git.cocoanetics.com:parts/dtloupe.git', :tag => spec.version.to_s }
  spec.source_files = 'Core/Source/*.{h,m}'
  spec.frameworks   = 'QuartzCore'
  spec.requires_arc = true
  spec.homepage     = 'http://www.cocoanetics.com/parts/dtloupeview/'
  spec.summary      = 'A Loupe as used for text selection.'
  spec.author       = { 'Oliver Drobnik' => 'oliver@cocoanetics.com' }
  spec.preserve_paths = 'DTLoupe.xcodeproj', 'Core/Resources'
 
  spec.post_install do |library_representation|
    Dir.chdir File.join(library_representation.sandbox_dir, 'DTLoupe') do
      command = "xcodebuild -project DTLoupe.xcodeproj -target 'Resource Bundle' CONFIGURATION_BUILD_DIR=../Resources"
      command << " 2>&1 > /dev/null"
      unless system(command)
        raise ::Pod::Informative, "Failed to generate DTLoupe resources bundle"
      end
    end
    File.open(library_representation.copy_resources_script_path, 'a') do |file|
      file.puts "install_resource 'Resources/DTLoupe.bundle'"
    end
  end
end

In summary: use the second approach if you don’t want warnings and don’t need to support older CocoaPods versions.

Spec’ing it Out

Because DTRichTextEditor and DTLoupe are closed source that I am selling access too it would not have made any sense to put their specs into the public CocoaPods. Also it would probably fail the CI checks they have for lint-ing the specs because their Continuous Integration server would not be able to clone the source.

So I added a specs repository on our private GitLab server and made it public. The next question was if you would reference components with the SSH or HTTPS URLs. I went with SSH because there authentication works nicely by the public SSH keys the users have added to their profiles. If you use HTTP then users have to enter their credentials.

The security of SSH also makes me not worry security for my components and which is why I am showing you the above spec. Please be nice, don’t hack me bro…

Before I could put together the DTRichTextEditor Spec I needed to know the minimum versions that all dependencies would need to have to be compatible. For this I tagged and published specs for DTFoundation 1.2 and DTCoreText 1.4.1. The final step was to change around some headers in the project so that it would pass pod spec lint.

CocoaPods ignores any headers you added to your PCH file, because at the time of building the pods there IS no Precompiled Header File. At least not the one you were using for building your static library. Running the spec lint with –no-clean proved invaluable because it quickly found the places where additional #import where necessary.

I made this graphic to show how all fits together. DTLoupe and DTRichTextEditor are on our private GitLab server. They references DTWebArchive, DTCoreText and DTFoundation as dependencies.

Version Confusion aka The Pessimistic Operator

One thing that took me a while to wrap my head around was how to properly write the version requirement. At first I was pointed towards the CocoaPods Dependency Versioning document but that didn’t help clarify. French Developer Arnaud helped me out there.

~> 1.1.7 is >= 1.1.7 && < 1.2
And ~> 1.1 is >= 1.1 && < 2.0

What confused me is that the individual digits of the version are meaning something else. The rightmost digit means equal than or higher whereas all other digits are “locked”. This process is explained in the RubyGems User Guide. They call the tilde-greater the “pessimistic version constraint”.

If you are unsure how to increment your version numbers then I recommend you read the Semantic Versioning Specification authored by Tom Preston-Werner, one of the GitHub co-founders.

Conclusion

From my own experience I can tell you that it is a great feeling to have your dear-to-your-heart component successfully build via CocoaPods because it means that you don’t have a hidden dependency that you didn’t know about.

I will now make it standard practice to spec out private and public components because the process of getting it to pass lint alone shows you some places where you might have some build issues.

And the benefit for my customers is obvious as well. They can now have 3 options to add DTRichTextEditor to their apps:

• CocoaPods

Of these I personally use the second most of the time since it allows me to add code to sub-modules while working on a component. But for future apps I am tempted to switch everything to using CocoaPods.

I’ve begun to aggregate issues on both GitHub and our own private GitLab instance via milestones. These are the grouping unit collecting issues so that you can tell from which version onward these fixes or enhancements are available. Each milestone will become a tag, once it is completed and will represent a stable version.

You can always get a picture of the original issues if you filter them by milestone, like in this GitHub issue list for version 1.4.0 of DTCoreText

DTCoreText 1.4 Changes

• ADDED: Support for including local CSS style sheet files
• ADDED: DTHTMLWriter can now write HTML fragments with inline styles
• CHANGED: Changed the way color-changing hyperlinks are drawn, code now unified in DTCoreTextLayoutFrame
• CHANGED: You no longer need an override plist, all available system fonts now get loaded into the override table automatically
• CHANGED: renamed the define for showing performance measurement so that they don’t show in normal DEBUG mode
• CHANGED: strike-through and underline is now properly positioned and sized
• FIXED: Dictation Placeholder not displayed if no text delegate set
• FIXED: Line truncation problem going for longer than the paragraph
• FIXED: RTL justified text too short to be justified would be left-aligned instead of being right-aligned
• FIXED: Problem parsing CSS styles containing a !important tag
• FIXED: Using Chinese characters would cause height problems in hyperlinks
• FIXED: Having text with a shadow would cause bolder text due to it being drawn twice
• FIXED: Images don’t keep aspect ratio on resize
• FIXED: Element hyperlink URL did not get copied to DTTextAttachment
• FIXED: code removed by accident would cause problem with custom views for links
• FIXED: HTML encoding for Emoji Characters
• FIXED: Static Framework was not linking in code from DTFoundation
• FIXED: Static Framework building was missing embedded DTHTMLParser

The changes to how hyperlinks are drawn are breaking the API since before the color changing of hyperlinks that are touched was done inside DTLinkButton. But it was next to impossible to have these line up perfectly with the text. Now there is a mode on drawing (via bit mask) that allows you to draw a frame either with normal or highlighted hyperlinks.

The second big noticeable improvement relates to underlining. UIWebViews only do a nasty 1 px underline regardless of font size. The new method gets the line thickness and position from the CTFont. This causes underlines to look like in Pages. Also a great deal of effort was spent on having the lines always perfect pixel aligned, even on Retina displays.

DTRichTextEditor 1.4 Changes

• ADDED: A delegation protocol that gives it feature parity with UITextView.
• FIXED: override typing attributes (like setting bold with no selection) would be reset on a new line
• FIXED: Autocorrection was broken due to removal of input delegate notification
• UPDATED: DTCoreText to 1.4

At the time of this writing this version was not finalized and bug fixing still underway. But those are just finishing touches.

The other big and important improvement is that now the code lives on a GitLab server instead of Subversion. This unifies our workflow tremendously since we no longer have to keep copies of sub-projects inside the SVN repo. Instead everything is included as git submodules. Those are always pointing to an exact commit in the submodule. This way we have control over which version of the submodule we want to use and can advance the pointer if there is a new release without having to keep updating a full copy of the source code.

The other big advantage for all our clients comes from everybody having their own git user accounts. This way you can easily contribute enhancements in a project branch and create a merge request for them to be included in the master branch. Previously on Subversion I only had a single read-only user for everybody.

I am hoping that the new structure and the help of fabulous GitLab will enable a new form of social coding that we see as standard on GitHub. And that seeing other users helping out and squashing bugs will inspire a greater belief in the quality of this component as well as inspire contributing for the greater good.

The next version will finally implement proper list support. Two people have stepped forward to fund the development of this feature. This is a somewhat involved thing since we need to implement ability to protect certain parts of the text. You don’t want the user to be able to remove individual characters of a list item prefix. This can also benefit people who want to treat hyperlinks as a single unit.

The DTWordpress class, based on DTXMLRPC, provides an ever growing number of WordPress API calls, like retrieving a user’s blogs, a blog’s categories, posting a new article and uploading an image. All is block based.

For example this is the code in the sample app for uploading an image:

- (IBAction)uploadImage:(id)sender {
    DTWordpress *wordpress = [[DTWordpress alloc] initWithEndpointURL:URL];
    wordpress.userName = user;
    wordpress.password = pass;
 
    UIImage *image = [UIImage imageNamed:@"Default"];
    NSData *imageData = UIImageJPEGRepresentation(image, 0.8);
 
    [wordpress newMediaObjectWithFileName:@"bla.jpg" 
        contentType:@"image/jpeg" 
        data:imageData 
        shouldOverwrite:YES 
        completion:^(NSInteger mediaID, NSURL *mediaURL, NSError *error) {
        // deal with result
        });
    }];
}

DTXMLRPC is available as Open Source project for free use with attribution. A non-attribution license is also available on our store.

Because of this I went in and gave it some love.

Changes

• Modernized Project Structure to current standards
• Migrated to ARC
• Implemented iOS 6 autorotation support
• Added Retina artwork
• Added full documentation
• Add a Setup Guide

The new documentation can be found on our documentation site.

This component is still used in our iWoman app and so we will continue maintaining and offering it on our parts store now at a rock bottom price of 50 Euros for a normal development license.

Changes

• Fixed Problem with Filter Scope
• Addressed an Issue that might prevent some users from closing the Preferences Windows

The second problem was reported by two users but so far we have been unable to reproduce it. If you are a developer and too find that you cannot close the preferences window we need your help! Please e-mail us so that we can arrange for inspecting the problem on your machine.

Update March 28: Approved after 10 days.

Urban Airship Commander is dear to our heart and so it also deserves the benefit of a 1.1.1 version.

Changes

• NEW: App icon is now included when app configuration is forwarded by email
• CHANGED: Improved Verification of App Settings
• CHANGED: Better error descriptions

The version has been submitted to Apple for approval.

I used a relatively new feature of appledoc to create Programming Guides which allows to add markdown files that get transformed the same way to HTML as the header comments are.

You can also add images and cross references, which unfortunately seem to have a mind of their own. But I finally found a way how to get it what I wanted it to do and you can see the results online.

The current generation brings several user-facing features as well as a plethora of internal cleanup and refactoring.

The main benefits for users are that that the download process feels much better. Previously you would only see a progress bar during the download of catalogs and then it would not do anything during the “Processing” stage. Recent advancements in our DTZipArchive component now give us the capability of also showing an uncompressing progress.

That actually fills us with geeky delight because of a funny little detail we put into DTZipArchive that you would only feel. When computing progress you could either count files or bytes. When copying something large in Apple’s Finder they appear to be using whatever is the higher percentage of these two. This way you always have a movement on the progress bar, even if you’re copying many small files. We are doing it the same way.

When we started with iCatalog all catalogs where basically in portrait format and so we were surprised a bit by more and more clients doing catalogs in landscape format. Previously landscape catalogs would look small and out of place with exaggerated margins around the pages. So we made certain that this “surprising new format” also displays optimally, especially since most people seem to prefer holding their iPads in landscape orientation.

In this montage I am showing the previous landscape presentation on the left and the much improved version on the right. The page thumbnails are now larger and since we dynamically create them on the device they now support Retina displays which much improves their utility since you can even read large headlines – if you have good retinas.

Of course a shiny new version like 3.0 also deserves that we updated all components we rely on to the latest versions. The big benefit this gets us is that on iOS 6 the apps now use the built-in Facebook share sheets. We figure, people who love Facebook will also love this improved way of sharing products they find in iCatalog books.

There is another big change behind the scenes that affects the catalog production work flow. Three years ago I was a fledgling iOS developer and – frankly – was afraid of the big confusing world of Mac apps. Which is why I built the editor for iCatalog issues into the app itself. This worked pretty well for over two years, running the editor in iOS Simulator.

With v3 we were now able to refactor out the editing code and special cases from the framework. This is now in a standalone Mac app that I wrote late last year as my first big Mac project. Having the Editor in a separate Mac app gives the production staff many obvious advantages: drag and drop, Autosaving and Versioning (which are built into OS X since Lion), full mouse and trackpad support, keyboard shortcuts.

In retrospect I can say: if I had known how easy it is to make a Mac app I would have made the switch a couple of years earlier. And my partners would have suffered much less. Oh well, you grow and learn. I did my best to make the new Editor as efficient and fun to use as possible to make up for that.

You can and should immediately try out version 3 with the updated Lilly Pulitzer iCatalog+ and the brand new FullBeauty iCatalog+. Never mind that the current catalogs show a selection of beautiful bras. If somebody asks … you’re just evaluating the iCatalog technology.

iCatalog.framework 3.0 has proven to be a sturdy yet extensible platform that more than two dozen brands have chosen to trust for their digital catalog presentation: 27 catalogs and 1 magazine at today’s count, if you search for “iCatalog” on the app store.

Selling many licenses also allows me to dedicate a great deal of time to improving and tuning the component. Now here is Version 1.2.

Inside DTRichTextEditor you get the beating heart of DTCoreText, which is responsible for parsing HTML, generating attributed strings, correctly displaying the attributed strings as well as generating HTML output for persisting the changes. Because of this I am also doing a new release version of DTCoreText. That brings this component to version 1.3.

I won’t bore you with the lengthly change log which can be browsed online. As development progresses in the source code repository I am frequently updating this log to document them. I also recently added a Known Issues file to document current limitations of the editor.

Rick exclaimed excitedly:

Not only did you fix this issue, look how nice all of these languages are displayed in the editor.  Now this, my friend, is one nice editor!

The major changes revolve around improving performance, keeping pace with improvements in DTCoreText, adding Retina-support for the selection loupe and fixing a plethora of problems.

As a goodie for other editor developers I integrated a dictation placeholder view into DTCoreText. This is used if you tap the dictation button and dictate your rich text to Siri. Of course the purple dots animate!

For developers the amount of available APIs and related documentation has increased massively. The number of helpful methods for manipulating the attributed text is ever growing. All this development is driven by the client needs who often approach me with specific requests that I try to fulfill as broadly as possible so that all users of this component benefit.

As a general rule I am adding appledoc-style comments to all new public APIs. Also – just today – I spent an entire day polishing up the APIs and adding documentation comments to all remaining classes. Because of this the complete documentation for DTRichTextEditor can be now be browsed online or installed in your Xcode Organizer via the Atom Feed URL.

You can purchase a license for the DTRichTextEditor in our parts store. If you have a pro bono app in mind that would benefit from this, then please inquire about

Contrary to popular belief this app is not a game. It is a tool for developers.

Update Feb 25th: The Update is now approved and available on the App Store after 10 days.

Changes

• NEW: App now retrieves number of active devices and displays them on the app screen as well as when sending a new notification
• NEW: Change the order of your apps anyway you like, the log screen matches it
• NEW: You can forward configuration for apps by email
• CHANGED: Bigger text box for entering your push notification message
• FIXED: Changing an app name did not update the section name in the log
• FIXED: Incorrect location of database file could lead to data loss if iPhone gets full

The version has been submitted to Apple and I’ll update here as soon as it gets approved.

I admit, that for the first few tags/versions of DTCoreText I didn’t take CocoaPods seriously. But since I got down how to work with sub-modules and sub-specs I find that it gives me a great deal of pleasure to keep my specs current.

As your software matures people want to use a stable version of your library. That’s what versioning is for. From now on, any new features will increase the minor version digit. Fixes and improvements of existing functionality will increase the third digit.

Changes

• ADDED: truncation support to DTCoreTextLayoutFrame
• ADDED: DTAttributedLabel which can be used as a UILabel replacement
• FIXED: GCD ARC errors and warnings with iOS 6 deployment target
• CHANGED: DTAttributedTextView now uses the underlying UIScrollView contentInset
• CHANGED: Improvements on DTAttributedTextView to prevent unnecessary re-layouting

Many thanks go especially to bkennyatmeetme who contributed the first 2 items.

The new version is on CocoaPods and you should get it by pod update. We are thankful for any kind of support that you are willing to offer for our fun project here.

You can use DTCoreText in your apps for free if you attribute it to Cocoanetics, or you can purchase a Non-Attribution License for 75 Euros in our Parts Store. This is basically the DTCoreText improvement fund, but you get an invoice for your contribution that you can use in your company.

We are also looking for sponsors for larger endeavors like for example implementing support for <table> tags or further improve CSS support. Don’t hesitate to get in touch.