I’m “totally” migrating my iCatalog framework project to ARC, GCD and blocks and I’d like to share with you some of the revelations that the use of these modern technologies brings with them.

Here are two examples of the kind of simplifications you will see if you do the same. This approach is compatible with iOS 4.0 and above.

Executing a Multi-Parameter Method on Main Thread

I was looking for instances of performSelectorOnMainThread so that I could replace them with a dispatch_sync on main_queue instead. Previously when calling methods that take more than one parameter you had to jump through hoops.

Before:

- (void)reportAddProduct:(Product *)product toBagAs:(BagItem*)bagItem
{
	SEL selector = @selector(onlineIntegrationManager:willAddProduct:toBagAs:);
	if ([delegate respondsToSelector:selector])
	{
		NSMethodSignature *signature = [self methodSignatureForSelector:selector];
		if (!signature) 
		{
			return;	
		}
 
		NSInvocation* invocation = [NSInvocation invocationWithMethodSignature:signature];
		[invocation setTarget:delegate];
		[invocation setSelector:selector];
		[invocation setArgument:&product atIndex:2];
		[invocation setArgument:&bagItem atIndex:3];
		[invocation retainArguments];
		[invocation performSelectorOnMainThread:@selector(invoke) withObject:nil waitUntilDone:YES];
	}
}

After:

- (void)reportAddProduct:(Product *)product toBagAs:(BagItem *)bagItem
{
	if ([delegate respondsToSelector:@selector(onlineIntegrationManager:willAddProduct:toBagAs:)])
	{
		dispatch_sync(dispatch_get_main_queue(), ^{
			[delegate onlineIntegrationManager:self willAddProduct:product toBagAs:bagItem];
		});
	}
}

The handy dispatch_sync on main queue can call any method, with any number of parameters on the main thread. The sync is equivalent to the waitUntilDone:YES. Since this allows for putting the main thread code inline you no longer need to have special methods that you then performSelectorOnMainThread:.

As a second note I found that it calls to the main thread should generally be done synchronously because I had a situation where a UILabel would not get updated if I did waitUntilDone:NO. Having everything as dispatch_sync now also takes care of that.

Abusing the UIView Animation Context

Before we had block based animation I would find myself often passing some context to the animationDidStopSelector so that I can do some wrap-up work when the animation is done. This is quite unsafe, even ARC complains about that unless you add a (__bridge id) to tell it to ignore the memory management of this object.

Context parameters didn’t get retained as a rule of thumb. In this example I needed to remove a view that has been animated out also from an internal dictionary after it was done. Having a dedicated instance variable would not have been an option because you could potentially have multiple animations going on at the same time.

Before:

- (void)removalAnimationDidStop:(NSString *)animationID finished:(NSNumber *)finished context:(void *)context { UIView *removedView = (__bridge UIView *)context;   for (NSNumber *oneKey in [self.viewsForItems allKeys]) { UIView *view = [self.viewsForItems objectForKey:oneKey];   if (view == removedView) { [removedView removeFromSuperview]; [self.viewsForItems removeObjectForKey:oneKey]; } } }   // the above being called by:   for (id oneItem in itemsToRemove) { // we must have a view for this item to remove it __unsafe_unretained UIView *itemView = [self viewForItem:oneItem];   if (animated) { [UIView beginAnimations:@"ItemRemoval" context:(__bridge void *)itemView]; [UIView setAnimationDuration:deleteAnimationDuration]; if (delaySoFar>0) { [UIView setAnimationDelay:delaySoFar]; } [UIView setAnimationBeginsFromCurrentState:YES]; [UIView setAnimationDidStopSelector:@selector(removalAnimationDidStop:finished:context:)]; [UIView setAnimationDelegate:self]; }   itemView.alpha = 0; itemView.transform =CGAffineTransformMakeScale(0.5, 0.5);   if (animated) { [UIView commitAnimations]; }   delaySoFar +=deleteAnimationOffset; }

After:

// moved into a convenience method - (void)removeCachedView:(UIView *)removedView { for (NSNumber *oneKey in [self.viewsForItems allKeys]) { UIView *view = [self.viewsForItems objectForKey:oneKey];   if (view == removedView) { [removedView removeFromSuperview]; [self.viewsForItems removeObjectForKey:oneKey]; } } }   // called from:   for (id oneItem in itemsToRemove) { // we must have a view for this item to remove it __unsafe_unretained UIView *itemView = [self viewForItem:oneItem];   [UIView animateWithDuration:(animated?deleteAnimationDuration:0) delay:(animated?delaySoFar:0) options:UIViewAnimationOptionBeginFromCurrentState animations:^{ itemView.alpha = 0; itemView.transform =CGAffineTransformMakeScale(0.5, 0.5); } completion:^(BOOL finished) { [self removeCachedView:itemView]; }];   delaySoFar +=deleteAnimationOffset; }

A boolean animated value can easily be replaced with a duration of 0. Animation delays are passed in the appropriate method and the beginsFromCurrentState is now a UIViewAnimationOption. This method is way safer because the blocks “capture” (i.e.) retain all the used variables making it impossible for the thing that was previously passed via the context to already been deallocated.

Conclusion

Sorry for not having more wise words to add here. The beauty of the possible simplifications you get if you decide to make iOS 4 your minimum deployment target should speak for itself.

I’ve seen it! The fabled XIB support for Linguan is almost done.

A week ago I received a preview for the next version of Linguan which will also allow you to localize XIB files. Initially this will be facilitated by the ibtool tool which is contained in Xcode.app as well as gets installed in /usr/bin if you setup the command line tools.

The guys at BytePoets – who we partnered with to make Linguan a reality – integrated it such that you can edit strings and XIB files with virtually no difference. Behind the scenes you have ibtool humming away extracting the tokens from the interface builder files and if you make a modification to write them back in.

There are a few minor adjustments still necessary. For one there needs to be a preference setting to specify the path to ibtool. Without it the XIB functionality has to be disabled. Then we need to disable editing of the name column for tokens coming from a XIB because that’s the key that ibtool needs to send the updated string to the right place. If users can edit that it would probably cause trouble.

I am hoping to have a similar approach as we did in the past with genstrings. You might remember that initially Linguan was calling the original genstrings, but I reverse-engineered a static library with the same functionality which is orders of magnitude faster. Once this was working properly we replaced the external function to an internal one.

As soon as I have some time I hope to getting started with ibtool2 in a similar fashion. Write a GCD-multithreaded super-charged open-source version of ibtool that we can put in a static library and thus eliminate this external dependency.

Oh, if you have not done so yet I strongly urge you to purchase Linguan now because we will definitely raise the price tag once XIB support is live. Also your purchase gives us the budget to add more exciting features in the future.

I reported a while ago that I was forced to tag the current state of the DTCoreText master repository as 1.0.0. The reason for this was that CocoaPods was starting to gain lots of momentum and several people wanted to use DTCoreText via a podspec.

You can have podspecs point to the master branch as well, but then you never really know what you get. This can possibly cause many headaches especially in larger projects where you cannot track the state of each individual sub-project.

Therefore it is generally recommended – if not required – to make use of tags in GitHub.

Tags are like labels that you attach to the current state of a repository. You can create them simply by issuing the following command in the repository root folder.

git tag "1.0.1"

You can list the existing tags with:

git tag -l

There is an option on git push to have the tags also travel to the origin repository on GitHub:

git push origin master --tags

Once you’ve done that, GitHub provides snapshots of the tagged state as tar balls and zip files… though you probably don’t want to use these but rather have the project as a clone so that you can easily update it.

DTCoreText News

Amongst the fixes that made this maintenance release necessary where:

• Fixed Block-Retain-Cycle
• Fixed a second minor retain-cycle
• Workaround for Chinese Font cascade bug in iOS 5.x (radar://11262229)
• Workaround for a CoreText memory leak in iOS 4.3 (fixed in 5.0)
• Some Unit Testing corrections
• Updated Readme regarding necessary linker flags

I finally got around to also filing a Radar for the cascade bug. The memory leak issue is fixed as of iOS 5, the problem there was that if you replaced the paragraph style attribute on an NSAttributedString with a new one, the previous entry would leak. I fixed that by simply removing the attribute first before calling addAttribute with the new style.

The project has surpassed 1000 watchers on GitHub which tells me that it is definitely of use for many people. If you have any app making use of it, then please tell me about it as I like to feature your work. I especially love to receive testimonials like this one.

The changes to the Readme reflect the outcome of research done by David Hoerl. The question was to determine which linker flags are really necessary when linking in DTCoreText – or any other static library that contains categories – into an app.

Linker Flags Wisdom

The linker in general tries to only link in code that is actually used. So if you have C-functions then their code will not end up in the final app binary if it is never being called. This does not work for Objective-C category extensions because of the dynamic nature of method resolution.

Therefore you would generally use the -ObjC linker flag when dealing with static libraries that contain Objective-C code.

Greg Parker from Apple who refers to himself as “Runtime Wrangler” explains it like this:

-all_load and -force_load act at link time, not at load time. -all_load and
-force_load tell the linker to link the entire static archive in the final
executable, even if the linker thinks that parts of the archive are unused.

When you link a traditional C static archive (.a file), any code from the
archive that is never referenced in the final executable is simply omitted from
the executable. So if you had a static archive with 999 functions you did not
call and 1 function that you did call, your final executable would include only
that one function.

Objective-C categories break the C static archive model, because you want the
Objective-C category to appear in the final executable even though there are no
C symbol references to it from the executable.

The best solution for Objective-C categories in static archives is the -ObjC
linker option, which tells the linker that all Objective-C categories in the
archives are “used” but to apply the usual reference algorithm for everything
else in the archives.

The -ObjC option is broken in some versions of the linker. For those cases the
-force_load and -all_load options work. The final executable may be larger than
necessary with those options, if there were classes or C functions that could
have been omitted by the linker. If you have multiple archives and only some of
them have Objective-C code then -force_load may generate smaller output than
-all_load.

On iOS you’d typically only link in libraries that you need, as opposed to traditional C or C++ where you’d often link in large static libraries that are collections of utility methods. So in the case where the libDTCoreText.a is the only static library should be  no difference between force_load and all_load at all.

Personally I prefer the simplest approach which is to first try to get by with only -ObjC and if I get unrecognized selector crashes to additionally add -force_load because there I don’t need to know or specify the path to the specific library.

DTRichTextEditor

I’ve streamed all the 1.0.1 updates also into DTRichTextEditor which uses DTCoreText for display of rich text. Changes there include:

• Support Left, Center, Right and Justified toggling of paragraphs
• Preliminary work on supporting lists

I love to get feedback from people who are actually using the editor in shipping apps. The most prominent one is Dootrix who made the Simpl iPad app. I interviewed the maker on my podcast, if you haven’t done so I urge you to listen to it as I think it was one of the most enlightening conversations I ever had on air.

I keep getting requests for a ways to test the editor component before purchasing it. Also the work on lists as well as some feature requests are still open for the editor.

Unfortunately I won’t have any time to devote to these requests as we are in “crunch time” for a major project of maximum importance for the next two weeks. Therefore I ask for some patience.

The Future

I’m not making very much money from selling licenses. Only enough to justify it as a hobby. I might be forced to dramatically raise the price in the near future. So if you are thinking of buying then better do so now, because you then will have access to my Subversion repository and get the benefit of all future updates.

On the above mentioned podcast episode I also discussed what my thoughts where related to the future of rich text editing on iOS.

I am happy if Apple takes on more of the burden that DTCoreText and DTRichTextEditor are currently carrying. It is astonishing that they truly believe that people would use contentEditable UIWebViews for that task. As iPads become equal-partners in content creation this is an essential platform feature.

There are two levels that I can see Apple move forward on:

• Add the missing protocols and interfaces for interacting with selections and the magnifying glass – you would still have to create your own editor but at least you could do way more easily
• Enhance UITextView – which is using WebKit under the hood already – to be editable. Or alternatively create a totally new Rich Text Editing View.

Either way I will still have a market and and audience while people support 4.3 and above, or 5.0 and above when 6.0 finally ships. I would predict the former and not bet on the latter.

To cut a long story short: progress is being made and patience is required.

I thought I was smart when refactoring some code in DTAboutViewController to use block-based animations. Turns out that I had not considered backwards compatibility for 3.x when doing that simple change. This caused some unlucky users (still on iOS 3.1.3) to get the update pushed via iTunes, but then finding themselves unable to launch the app.

I do plan to cease supporting 3.x sooner or later, but not like this. The proper way is to raise the deployment target when implementing features that require 4.x. This way people unwilling (or unable) to update their devices just won’t be receiving those new updates but will still be able to continue using the old version.

Changes

• Fixed: Incompatibility with 3.x causes app to crash
• Added: Alert when user tries to send support e-mail but has no account configured
• Fixed: Tapping on today button in cycle view would show the wrong day in cycle view.
• Fixed: Tapping on the calendar button in Wheel View would lead to the wrong day in calendar view (in some time zones)

The update has been submitted to Apple and should be available soon.

Update April 4th: … the update is now available on the App Store.

I did a quick fix for Linguan after several users complained about the strict slash-escaping that we had introduced in 1.0.4.

Linguan un-escapes all texts it reads from strings files so that they can be displayed correctly. You don’t want to have to deal with backslashes in the editor. Now on writing I had thought it to be a good idea to also escape everything, including question marks, backslashes and single quotes. It was a bad idea to do that because this unduely changes the tokens and translations.

Translators (the sad kind without Linguan) would be confused by having to deal with lots of \’ in the text. And there where some reports of the localized string loading functions not being able to find the key. Not always, but this is clearly not what we wanted.

This update relaxes the escaping on writing to the extent that only double quotes and invisible characters are now being escaped.

This release fixes the crash on iOS 5 that I had in all my apps using the version of DTAboutViewController from before iOS 5 was released. I’m sorry for having procrastinated so long on updating SpeakerClock, but I had forgotten about this issue until a user reminded me of it via e-mail.

The update has been submitted to Apple and we hope to have it available on the app store in about 5 days.

Update March 10th: … and it’s approved and available for download.

This is a hot fix release addressing several issues that users found. You now have a new option to decode unicode sequences with two backslashes on loading strings files or scanning source code. Decoding and Encoding of slash escapes now uses the functions provided by genstrings2.

Changes

• ADDED: Option to decoding of \\U unicode sequences on loading files
• ADDED: Copy/Paste now possibly without the need to double-click on cell
• FIXED: Problem with xcodeproject with non-English CFBundleDevelopmentRegion
• FIXED: Warnings not being updated if tab is visible before validating
• FIXED: Over-Escaping of single quotes on scanning
• FIXED: Parse File duplicates loaded tokens

Here’s another maintenance release fixing a crashing bug in the About section.

Changes

• Fixed: Crash on trying to open usage instructions
• Added: More detailed explanation of accuracy and filter settings

This update, like the one before it, goes out for the paid version of GeoCorder first. If the issues are resolved once this comes into the store then we’ll update the ad-sponsored version, too.

Update Feb 11th: The update has been approved.

This is a maintenance update. There was a bug in DTAboutViewController which caused a crash under iOS 5.

Change

• Fixed: Crash on iOS 5 when opening About Section

The update has been submitted to Apple for approval.

Update Feb 8th: Ready for Sale. It should be available shortly.

Besides fixing several bugs reported by users this release focusses on implementing a new custom-built super-charged strings scanner.

Changes

• FIXED: missing strings file no longer aborts import
• FIXED: added – Button for deleting tokens
• FIXED: deletion of wrong row
• FIXED: over-escaping of \ on writing strings files
• FIXED: wrong token name updated on enter key
• FIXED: search filter not reset on adding a new token
• FIXED: Previous/Next buttons in wizard cease to function
• NEW: replaced genstrings with high-speed custom implementation (>20x speed improvement)
• NEW: support custom localization macro prefix

This new version does no longer support 32-bit because the new strings scanner was implemented using ARC. We hope that this does not inconvenience any of our existing uses. But then again, serious developers are on a 64 bit machine anyway since Snow Leopard…

The new version has been submitted to Apple today.

The second hot fix pack for Linguan 1.0 fixes a couple more issues that some of our (mostly) happy customers reported.

Changes

• Fixed: Translations will no longer get trimmed
• Fixed: Problem opening projects with absolute file paths
• Fixed: Table did not update on deletion of token
• Changed: Extended duration of “no new tokens found” HUD
• Changed: Enter key now opens selected recent project in welcome screen

If you haven’t done so please post your feedback on iTunes. To be able to add additional features to Linguan we need to have sufficient sales. And for that we need your positive reviews, high rating and that you tell other developers about Linguan.

Today is the best day for them to also get a copy because: As a Thank You for your interest in our app we reduced the sale price by 50% until the new version gets approval by Apple.

My partners at BytePoets have been causing their keyboards to emit steam from walking through 26 issues that we identified on the 1.0 release just 9 days ago. Almost all had been identified as typical “oh shoot” elements, mostly items that you only find when people begin to actually use your software. Also I was able to smuggle in one or the other new feature since I consider “user confusion” also as a form of bug that you should hot fix if you can.

Changes

• Fixed: potential crash on exporting tokens
• Fixed: on Export Missing Tokens + Translated Tokens = All Tokens
• Fixed: Undo bug when adding a new token
• Fixed: Location of HUD with app running on external monitor
• Fixed: red filename when opening a single strings file
• Fixed: entries in recent file list get duplicated
• Fixed: string parser did not properly deal with escaped characters
• Fixed: Warnings window scrollbar was cut off
• Fixed: Warnings and Errors should not be editable
• Fixed: Potential crash on closing a window or sending app into background
• Fixed: Problem saving files with French accent characters
• Fixed: Problem reading certain UTF16 files
• Fixed: Double-clicking a Warning should select the related token
• Fixed: Order of files to select for export was different from project tree
• Fixed: Warnings did not get flushed on revalidation
• Fixed: Inconsistencies in Wizard mode
• Fixed: Inconsistent handling of recent files
• Fixed: App no longer asks if you want to save the xcodeproj (which it does not modify)
• Fixed: you could open the same file twice
• Fixed: Inconsistent showing of Welcome window
• Fixed: Potential crash on reopening a file from recent file menu
• Fixed: confusing behavior of the setting for the token order in saved files
• Fixed: saving of files now cleans them up properly
• Fixed: Previous button was active in Wizard even when there was no previous token
• Changed: Error message improved when trying to import file that was not exported from Linguan
• Added: you can now add newlines in grid view with Alt+Enter, regular enter moves to the next row

I wanted to also get in several localizations and 10 volunteers jumped forward to provide translations of the tokens. But it turns out that this is only a third of the whole app. There are also many strings in XIBS and the help file. So instead of doing an incomplete job, I did not put these into this version just yet.

In Mac apps people tend to put more text in XIBs. Probably because there you have much more screen space which leads to more labels and setting all those in code would require many more outlets. But I ordered XIB support for 1.1. Linguan is localized in English and German at present, so I’m also taking the opportunity to add a German app store description which I found you can only add if the app is not yet approved. More languages will follow in another point release.

Another thing that did not make it for 1.0.1 is support for settings bundles because Xcode 4.2 seems to be in inconsistent about importing and handling these. So that needs a bit more research to support.

One thing that was also confusing was the naming of the “Last Import” auto-folder. If you scan your sources – Linguan uses genstrings for that – you will see new tokens appear there for quick access to what you need to add translations for. So we renamed that to “Last Scan”.

There are many more things that our enthusiastic users would like us to add, but as you can see we had our hands full at polishing up the 1.0 release. New features are being planned for the 1.1 version due later this year.

It would be awfully nice of you if you could help us spread the word about Linguan, here’s the app store link. And maybe a review on the app store, preferably with 5 stars? If you need support with Linguan please e-mail us.

UPDATE Nov 23rd: Now available.

There was a stupid problem before this version that could only be seen by users who where traveling between time zones. Notes that you made for a specific date would disappear when you moved into a different time zone and reappear if you moved back. This taught me that it is a bad idea to use an NSDate for a primary key.

Updating a lower version iWoman will restore all entries that might have disappeared. In very rare circumstances – involving traveling more than 12 time zones – some entries might end up the day before or after the day they were originally entered on.

The second change came from a user request who wanted to see the day number on all days of the cycle view. Previously it would not be shown on fertile days.

Changes

• FIXED: Items would vanish from calendar view if user moved between time zones.
• MODIFIED: Now the day number is shown for all days in cycle view.

The update has been submitted to Apple and we hope for a swift approval.

UPDATE Sept 7th: the update is now available on the app store.

The latest HotFix committed to the MyAppSales GitHub repo contain a fix for an AJAX change on iTunes connect.

Changes

• Fixes a problem where only the first daily or weekly report would be downloaded.

The problem started to occur because apple added a javascript function call into the method to switch between days and weeks. Something to do with rate limiting, I think they now disable the download button while the AJAX request is ongoing.

Development of version 2.0 is still ongoing, you can sneak a peak on the development branch. There are a couple of  things to do before I can merge it back into master: changing the charting to DTChartView and doing the summing per app on a background thread.

In the future I am still hoping that the Open Source community will get a bit more involved than it has been. i.e. totally hands off. I’ve open sourced MyAppSales precisely because I was hoping for contributions, but I have yet to see the first.

Summertime is my app that helps you to never be surprised by Daylight Savings Time transitions. A customer nudged me to update the app in time for the upcoming transitions. Since he is traveling a lot I needed to add the capability of configuring multiple time zones.

I spend several days to enhance the functionality as described below and to polish it to a level where I can release it in time for the upcoming DST transitions. March 13th in the US and March 27th in Europe.

Updates

• NEW: Completely new Design
• NEW: Set multiple time zones for your travels
• NEW: Choose “Local Time Zone” to be automatically updated to your local time zone
• NEW: Multi-Language Time Zone picker

The update is now under review by Apple.

I’m rather proud of the new look which is modeled after the weather app.

Before (October 2009):

Now (March 2011):

I’ve been working on several ingredients that made this possible.

One part was to be able to localize the time zone name you see on the cards. This is typically in a form “Europe/Vienna” and there is no localization for it. The only localized description you get is for the “Central European Summer Time”. Quite an oversight I think, that’s why I started an Open Source project to have this available in a translated way as well: NSTimeZone+Localization. In order to get a well-performing way to group and filter the time zones I added a CoreData backend which re-imports all known time zones every time the locale or the iOS version changes. With this the grouping by continents is happening automatically for me and searching via the search bar on top is a snap.

Time zones which observe DST are shown in green. Those which are not are shown in red. This is also an interesting view of the world.

The second part is to eventually be able to make it a universal app that behaves like the weather app on iPhone and presents a novel card-based layout and interactions on iPad. I did not get the final 10% done in time for a release, so I set the target device family to iPhone-only for the time being. Displaying and managing cards works, but I have to think of a way to do what the i-button does on the iPhone version, display a sorting table view. The general idea of DTCards is to be able to fully reuse the views you are building for a utility iPhone app but make use of the wider space available on an iPad. DTCard would allow me to pinch-open on individual cards to zoom into a more detailed view, but in this context this also does not make sense, because I’m already displaying all there is to know about the next Daylight Savings Time transitions.

In short, the iPad UI is not ready. At the same time Summertime is one of my glorified hobbies with which I don’t really make nearly enough to warrant put in the midnight oil. I’ll finish the iPad UI if I ever have time or if somebody specifically asks for it or if suddenly sales go through the roof. IF to the power of 3.

There is one piece of functionality that gets shown only if you run iOS 4 or higher: the reminder button. When pushed it allows you to specify a reminder which happens in the form of a local push notification for the next transition. This way easy enough to implement but only came into iOS with version 4. Thus people still running an outdated 3.x only get the cog button for changing a card
s time zone and the mail button to e-mail somebody with the info on the card.

I posted some screenshots on twitter and feedback generally has been very favorable. Let’s see what the customers think as soon as Apple approves the update.

Update March 12th: Out now!

In this quick-fix update for iWoman I addressed a bug that could only be seen by users of the basal temperature feature.

Changes

• FIXED: The basal temperature chart would only show the first 30 entered values.

Update was approved by Apple on March 8th it is available via the app store.

It’s been a while since we last updated our game LuckyWheel. There was a nasty bug on iOS 4.x that prevented the keyboard from appearing causing a great deal of frustration. We also used the opportunity of polishing the graphics and adding Retina support.

Changes

• FIXED: Keyboard not appearing on iOS 4.x
• UPDATED: Now with Retina Graphics
• NEW: Lite Version has IAP option to purchase full version question pack
• NEW: Lite Version has IAP option to remove ads

The new version has been submitted to Apple and is awaiting review.

The previous version of iWoman has a severe problem if you have an existing database that needs to get migrated. Turns out that old iPhone might take too long doing that. And if it takes longer than a couple of seconds for an app to start then there is a watchdog timer in iOS that will outright kill the app.

Also there was a graphics glitch on the list view which has been remedied. I am really sorry for all these glitches. I promise you that they have not been intentional and I am quite embarrassed by them.

The Update has been submitted to Apple and should become available soon.

Changes

• Fixed: Graphics glitch on list view on 3.x devices
• Fixed: DB Migration is now done after app startup – instead of during startup – to prevent app termination by iOS.

Hopefully with this patch migration and usage should be smooth on 3.x and 4.x alike. If so then I can concentrate on additional features. The app is doing pretty well in Russia and so I will add localization as a “Thank you!” for the Russian ladies. Also I am thinking about adding Japanese to see how this might affect sales there.

GeoCorder started out as a pure track recorder but since version 1.2 it also became a great position tracker, provided that you had your own server to receive the position updates.

In this new version 1.3 you have a choice of two additional services: Google Latitude and Crossingways.

Changes

• FIXED: Tracker would stop sending updates
• ADDED: Google Latitude as tracking service
• ADDED: Crossingways as tracking and upload service

Update Jan 7th: The update is now available for download from the app store.

These changes made it necessary to completely revamp the tracking screen. Each individual service is now shown with a traffic light indicating the last update status. Red means error, Yellow in progress and Green ok.

The Update Interval is now set globally for all enabled service. You can switch services on and off on the “Configure Tracking Services” screen. Additionally you can configure an arbitrary number of custom servers to receive your updates via HTTP GET.

In addition to these changes on the tracking screen there is a new section in settings where you can link the Crossingways and Latitude accounts.

Generally a word of caution: Crossingways insists on mentioning that they are BETA, Latitude keeps telling us that it is a Google Labs service that might change when becoming a released product. Generally my tests have shown them to work without issues.